Since Ian started already releasing v5.2, I jumped also on the wagon:
I just commited r410, nothing much, but added:
- baudrate can be manually set for pcside (uart1) and protocol (uart2)
- display warning when the speed of uart2 is faster then uart1
- updated the firmware display string
here is a 'screenshot':
HiZ> i
Bus Pirate v3a
Firmware v5.2RC (r410) Bootloader v4.1
DEVID:0x0447 REVID:0x3043 (B5)
http://dangerousprototypes.com
HiZ> b
Set serial port speed: (bps)
1. 300
2. 1200
3. 2400
4. 4800
5. 9600
6. 19200
7. 38400
8. 57600
9. 115200
10. BRG raw value
(9)> 10
Enter raw value for BRG
(34)> 68
Adjust your terminal and press space to continue
HiZ> m 3
Set serial port speed: (bps)
1. 300
2. 1200
3. 2400
4. 4800
5. 9600
6. 19200
7. 38400
8. 57600
9. 115200
10. BRG raw value
(1)> 10
Raw value for BRG (MIDI=127)
(34)> 34
Data bits and parity:
1. 8, NONE *default
2. 8, EVEN
3. 8, ODD
4. 9, NONE
(1)>
Stop bits:
1. 1 *default
2. 2
(1)>
Receive polarity:
1. Idle 1 *default
2. Idle 0
(1)>
Select output type:
1. Open drain (H=Hi-Z, L=GND)
2. Normal (H=3.3V, L=GND)
(1)>
WARNING: Possible bufferoverflow
Ready.
UART>
I haven't added a nightly or made it final since (at least) Ian also has some things to add.
I wanted to add the improved i2c sniffer posted in the forums, but there wasn't enough room for it. Prolly better to overwrite the existing one instead of using this one along with the current (dunno yet what to do)
Here's the list of things I'm going to address after finishing the morning support rounds:
*SPI resync
*power supply short detect
*PWM/power in HiZ mode
*Unify pause/continue/reset message and function
*turn bpConfig.vregen variable to a pseudo function that reads the vregen pin state instead
In another thread someone mentioned issuing a warning in I2C if the Bus didn't match the start/stop condition (slave stuck in read, holding the bus low). That might be a good addition, I'm waiting for a little clarification though.
The latest nightly has these updates:
*Fixed text formatting after ADC and Supply in self-test
*PWM and power are forbidden in HiZ
*eliminated vpullup and vreg tracking variable, all places now test the actual pin instead of storing the state and reading it. This saved about 50 program words.
1-WIRE> w
POWER SUPPLIES OFF
1-WIRE> W
VREG failed, is there a short?
1-WIRE> W
VREG failed, is there a short?
1-WIRE>
*Power supplies are now tested 2ms after W - if they are too low (short circuit) the BP throws an error and turns them off. This might help save a circuit or two. Text should be simplified and moved to the translation file.
*moved ADC pins, self-test voltage stuff to defines in base.h (should be in hardwareprofiles)
Add an 'Are you sure?' ;)
Isn't the voltage regulator protected against shortcircuit? Still 150mA could be too much for some circuits..
Here are all the 'press to x' statements in the translation file. I'm going to try to consolidate them into a single nice function that can be reused:
[s:]BPMSG1043;1;"Press any key to exit"[/s:]
[s:]BPMSG1071;1;"Sniffer, press any key to exit"[/s:]
[s:]BPMSG1134;1;"Adjust your terminal and press space to continue"[/s:]
[s:]BPMSG1178;1;"MODE and VREG LEDs should be on! Any key exits."[/s:]
[s:]BPMSG1204;1;"UART bridge. Space continues, anything else exits."[/s:]
[s:]BPMSG1206;1;"Raw UART input. Space to exit."[/s:]
[s:]BPMSG1239;1;"Input monitor, any `` exits"[/s:]
Another place we can save space is convert to the new LCD library. The current one uses an I2C chip and I think the new 74x595 version will be a lot simpler to code for (and faster over SPI).
--
Yes, they are protected. I guess my original thought was just to alert the user right away if there was a short. I always do Wv to power up and then check level to be sure there's no problems. adding a check at power on saves me a step, and reacts faster than I can to a problem. I changed the message slightly to "VREG too low, is there a short?", but I'm still not really happy with it.
Along the same lines I going to add a message that there's no pullup voltage. That might save us some grief :)
I added the vpullup check, though with the current space constraints I'm not sure it's worth it ;) We've got some thinking to do and some hard decisions to make :)
1-WIRE> ~
Self-test in HiZ mode only.1-WIRE>
1-WIRE> p
Pull-up resistors OFF
1-WIRE> P
Pull-up resistors ON
Warning: no voltage on the Vpullup pin.
1-WIRE> v
Pinstates:
1.(BR) 2.(RD) 3.(OR) 4.(YW) 5.(GN) 6.(BL) 7.(PU) 8.(GR) 9.(WT) 0.(Blk)
GND 3.3V 5.0V ADC VPU AUX - OWD - -
P P P I I I I I I I
GND 3.34V 5.01V 0.00V 0.00V L L L L L
1-WIRE>
I also corrected the line break on the self-test notice shown above.
Source cleanup. Removed lots of v0a and v2a defines (no longer supported since v3.6). Removed some v1a text warnings that are no longer needed.
Going to look at SPI resync now.
SPI sniffer now verifies start with edge interrupt (untested). Will probably need a little more work. My changes should be about here:
http://code.google.com/p/the-bus-pirate ... /SPI.c#317 (http://code.google.com/p/the-bus-pirate/source/browse/trunk/source/SPI.c#317)
I've got some other bloggy things to do now, so I will stop here and leave the unified pause statement open.
I didn't make a custom pause/continue/ext function. Instead, I swapped things around a bit.
I moved the agree() fuction to the base so everyone can use it, then used it with the UART bridge warning so it didn't need a custom message. Then I added a general any key to exit message and removed the individual ones from other text.
UART> (0)
0.Macro menu
1.Transparent UART bridge
2. Live UART monitor
3.UART bridge with flow control
UART> (1)
UART bridge
Reset to exit
Are you sure? n
UART> (2)
Raw UART input
Any key to exit
UART>
MODE and VREG LEDs should be on!
Any key to exit
Found 6 errors.
I2C> (2)
Sniffer
Any key to exit
I2C>
(1)>
Sniffer
Any key to exit
[
SPI>
KEYB> (1)
Input monitor
Any key to exit
KEYB>
KEYB> D
VOLTMETER MODE
Any key to exit
VOLTAGE PROBE: 0.00V
KEYB>
I messed this up the first time, but it is corrected in the current translation file (needs to be converted and inserted)
HiZ> b
Set serial port speed: (bps)
1. 300
2. 1200
3. 2400
4. 4800
5. 9600
6. 19200
7. 38400
8. 57600
9. 115200
10. BRG raw value
(9)>
Adjust your terminal and press space to continue
Space to continue
HiZ>
Any key works here, but it says space. Whatever.
HiZ> ~
Disconnect any devices
Connect (Vpu to +5V) and (ADC to +3.3V)
Space to continue
I think you need to keep the 'press space' (or a particular key) in the baudrate adjustment. It is used to check if the baudrate is ok.
MODE and VREG LEDs should be on!
Any key to exit
Found 6 errors.
Could you please move this to the support forum? :P :P
(9)>
Adjust your terminal
Space to continue
HiZ>
It will look like this.
A little more cleanup and minor feature updates.
I2C> (1)
Searching I2C address space. Found devices at:
I2C> p
Pull-up resistors OFF
I2C> (1)
Searching I2C address space. Found devices at:
Warning: *Short or no pull-up
I2C>
A slightly more compact format for the I2C address search. And if the bus starts out low it gives a warning and aborts instead of showing 256 addresses.
I2C> [
Warning: *Short or no pull-up
I2C START BIT
I2C> PW
Pull-up resistors ON
Warning: no voltage on Vpullup pin
POWER SUPPLIES ON
I2C> [
I2C START BIT
I2C>
If the bus is low (no pullups or contention) at the start of I2C start bit, then we report the error. You can also see the 'no pullup' warning in use. That should be stored as 'no volta....' and recycle the other 'warning'...
[quote author="ian"]
(9)>
Adjust your terminal
Space to continue
HiZ>
It will look like this.
[/quote]
I meant this message can't be a 'Press any key' You'll need to check for a particular character to be sure.
Yup, it does a loop looking for space currently. I thought about changing it so it looked for 'U' to be auto-baud compatible, but then I would have had to add another entry to the text file :p
[quote author="ian"]
A little more cleanup and minor feature updates.
I2C> (1)
Searching I2C address space. Found devices at:
I2C> p
Pull-up resistors OFF
I2C> (1)
Searching I2C address space. Found devices at:
Warning: *Short or no pull-up
I2C>
A slightly more compact format for the I2C address search. And if the bus starts out low it gives a warning and aborts instead of showing 256 addresses.
I2C> [
Warning: *Short or no pull-up
I2C START BIT
I2C> PW
Pull-up resistors ON
Warning: no voltage on Vpullup pin
POWER SUPPLIES ON
I2C> [
I2C START BIT
I2C>
If the bus is low (no pullups or contention) at the start of I2C start bit, then we report the error. You can also see the 'no pullup' warning in use. That should be stored as 'no volta....' and recycle the other 'warning'...
[/quote]
Ian,
I tried 5.2r418 this morning and the I2C changes are great. Thanks!
Randy
[quote author="ian"]
Yup, it does a loop looking for space currently. I thought about changing it so it looked for 'U' to be auto-baud compatible, but then I would have had to add another entry to the text file :p
[/quote]
What is wrong with 'Press U to continUe'? :P
0x55 is better for autobaud (it has a pulsetrain with exactly the 'baud'-frequency: 1 01010101 1)
Today I'm going to work on updating the new wiki to v5.2. I started a new command reference here:
http://dangerousprototypes.com/docs/Bus ... ions_guide (http://dangerousprototypes.com/docs/Bus_Pirate_menu_options_guide)
And I'll migrate a bunch of the smaller how-to posts there as well.
This Wiki is what DP needed, the old Google pages were awful. :)
Thanks! We /really/ need a wiki themer to come make it look nice. If anyone knows anyone, or can recruit someone, I'll pay to have it done.
I think we're missing a break between the v and f menu options:
1-WIRE> v
Pinstates:
1.(BR) 2.(RD) 3.(OR) 4.(YW) 5.(GN) 6.(BL) 7.(PU) 8.(GR) 9.(WT) 0.(Blk)
GND 3.3V 5.0V ADC VPU AUX - OWD - -
P P P I I I I I I I
GND 3.34V 5.01V 0.00V 0.00V L L L L L
Frequency on AUX pin: autorange 0 Hz
1-WIRE>
I'll try to look at it later, I want to finish the new manual now.
You do also a frequency measure when command 'v' is issued?
F does not V, but V does F, I assume it's just a missing break.
I also got a double ACK from a single byte write in I2C:
I2C> 0b1001
WRITE: 0x09 ACK ACK
I2C>
There is a statemachine in the I2C to ACK/NAK the last byte received. Basiscly if you send/receive after it, it get ACKed and with a stop/start condition it gets NACKed. The code is here for write: http://code.google.com/p/the-bus-pirate ... /I2C.c#110 (http://code.google.com/p/the-bus-pirate/source/browse/trunk/source/I2C.c#110) and here for read: http://code.google.com/p/the-bus-pirate ... e/I2C.c#80 (http://code.google.com/p/the-bus-pirate/source/browse/trunk/source/I2C.c#80)
A better message would be 'ACK last byte, got ACK'
I did a couple of tricks to get the statemachine compatible with the newterm :D
2WIRE> ^
CLOCK TICK
2WIRE> ^:12
CLOCK TICK
CLOCK TICK
CLOCK TICK
CLOCK TICK
CLOCK TICK
CLOCK TICK
CLOCK TICK
CLOCK TICK
CLOCK TICK
CLOCK TICK
CLOCK TICK
CLOCK TICK
2WIRE>
Multiple clock ticks show a line for each.
As someone already did post:
^:0]
I think that extra ACK was my fault. I used it funny to make the new excerpts for the manual update.
This does look like an extra BR after the bulk read before the NACK:
I2C> [0xa1 r:8]
Warning: *Short or no pull-up
I2C START BIT
WRITE: 0xA1 ACK
READ: 0x00 ACK 0x00 ACK 0x00 ACK 0x00 ACK 0x00 ACK 0x00 ACK 0x00 ACK 0x00
NACK
I2C STOP BIT
I2C>
Finished the update of the menu and syntax guide for v5.2:
http://dangerousprototypes.com/docs/Bus ... ions_guide (http://dangerousprototypes.com/docs/Bus_Pirate_menu_options_guide)
Also did an update of the main Bus Pirate Wiki:
http://dangerousprototypes.com/docs/Bus ... ure_guides (http://dangerousprototypes.com/docs/Bus_Pirate#Feature_guides)
I think I typed an update and forgot to hit post.
Today I rolled back the latest SPI sniffer update.
There was some double display stuff in the raw2wire ATR macros
Fixed the f after v bug (just a missing break)
Now I want to:
[s:]get rid of the extra BR before the NACK[/s:]
[s:]multiple clock ticks to print only once[/s:]
[s:]figure out the rawSPI problem with flashrom[/s:] (still exists, could not duplicate)
Did I mention:
we could roll the 2 and 3 wire libraries into one and maybe save some space?
get rid of the extra BR before the NACK <<< just a terminal width thing, not a bug.
1-WIRE> /
CLOCK, 1
ERROR: command has no effect hereSyntax error at char 1
1-WIRE> ^:10
CLOCK TICK
0CLOCK TICK
0CLOCK TICK
0CLOCK TICK
0CLOCK TICK
0CLOCK TICK
0CLOCK TICK
0CLOCK TICK
0CLOCK TICK
0CLOCK TICK
01-WIRE>
[s:]Noticed some weird stuff in the 1-wire library.[/s:]
I guess it' supposed to show the command that caused the error. I'll add the BR after the error.
I removed the repeat on /-_ because it doesn't really make sense to repeat them (maybe I'm wrong). Do we still need to test for the repeat characters if we don't allow it?
I also changed the read bit repeat to be like the read byte repeat. And changed the multiple clock ticks to this:
2WIRE> !:8
READ BIT: 0 0 0 0 0 0 0 0 *pin is now HiZ
2WIRE> ^:10
CLOCK TICKS: 0x0A
2WIRE>
Here's the fixed ATR:
2WIRE> (1)
ISO 7816-3 ATR (RESET on CS)
RESET HIGH, CLOCK TICK, RESET LOW
ISO 7816-3 reply (uses current LSB setting): 0x00 0x00 0x00 0x00
Protocol: unknown
Read type: to end
Data units: no indication
Data unit length (bits): 1
2WIRE>
It is safe to remove them. I think it is a left over from sloppy copy/paste actions ;)
Ok, thank you. I'm also doing a mini overhaul on the 1-wire library.
I changed the 1-wire library so - adn _ set the data state variable but don;t send a bit. I think this is more consistent with other bus modes, now to send four high bits use -^^^^ instead of -^^^.
I added a peek fucntion to 1-wire that returns the stored data state.
1-wire wiki was updated with notes about the change.
Next I'm going to investigate the binary SPI problem.
I did my best to find the flashrom bug but 'it works for me' and I cannot replicate any errors at all. I'll leave it until I hear more.
Interesting :D
Is it perhaps an setting in the ftdi driver?
Do you want anything else in the v5.2 before a release?
I think we polished a lot of things without introducing many errors :)
I am going to give every terminal text a once-over in the v5.3 release. There are numerous improvements in this one. I'm going add examples to the protocol documentation, and will use that opportunity to find anythign that might be improved. I'm programming on the PC now :P maybe I can make an app that convnerts the terminal text into the files automagically. I hate doing it so many times lately.
I will be working on the PIC part shortly. When robots checks in a main.c, I'm going to get it working with the rawwire extensions and test the pics/add the 16F stuff. My sure board came today, I have to pick it up at the post office tomorrow.
Maybe we can look at the I2C sniffer too? He got a much better speed but used an on-demand display method. The 4096 byte buffer should be enough to do quite a bit, maybe it wasn't implemented then.
Man I'm already working on version 6 :D (test is working quite well, need some tools though)
Well there wasn't room for the sniffer, but if we remove the old one it would fit. That texconverting thing wasn't suppose to be done every build ;) I needed a quick fix, and it worked quite well (it even is crossplatform!). It still needs some translation ;)
[s:]Shall we replace the i2c sniffer?[/s:]
Edit: the i2c sniffer is for 5.3
Yeah, sorry, I meant all that was my todo list for the 5.3 next release :) Anything you'd like to have to merged into 5.2 should probably go into SVN tonight.
I posted it up on the block. Unstickying this thread now :)
And unsticky-fied!