new branch in the svn (newterm)

[Sjaak]

no problem, but i didn't saw the reason why it coexist. Now i see. :)

[Sjaak]

I needed to test the SPI library with the newterm branch. I had a nice display from a dead Siemens phone (optipoint 500 something). It uses a KS0074 display (which is an sortof SPI version of the good old HD44780). I found the datasheet http://www.chipdocs.com/datasheets/datasheet-pdf/Samsung-Electronic/KS0074.html and some example code on the internet http://www.schorsch.at/content/view/25/1/lang,de/ (sorry only german is available). During the testing i found out the buspirate spits out the bits the other way around then in the code/datasheet. As the old firmware has also the same error i assume it is ok. Pictures at my rig: http://www.xs4all.nl/~cdongen1/IMG_9541_.jpg and the final result: http://www.xs4all.nl/~cdongen1/IMG_9543_.jpg (large picture alert!).

here is the actions and descriptions, for exact details refer to the datasheet:

(note this uses some new commands!! and is not 100% compatible with the old syntax!!)

first setup SPI:

Code: [Select]

m 5 4 1 2 1 1

enable pullups:

Code: [Select]

P

enable voltage regualtors

Code: [Select]

W

display init and clear screen:

Code: [Select]

[ 0xf8 0xf0 0x00 0x80 0x00 ]

switch to normal input

Code: [Select]

[ 0xfa

text 1st line:

Code: [Select]

0x40 0x20 0xa0 0xa0 0xc0 0xa0 0x00 0xa0
0x90 0x20 0x40 0xa0 0x80 0x20 0x20 0xa0
0xa0 0x20 0x00 0x40 0xf0 0x20 0x70 0x20
0x00 0x40 0x60 0xa0 0x30 0x20 0xe0 0x20
0xa0 0x20 0xb0 0x20 0x80 0xc0 0x00 0xc0
0x40 0xc0 0x80 0xc0 0x80 0x40 0x80 0x40

cs low:

Code: [Select]

]

program a diode to chram pos 0x00:

Code: [Select]

[ 0xf8 0x00 0x20 ]
[ 0xfa 0x20 0x00 0xf0 0x80 0xf0 0x80 0x70 0x00 0x70 0x00 0x20 0x00 0xf0 0x80 0x20 0x00 ]

program an antenna to chram at 0x01 (no need to set address again)

Code: [Select]

[ 0xfa 0x80 0x80 0x50 0x00 0x20 0x00 0x20 0x00 0x20 0x00 0x20 0x00 0x00 0x00 ]

move to second line:

Code: [Select]

[ 0xF8 0x00 0x30 ]

display something on line 2

Code: [Select]

[ 0xFa 0x00 0x00 0x80 0x00 ]

log from hyperterminal:

Code: [Select]

Bus Pirate v3
Firmware v4.2 (newterm-r296)  Bootloader v4.1
DEVID:0x0447 REVID:0x3043 (B5)
http://dangerousprototypes.com
HiZ> m 5 4 1 2 1 1
SPI ( 3 0 1 0 1 )

READY
SPI> P
Pull-up resistors ON
SPI> W
POWER SUPPLIES ON
SPI> i
Bus Pirate v3
Firmware v4.2 (newterm-r296)  Bootloader v4.1
DEVID:0x0447 REVID:0x3043 (B5)
http://dangerousprototypes.com
*----------*
POWER SUPPLIES ON
Voltage monitors: 5V: 5.00 | 3.3V: 3.35 | VPULLUP: 4.98 |
a/A/@ controls AUX pin
Open drain outputs (H=Hi-Z, L=GND)
Pull-up resistors ON
Bitorder configuration not allowed
*----------*
SPI> [ 0xf8 0xf0 0x00 0x80 0x00 ]
CS ENABLED
WRITE: 0xF8
WRITE: 0xF0
WRITE: 0x00
WRITE: 0x80
WRITE: 0x00
CS DISABLED
SPI> [ 0xfa
CS ENABLED
WRITE: 0xFA
SPI> 0x40 0x20 0xa0 0xa0 0xc0 0xa0 0x00 0xa0 0x90 0x20 0x40 0xa0 0x80 0x20 0x20 0xa0 0xa0 0x20 0x00 0x40
 0xf0 0x20 0x70 0x20 0x00 0x40 0x60 0xa0 0x30 0x20 0xe0 0x20 0xa0 0x20 0xb0 0x20 0x80 0xc0 0x00 0xc0 0x40
0xc0 0x80 0xc0 0x80 0x40 0x80 0x40
WRITE: 0x40
WRITE: 0x20
WRITE: 0xA0
WRITE: 0xA0
WRITE: 0xC0
WRITE: 0xA0
WRITE: 0x00
WRITE: 0xA0
WRITE: 0x90
WRITE: 0x20
WRITE: 0x40
WRITE: 0xA0
WRITE: 0x80
WRITE: 0x20
WRITE: 0x20
WRITE: 0xA0
WRITE: 0xA0
WRITE: 0x20
WRITE: 0x00
WRITE: 0x40
WRITE: 0xF0
WRITE: 0x20
WRITE: 0x70
WRITE: 0x20
WRITE: 0x00
WRITE: 0x40
WRITE: 0x60
WRITE: 0xA0
WRITE: 0x30
WRITE: 0x20
WRITE: 0xE0
WRITE: 0x20
WRITE: 0xA0
WRITE: 0x20
WRITE: 0xB0
WRITE: 0x20
WRITE: 0x80
WRITE: 0xC0
WRITE: 0x00
WRITE: 0xC0
WRITE: 0x40
WRITE: 0xC0
WRITE: 0x80
WRITE: 0xC0
WRITE: 0x80
WRITE: 0x40
WRITE: 0x80
WRITE: 0x40
SPI> ]
CS DISABLED
SPI> [ 0xf8 0x00 0x20 ]
CS ENABLED
WRITE: 0xF8
WRITE: 0x00
WRITE: 0x20
CS DISABLED
SPI> [ 0xfa 0x20 0x00 0xf0 0x80 0xf0 0x80 0x70 0x00 0x70 0x00 0x20 0x00 0xf0 0x80 0x20 0x00 ]
CS ENABLED
WRITE: 0xFA
WRITE: 0x20
WRITE: 0x00
WRITE: 0xF0
WRITE: 0x80
WRITE: 0xF0
WRITE: 0x80
WRITE: 0x70
WRITE: 0x00
WRITE: 0x70
WRITE: 0x00
WRITE: 0x20
WRITE: 0x00
WRITE: 0xF0
WRITE: 0x80
WRITE: 0x20
WRITE: 0x00
CS DISABLED
SPI> [ 0xfa 0x80 0x80 0x50 0x00 0x20 0x00 0x20 0x00 0x20 0x00 0x20 0x00 0x00 0x00 ]
CS ENABLED
WRITE: 0xFA
WRITE: 0x80
WRITE: 0x80
WRITE: 0x50
WRITE: 0x00
WRITE: 0x20
WRITE: 0x00
WRITE: 0x20
WRITE: 0x00
WRITE: 0x20
WRITE: 0x00
WRITE: 0x20
WRITE: 0x00
WRITE: 0x00
WRITE: 0x00
CS DISABLED
SPI> [ 0xF8 0x00 0x30 ]
CS ENABLED
WRITE: 0xF8
WRITE: 0x00
WRITE: 0x30
CS DISABLED
SPI> [ 0xFa 0x00 0x00 0x80 0x00 ]
CS ENABLED
WRITE: 0xFA
WRITE: 0x00
WRITE: 0x00
WRITE: 0x80
WRITE: 0x00
CS DISABLED
SPI>


[ian]

Fantastic.  Great pictures too! May I post this as a demo tomorrow?

[Sjaak]

Sure no problem!

Only this syntax only works on the newterm! (i'll update svn later on, after i tested/bugfixed i2c)

[Sjaak]

I2C seems also fine:

Code: [Select]

HiZ> m 4 1
I2C ( 0 )

READY
I2C> P
Pull-up resistors ON
I2C> W
POWER SUPPLIES ON
I2C> ]
I2C STOP BIT
I2C> [ 0xa0 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff ]
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x00 ACK
WRITE: 0xFF ACK
WRITE: 0xFF ACK
WRITE: 0xFF ACK
WRITE: 0xFF ACK
WRITE: 0xFF ACK
WRITE: 0xFF ACK
WRITE: 0xFF ACK
WRITE: 0xFF ACK
I2C STOP BIT
I2C> [ 0xa0 0x00 [ 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> [ 0xa0 0x00 0xaa 0xaa 0x55 0x55 0x55 0x55 0xaa ]
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x00 ACK
WRITE: 0xAA ACK
WRITE: 0xAA ACK
WRITE: 0x55 ACK
WRITE: 0x55 ACK
WRITE: 0x55 ACK
WRITE: 0x55 ACK
WRITE: 0xAA ACK
I2C STOP BIT
I2C> [ 0xa0 0x00 [ 0xa1 rrrrrrrr ]
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x00 ACK
I2C START BIT
WRITE: 0xA1 ACK
READ: 0xAA
READ:  ACK 0xAA
READ:  ACK 0x55
READ:  ACK 0x55
READ:  ACK 0x55
READ:  ACK 0x55
READ:  ACK 0xAA
READ:  ACK 0xFF
NACK
I2C STOP BIT
I2C>

This is btw a 24lc02B. I noticed I need to send a stop condition after powerup, otherwise the chip won''t respond. I noticed that you also typed an extra stop condition in the other topic (on the i2c dongle). Is this necessary or need this chip to be synchronised to the bus?

Tonight I'll update svn. I think it is fairly finished by now and should be functionalitywise compatible with the old code, besides some syntax changes.

[ian]

The extra stop is just a precaution. It might also be needed if the pins aren't in the correct state when it starts (though that should be ensured by the library).

Looks great. Should I put up a post for alpha testers? I look forward to seeing the code. I should have time help with this now that the SUMP PUMP firmware is finished.

[Sjaak]

I tried to add a jump to I2Cstop into the init, but i hasn't any effect. It is logical it didn't work because the device wasn't powered up.

You think it is ready for alphabetatesting?

I just checked r319 in.

All the basic protocols (1wire, uart, i2c, spi, sump and all the binmodes (nothing changed there) should work.

todo (not limited to this list :):
- port the remaining protocols to new structure (are they all needed?)
- move the newly used textstrings  to the textlibrary
- fix liveio uart
- fix the remaining bugs :D

[ian]

There are a few fixes I've implemented into the current v4.1 source trunk. I'll try to go through the change log and apply then to the newterm tomorrow. After that, I'm sure there's lots of people who would be interested to at least try the newterm version and give us some feedback.

[Sjaak]

Shall I then upload an hex? Or you want to apply the changes before (sorry for messing up the svn revisions :$)

The commandusage is posted somewhere in this topic, please post that along with it. I haven't changed the textlibrary at all.

I'm curious for the reactions.

[ian]

http://code.google.com/p/the-bus-pirate/source/detail?r=285
http://code.google.com/p/the-bus-pirate/source/detail?r=310

I'm going to apply these two changes to your branch, then compile for testing.

[ian]

285 was already done. I implemented the other changes and added binary mode includes in procmenu.c to get rid of the errors (and enable binmode features).

My compile is here:
http://code.google.com/p/the-bus-pirate/source/browse/trunk/firmware/v4-nightly/BPv3%26v2go/BPv3-Firmware-v4.X.newterm.hex

I'm going to test it now. I'm also going to compile and test the v4.3 bootloader.

[Sjaak]

It was/is based on r296 so you're right. I thought it did compile (with a little complaint from the compiler)..

Does the binmode and SUMP modes as expected?

I updated the SVN:
I readded the check you removed in I2C with the proper display and also uploaded the buspiratecore.c (i somehow forgot yesterday :S ) r2w and r3w should also work.

What do you think of displaying the settings after 'quickset' it? Should I display the values entered (by reading the appropriate global variable) or the result in the global variable?

[ian]

Sorry, I thought that code was unneeded because it wrote to the spisetting.xxxx struct. If the HW_I2C define was enabled there is an error on that line.

I have not tried the binmode or SUMP yet, only the terminal, which is very nice. I'll test the others tomorrow.

What about showing the 'i' info menu after a quick set?

I think it might be good to make a v4.2 firmware release and then start this as a v4.4 branch? That gives us v4.3 if I still need to release another update before newterm is done.

[Sjaak]

You were correct, but i replaced it with the intended code ;) A bit of sloppy copy/paste thing

Code: [Select]

#ifdef BP_USE_I2C_HW
  bpWdec(i2cmode); bpSP;
#endif

I think 'i' provide to less info; ie. it doesn't display the speed setting or the i2c mode. I think you should check whether the setting are as intended. Perhaps add a sub in each protocol to display the settings? Could be very size hungry i suspect.

[Sjaak]

Another update to the svn:

- Altered the pwm/frequency generate to use the new getnumber (which now accepts number of 4 digits)
- Added quickset to baudrate, output and PWMgenerate.
- some cosmetic changes.
- added more descriptive return message after quickset mode (e.g. :

Code: [Select]

HiZ> m 5 4 1 2 1 1
SPI (spd ckp ske smp hiz)=( 3 0 1 0 1 )
SPI>

This spits out the global vars after they have been set (in general: the value entered-1, except for HiZ mode)

Also added the firmware to try: http://code.google.com/p/the-bus-pirate/source/browse/trunk/firmware/v4-nightly/BPv3%26v2go/BPv3-Firmware-v4.X2.newterm.hex

I'm open for comments ;)