new branch in the svn (newterm)

[Sjaak]

Hi,

I have rewritten the main loop that interfaces the user with all the protocols. The handling of the userinput is a bit more flexible and is easier to extend (at least I think) It uses a ringbuffer (256 bytes for now) for userinput, in which the main sub filters all the commands the user types and executes them sequentially (in theory (not fully implemented yet) it is possible to set the mode from HiZ-mode write some config regs and read back some responses in just one line). It also provides a (simple) history function (command 'h') to replay the last 15 commands (if not overwritten by long commands). It implements the protocol implementation as subs so it eliminates the double case statement (should speed things a bit up) Also as a bonus it can now send a string to the protocol send sub (here you go Ian!!)

some commands were changed a bit:

Code: [Select]

commands:

h history
? help
i info
m <CR> choose mode from menu
m 1..9 choose mode directly (planned to also set protocol settings)
b baudrate menu
b 1..9 baudrate directly (unimplemented yet)
o dataoutput menu
o 1..3 dataoutput directly (unimplemented yet)
v check powersupply
f freq count
g freq generate
c aux pin assignment (aux=aux)
C aux pin assignment (aux=cs)
l lsb bit order
L msb bit order
p pullup resistor off
P pullup resistor on
= [val] display val in dec,hex and binary
~ selftest
# reset
$ goto bootloader
a AUX low
A AUX hi
@ read AUX
W psu on
w psu off
d read adc
D read adc continuosly
& delay
(val) execute macro val
"abc" send abd as string :P
[ start
{ start with read
] stop
} stop
0..65535
0x0000-0xFFFF
0b0 send byte (stored internally as an unsigned int) (0h not yet implemented)
r read a byte
/ clk hi
\ clk lo
- dat hi
_ dat lo
. dat state read
^ clock pulse
! bit read


I only rewriten 1-wire, UART and SPI yet. The other protocols needs to be converted to the new style. This should be easy, but it is already getting late.. So i put them on my todo list.

As with all my code, it comes with no warranty!! it still has some sharp edges and is not fully tested (especially the protocols!) Also it needs a lot of cleaning up. If you use your buspirate for serious/lifsaving stuf please use the main release and don't upgrade!!

It doesn't have SUMP and binio implemented yet (also on the todo list, as many otherf things.. :( )

[EGHM]

Cool.  I read a bit of r307.  I was thinking it may have been a bit easier to follow the initial changes if newterm had first been committed with the existing version of the files and then the next commit the changes you made.  Using TortoiseSVN I copied the existing files into newterm and used diff just reading in the other direction to follow along.  No huge deal, maybe next time?  It certainly doesn't decrease my appreciation of your contributions to the project.  Thanks.

[ian]

Great job. I'm going to give this a try now.

Hey... + is a secret :p (just kidding)

[Sjaak]

@EGHM: When I started to write the new backbone it was at r296  and i took me quiet a while to figure some things out. there aren't many changes since that release, so i don't care for now. I was just busy getting it in the svn and more or less bugfree.. Later on we can synchronize it with the normal trunk (in case we gonna use it)

I misunderstand you. Next time I should learn how to use SVN. Sorry for that!!

@Ian: Which + ? :P

[ian]

The + that activates the easter egg and... Ok, I just noticed that you took it out :) It wasn't much of a secret...

I just reviewed and compiled the newterm version, I'm going to try it now.

I made one minor change: The pullup switch should warn, but not prohibit, activation when pins are active. As a general design guideline I never prevent a possible use, you never know what someone's using it for. The exception if HiZ mode, it's 'safe' so no output is allowed.

I really like the structure. It's very readable and workable. It's one long stretch of code, but it adds lots of flexibility over the older way.

[ian]

I made one minor change: The pullup switch should warn, but not prohibit, activation when pins are active.

I'm sorry, I read the code incorrectly.

Code: [Select]

//don't allow pullups on some modules. also: V0a limitation of 2 resistors
if(modeConfig.allowpullup==0)
{ bpWmessage(MSG_ERROR_MODE);
}
else
{
if(modeConfig.HiZ==0){bpWmessage(MSG_ERROR_NOTHIZPIN);}
BP_PULLUP_ON(); //pseudofunction in hardwarevx.h
bpWmessage(MSG_OPT_PULLUP_ON);
}

I added the if(modeConfig.HiZ==0){bpWmessage(MSG_ERROR_NOTHIZPIN);} so it warns that the pins are in active mode not hi-z mode.

I think allowpullup is a worthless variable. All modes (as far as I can tell, except HiZ) allow pullups, so why not just test if mode!=HiZ? I think this is garbage left over from when not all modes supported HiZ pin types (UART was the last to be converted).

I really like the history, fantastic. I'd like to add VT100 arrow support eventually, so you can scroll through with the up/down keys.

A few other items (you said it's not finished, so I'm not worried at all):
Is the extra space after the prompt intentional?
Is it possible to restore the default option that was shown in ()> at the prompts?
Can we have a record of the actions taken when multiple commands are processed (for debugging)? m 2 m 3 m 4 shows the init for the UART, but then jumps into the I2C mode.

[Sjaak]

- i copied most of the hw code into the new structure, so it should be (mostly :D) compatible.
- the extra space is intentional
- display the default option is no problem
- m 2 (or m 0b10 :P) jumps to the first protocol (1wire?), after that it encounters m 3 (uart with questions) inits that and m4 (i2c?) finally executes. multiple mode changes shoudl be prohibited i think.

using one loop prevents also from using a 'command' twice (like the jump to bootloader).

[Sjaak]

Did a couple of improvements to the newterm branch.

- Added default input indicator (the text *default should be removed from the translation.h then btw!)
- Discarded input after mode change.
- Added the check in pullups (see ian's post, but i don't see the benefit? I think it's better to check for HiZ mode)
- Added setting modeConfig.pullupEN and modeConfig.altAUX so the settings show up correctly in 'i' menu
- settings for modes (like speed etc) can be set commandline (see screenshot)

One screenshot says more then thousand words:

Code: [Select]

Bus Pirate v3
Firmware v4.2 (newterm-r296)  Bootloader v4.1
DEVID:0x0447 REVID:0x3043 (B5)
http://dangerousprototypes.com
HiZ> m 5
Set speed:
 1. 30KHz
 2. 125KHz
 3. 250KHz
 4. 1MHz

(1)> 4
Clock polarity:
 1. Idle low *default
 2. Idle high

(1)> 1
Output clock edge:
 1. Idle to active
 2. Active to idle *default

(2)> 2
Input sample phase:
 1. Middle *default
 2. End

(1)> 1
Select output type:
 1. Open drain (H=Hi-Z, L=GND)
 2. Normal (H=3.3V, L=GND)

(1)> 1
READY
SPI> m 1 m 2
READY
HiZ> m 5 4 1 2 1 1
READY
SPI> m 1
READY
HiZ> m 0b101 0b100 0b1 0b10 0b1 0b1
READY
SPI>

Still only HiZ, 1wire, UART and SPI are converted. (Could someone test these proto if they work as expected??) Other protocols will be converted later

Ps. the last line is just because we can (it is a pleasant(?) side effect)

[ian]

Great job. I'll load it up and do some testing today.

[ian]

I'm running some tests:
*1-wire works OK
*UART read and write work, but it doesn't report failure to read when the UART is empty.
*No message on UART live IO (with { or [), and live IO doesn't seem to work (no period service routine?)
*Uart macros look OK
*Hi-Z allows reads and write, other syntax commands, shows read/write message.
*Need line feed after syntax error at warning
*SPI read and write seem fine

Architecturally, I like your approach a lot. It simplifies. I like the consolidation of terminal text to the single function. The arrays of function pointers are exactly what I had in mind when I've thought of changes. I like how the protocol libraries have less control code.

I'm worried about custom message handling though. For example the I2C ACK and NACK reports and state machine tracker output. I'm not sure how that can be handled.

[Sjaak]

Thanks!

When this is working I'll get into the displaysystem (got some ideas which save a lot of bytes)

I'll look into the UART subsys later on. The I2C lib is something I'm not sure about (which I avoided on purpose ;)), but with some global vars the statemachine can be done. I'll also fix the error thing.

[Sjaak]

new release in the svn, fixed the following things:

- added a crlf after an error
- added the failure on reading from empty uart
- added i2c support (state machine implemented as before?)
- reading,writing in HiZ raises an error. this also catches unimplemented features in the protocols

I didn't add the {[ to the uart, because i thought macro 1 or 3 would tackle it. I think the implementation as it was is prone to buffer overflow (only after an enter on the cmdline it service the uart receive buffer) If it is needed we should go for a timer isr imo.

things to do (after smashing the bugs) :
- convert jtag, 2wire, 3wire, keyb and lcd to new structure
- implement binmode and sump (implement as mode instead?)
- add cmdline config to i2c, uart
- cleanup

Please let me know if I forget something :D

[ian]

Thanks for the update, I'll give it a try today. Periodic service on a timer interrupt sounds fine.

SUMP has to enter in the same way, it's a hack to work with an unmodified SUMP client.

The binmode also needs to stay the same, there's 4 or 5 apps, plus lots of scripts, that use the existing entry method.

[Sjaak]

Do we need it? UART is the only lib that uses it, and I think the macro's do the same?

Ok for SUMP and Binmode.

[ian]

Since UART is async it's nice to be able to get data as it arrives. The macros do the same thing, but you can't interact with it at the same time. My main concern is keeping it pretty consistent with the existing demonstrations.

You're doing a ton of work on this, if this is an item you don't want to deal with, that's totally  fine. I can take care of it later :)