Please login or register.

Login with username, password and session length
 

News:

Latest updates at DangerousPrototypes.com.


Author Topic: new branch in the svn (newterm)  (Read 4198 times)

Sjaak

  • Fellow
  • Hero Member
  • *****
  • Posts: 885
  • Karma: +263/-0
  • Überprutser
    • View Profile
Re: new branch in the svn (newterm)
« Reply #30 on: February 10, 2010, 02:11:04 PM »
Ian, how did the testing went?

I'm still puzzling a bit with the messagesystem. I though of a way for storing text much more efficient, but i'm a bit stuck in writing the converter.

ian

  • Crew
  • Hero Member
  • *****
  • Posts: 2861
  • Karma: +61/-0
    • View Profile
Re: new branch in the svn (newterm)
« Reply #31 on: February 11, 2010, 07:42:23 AM »
I compiled the latest source and posted a call for preview testers. I'm eager to see the reactions. You've done a really great job with this.

Sjaak

  • Fellow
  • Hero Member
  • *****
  • Posts: 885
  • Karma: +263/-0
  • Überprutser
    • View Profile
Re: new branch in the svn (newterm)
« Reply #32 on: February 11, 2010, 12:47:46 PM »
Ok, I had already compiled it and put it in the directory ;) Actually I compile it and then it is ok. You dont need to export, etc, etc, anymore. It also uploads much quicker :D

One thing I need to correct: it isn't smaller, actually it is 2k bigger, I dunno why.. I think it is because of the 'stacking' of the modes ( m 4 5 etc) and the new history function. Perhaps also some leftover debug strings.

BTW thanks Ian.
« Last Edit: February 11, 2010, 12:57:38 PM by Sjaak »

elafargue

  • Newbie
  • *
  • Posts: 11
  • Karma: +1/-0
    • View Profile
Re: new branch in the svn (newterm)
« Reply #33 on: February 16, 2010, 04:23:49 AM »
Hi Sjaak, I'm very much looking forward to one of the features of your updates: the ability to send ASCII codes as "string", it is very useful since at the moment, the only way to type ascii commands on the bus pirate is to put it into transparent UART mode which you cannot get out of without resetting...

-> If you are looking for testers, I am willing to try, any risks involved ? :)

Sjaak

  • Fellow
  • Hero Member
  • *****
  • Posts: 885
  • Karma: +263/-0
  • Überprutser
    • View Profile
Re: new branch in the svn (newterm)
« Reply #34 on: February 16, 2010, 07:07:56 AM »
elafargue, not much risk. Most of the code is copied from the 'old' firmware. Please don't use it for mission critical things ;)

Sjaak

  • Fellow
  • Hero Member
  • *****
  • Posts: 885
  • Karma: +263/-0
  • Überprutser
    • View Profile
Re: new branch in the svn (newterm)
« Reply #35 on: February 18, 2010, 01:16:05 PM »
I've been a little quiet the last days about the newterm branch. But I'm still working on it :D I made a little scripting engine which will (in the near future) control the functions of each protocol. At the moment it only supports the following basic keywords:

Code: [Select]
#define STAT_LET "LET"
#define STAT_IF "IF"
#define STAT_THEN "THEN"
#define STAT_ELSE "ELSE"
#define STAT_GOTO "GOTO"
#define STAT_GOSUB "GOSUB"
#define STAT_RETURN "RETURN"
#define STAT_REM "REM"
#define STAT_PRINT "PRINT"
#define STAT_INPUT "INPUT"
#define STAT_FOR "FOR"
#define STAT_TO "TO"
#define STAT_NEXT "NEXT"
#define STAT_END "END"

I think that is enough too write a simple basic program that can handle all the computations needed for interfacing a serial device. I'll also implement the same commands as normally available:

Code: [Select]
PROTOCOL:
start
startR
stop
stopR
send
read
clkh
clkl
dath
datl
dats
clk
bitr
macro

GENERAL:
adc
auxin
auxlo
auxhi
psu
pullup
delay
bitorder
auxpin

As with all things a picture says more then thousand words (note that I wrote this besides the normal buspirate framework and only bpWinthex (which display a 16bit hex) is available):

Code: [Select]
Buspirate basic version :D
(C)hris 2010
released under creative commons null license
Press any key to continue

0x0064  REM basictest
0x006E  LET A=C+16
0x0078  FOR B=1 TO 5
0x007D  FOR D=0 TO 2
0x0082  PRINT "A=";A;" B=";B;" D=";D
0x0087  NEXT D
0x008C  NEXT B
0x00C8  INPUT "Enter C",C
0x00D2  GOSUB 1000
0x00DC  IF C=20 THEN  PRINT "C=20!!"; ELSE  PRINT "C!=20";
0x00E6  END
0x03E8  PRINT "C=";C
0x03F2  RETURN
0xFFFF  END
0x0096 bytes

A=0x0010 B=0x0001 D=0x0000
A=0x0010 B=0x0001 D=0x0001
A=0x0010 B=0x0001 D=0x0002
A=0x0010 B=0x0002 D=0x0000
A=0x0010 B=0x0002 D=0x0001
A=0x0010 B=0x0002 D=0x0002
A=0x0010 B=0x0003 D=0x0000
A=0x0010 B=0x0003 D=0x0001
A=0x0010 B=0x0003 D=0x0002
A=0x0010 B=0x0004 D=0x0000
A=0x0010 B=0x0004 D=0x0001
A=0x0010 B=0x0004 D=0x0002
A=0x0010 B=0x0005 D=0x0000
A=0x0010 B=0x0005 D=0x0001
A=0x0010 B=0x0005 D=0x0002
Enter C
(0x0000)> 20
C=0x0014
C=20!!

feel free to give your opinion and tell me what functionanlity you want to see in it.

@ian: could you please help me with the periodic function? No Hurry as I know you're a bit busy ;)

ian

  • Crew
  • Hero Member
  • *****
  • Posts: 2861
  • Karma: +61/-0
    • View Profile
Re: new branch in the svn (newterm)
« Reply #36 on: February 19, 2010, 01:30:04 AM »
This is fantastic! How can I help with the periodic function - let me know what to do and I'll dive in.

Sjaak

  • Fellow
  • Hero Member
  • *****
  • Posts: 885
  • Karma: +263/-0
  • Überprutser
    • View Profile
Re: new branch in the svn (newterm)
« Reply #37 on: February 19, 2010, 01:57:42 AM »
from one of your first test/posts:

Quote
*No message on UART live IO (with { or [), and live IO doesn't seem to work (no period service routine?)

This isn't implemented yet, but i think it should be in the future ;) I was thinking about starting a timer with {[ and using an ISR to fill a temp buffer, which gets displayed after an enter. The ISR executes the proto[current].periodic() which fills the buffer.

BTW we should also look into the text system (but that works atm ;) so no hurry here)

pgeorgi

  • Newbie
  • *
  • Posts: 10
  • Karma: +0/-0
    • View Profile
Re: new branch in the svn (newterm)
« Reply #38 on: February 20, 2010, 10:01:15 AM »
Depending on how large the code can be, and how large the variable space is, this might be very useful to flashrom:
Upload special routines at the beginning, which handle large transfers (ideally we'd need a way to buffer 300 bytes) and allow the buspirate to poll for the chip to become un-busy without having to interact with the host all the time, use those routines to do the flashing, discard on exit.

Sjaak

  • Fellow
  • Hero Member
  • *****
  • Posts: 885
  • Karma: +263/-0
  • Überprutser
    • View Profile
Re: new branch in the svn (newterm)
« Reply #39 on: February 20, 2010, 12:07:42 PM »
Wel the variable space will be around 26 (a-z) which are signed 16 bit ints. I'm thinking about arrays and string atm, but for now this is it. The codespace is atm 1kb.

I'm developing it besides the newterm, but the standalone is almost finished, so I'm gonna integrate it this weekend and I'm hoping to release it also this weekend. Also it will only be available for newterm as it isn't compatible with the old codebase.

Isn't binmode fast enough btw?

ian

  • Crew
  • Hero Member
  • *****
  • Posts: 2861
  • Karma: +61/-0
    • View Profile
Re: new branch in the svn (newterm)
« Reply #40 on: February 21, 2010, 02:58:55 AM »
Binmode is pretty slow, the Bus Pirate was designed for the user terminal interface that doesn't require fast reaction times. The binmode was an afterthought, and lots of people are disappointed by the limited speed of the 115200UART in binmode. It's not great for large transfers because you need to push read/writes in 15byte segments too, but that's a protocol limitation. If I were to design a device for binary IO it would use a direct USB HID or other bulk transfer interface instead of the serial converter chip.

The current hardware has binary transfer rate limitations because it was designed only for user terminal interaction, but has grown to handle so much more. As the Bus Pirate is supported by more software, there's a growing group of people who would really like a device with more binary bandwidth. I hear you, and I'm working on it :) The main issue is the USB connection. There's already a GPL HID driver in the ASM bootloader that I'm using in a bunch of projects, that's half the equation. I won't use the Microchip CDC virtual serial port firmware because it's not really open source and I hate trying to distribute source that relies on it. I'm hoping when the USB IR Toy and the SUMP PUMP are out there that there's critical mass to develop an open alternative. Then we'd have everything we need for a USB 2.0 Bus Pirate. This is also something I could hire someone to do if we found the right developer. Maybe I should put up a quick post on rentacoder?

This got a little out of hand and off topic, but this is a thread about development ;)

Sjaak

  • Fellow
  • Hero Member
  • *****
  • Posts: 885
  • Karma: +263/-0
  • Überprutser
    • View Profile
Re: new branch in the svn (newterm)
« Reply #41 on: February 21, 2010, 03:36:25 AM »
Sounds cool! planning to keep it 'backward' compatible? I really like the low level entry of hyperterminal (or terraterm) to use the device.

I could implement an get, so the user could program a his own protocol. This would however lead to an explosion of buspirate protocols, I'm afraid. My intention for the scripting was to automate things for which now macro's or seperate libraries (lcd) are writing. Thus lowering the entrylevel.

Edit: the speed can be a bit higher but i calculated that i could be higher the 230400 (see other thread http://whereisian.com/forum/index.php?topic=318.0). an other issue is it uses an internal oscillator instead of a crystal (dunno the precission, but i guess not as good a crystal)
« Last Edit: February 21, 2010, 03:43:04 AM by Sjaak »

Sjaak

  • Fellow
  • Hero Member
  • *****
  • Posts: 885
  • Karma: +263/-0
  • Überprutser
    • View Profile
Re: new branch in the svn (newterm)
« Reply #42 on: February 21, 2010, 04:40:55 AM »
Hmm, it looks like i'm hitting a boundry by adding the basic interpreter to the newterm branch. Now i must select large memory model for both data as code. This will add approc 6k to the code and totals it (in the current form) to a whopping 60kb (94% of flash space used) Looks like i need to digg a bit earlier into the textsystem to save bytes over there

And also my compiler is almost over its evaluation period, now it prints a warning for every .c so the real errorswarnings are missed easily. Bleh!!
« Last Edit: February 21, 2010, 05:40:33 AM by Sjaak »

Sjaak

  • Fellow
  • Hero Member
  • *****
  • Posts: 885
  • Karma: +263/-0
  • Überprutser
    • View Profile
Re: new branch in the svn (newterm)
« Reply #43 on: February 22, 2010, 03:19:43 PM »
I tried to use -o1 optimize switch but things get broken (at least with the interpreter). So for now no optimizing :( If someone has precise info about the gcc optimizing please share, perhaps we could use it :D

Testing went well so far; the scriptengine is integrated into the buspirate structure and seems to work well. Here are the prelimary results:

The basic test (with no interfacing just the syntax):

Code: [Select]
Bus Pirate v3
Firmware v4.2 (newterm-basic)  Bootloader v4.1
DEVID:0x0447 REVID:0x3043 (B5)
http://dangerousprototypes.com
HiZ> s

100  REM basictest
110  LET A=C+16
120  FOR B=1 TO 3
125  FOR D=0 TO 1
130  PRINT "A=";A;" B=";B;" D=";D
135  NEXT D
140  NEXT B
200  INPUT "Enter C",C
201  READ C
202  GOSUB 1000
203  READ C
204  GOSUB 1000
205  READ C
206  GOSUB 1000
207  READ C
210  GOSUB 1000
220  IF C=20 THEN  PRINT "C=20!!"; ELSE  PRINT "C!=20";
230  END
1000  PRINT "C=";C
1010  RETURN
2000  DATA 1,2,3
2010  DATA 4
65535  END
208 bytes.
HiZ> S
A=16 B=1 D=0
A=16 B=1 D=1
A=16 B=2 D=0
A=16 B=2 D=1
A=16 B=3 D=0
A=16 B=3 D=1
Enter C
(0)> 23
C=1
C=2
C=3
C=4
C!=20
HiZ>

I2C test with a 24lc02 I2C eeprom.
connections:

Code: [Select]
BP 24lc02
5v 8
GND 1,2,3,4
clk 6
mosi 5


And the result (first writing using normal commands, read back by the script and reset to 0xFF, next read back by commandline):
Code: [Select]
HiZ> i
Bus Pirate v3
Firmware v4.2 (newterm-basic)  Bootloader v4.1
DEVID:0x0447 REVID:0x3043 (B5)
http://dangerousprototypes.com
HiZ> m 4 1
I2C (mod spd)=( 0 0 )

READY
I2C> P W
Pull-up resistors ON
POWER SUPPLIES ON
I2C> ]
I2C STOP BIT
I2C> [ 0xa0 0 1 2 3 4 5 6 7 8 ]
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x00 ACK
WRITE: 0x01 ACK
WRITE: 0x02 ACK
WRITE: 0x03 ACK
WRITE: 0x04 ACK
WRITE: 0x05 ACK
WRITE: 0x06 ACK
WRITE: 0x07 ACK
WRITE: 0x08 ACK
I2C STOP BIT
I2C> [ 0xa0 0 [ 0xa1 rrrrrrrr ]
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x00 ACK
I2C START BIT
WRITE: 0xA1 ACK
READ: 0x01
READ:  ACK 0x02
READ:  ACK 0x03
READ:  ACK 0x04
READ:  ACK 0x05
READ:  ACK 0x06
READ:  ACK 0x07
READ:  ACK 0x08
NACK
I2C STOP BIT
I2C> s

100  REM I2C test (24lc02)
110  PULLUP 1
120  PSU 1
130  DELAY 255
140  STOP
150  GOSUB 1000
200  START
210  SEND 160
220  SEND 0
230  FOR A=1 TO 8
240  READ B
250  SEND B
200  NEXT A
260  STOP
270  DELAY 255
280  GOSUB 1000
290  PSU 0
300  PULLUP 0
310  END
1000  REM Dump 8 bytes
1010  START
1020  SEND 160
1030  SEND 0
1040  START
1050  SEND 161
1060  PRINT  RECEIVE ;" ";
1070  PRINT  RECEIVE ;" ";
1080  PRINT  RECEIVE ;" ";
1090  PRINT  RECEIVE ;" ";
1100  PRINT  RECEIVE ;" ";
1110  PRINT  RECEIVE ;" ";
1120  PRINT  RECEIVE ;" ";
1130  PRINT  RECEIVE
1140  STOP
1140  RETURN
2000  DATA 255,255,255,255
2010  DATA 255,255,255,255
286 bytes.
I2C> S
1 2 3 4 5 6 7 8
255 255 255 255 255 255 255 255

I2C> P W
Pull-up resistors ON
POWER SUPPLIES ON
I2C> ]
I2C STOP BIT
I2C> [ 0xa0 0 [ 0xa1 rrrrrrrr ]
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x00 ACK
I2C START BIT
WRITE: 0xA1 ACK
READ: 0xFF
READ:  ACK 0xFF
READ:  ACK 0xFF
READ:  ACK 0xFF
READ:  ACK 0xFF
READ:  ACK 0xFF
READ:  ACK 0xFF
READ:  ACK 0xFF
NACK
I2C STOP BIT
I2C>


Next is SPI :D

ian

  • Crew
  • Hero Member
  • *****
  • Posts: 2861
  • Karma: +61/-0
    • View Profile
Re: new branch in the svn (newterm)
« Reply #44 on: February 23, 2010, 06:23:50 AM »
I didn't see an update in SVN, so I didn't implement these changes myself baring your latest code. Here is how I would add periodic service...

Code: [Select]
void UARTstart(void){
//open, start bridge
//start
//UART2Enable();
    U2STA &= (~0b10); //clear overrun error if exists
uartSettings.eu=1;//open uart
modeConfig.periodicService=1;//start periodic service calls
bpWline(OUMSG_UART_LIVE_DISPLAY_ON);
}

void UARTstop(void){
//close bridge
//UART2Disable();
uartSettings.eu=0;// uart
modeConfig.periodicService=0;//start periodic service calls
bpWline(OUMSG_UART_LIVE_DISPLAY_OFF);
}

Add individual functions for these to uart.c

Code: [Select]
#ifdef BP_USE_HWUART
,
{ UARTStart, // start
UARTStart, // startR
UARTstop, // stop
UARTstop, // stopR
UARTwrite, // send
UARTread, // read
nullfunc1, // clkh
nullfunc1, // clkl
nullfunc1, // dath
nullfunc1, // datl
nullfunc1, // dats
nullfunc1, // clk
nullfunc1, // bitr
UARTmacro, // macro
UARTsetup, // setup
UARTcleanup, // cleanup
"UART" // name
}

Add call those function in buspiratecore.c from the start and stop reference.

Code: [Select]
typedef struct _proto {
void (*protocol_start)(void);
void (*protocol_startR)(void);
void (*protocol_stop)(void);
void (*protocol_stopR)(void);
void (*protocol_send)(unsigned int);
void (*protocol_read)(void);
void (*protocol_clkh)(void);
void (*protocol_clkl)(void);
void (*protocol_dath)(void);
void (*protocol_datl)(void);
void (*protocol_dats)(void);
void (*protocol_clk)(void);
void (*protocol_bitr)(void);
void (*protocol_macro)(unsigned int);
void (*protocol_setup)(void);
void(*protocol_periodicservice)(void);
void (*protocol_cleanup)(void);
char protocol_name[8];
} proto;

Add a periodic service function.

Code: [Select]
//send the periodic service command to the current protocol
//allows to check UART for async RX bytes, etc, independent of user input
if(modeConfig.periodicService==1){
                      protos[bpConfig.busMode].protocol_periodicservice();
}

Reinstate the periodic service function in the main loop. I'm not sure of the scope there though.

Code: [Select]
// cvd: Better to use a ISR to service this?? only the
if(modeConfig.periodicService==1)
{
                      protos[bpConfig.busMode].protocol_periodicservice();
}

I saw that you already had this in the userservice loop, so I'm probably missing part of the picture.