Some light on the first OpenOCD firmware:
The openocd gathers all the bits to be sent out on jtag (TMS, TDI) and prepares stream that looks like this:
C = Command, S = Size, D = TDI bits, M = TMS bits
C S S (D)*size (M)*size
Meaning:
First is the command id, then size in bits, TDI data, and TMS data.
1. The whole packet is sent over to BP.
2. BP then shifts out the bits, and shifts in TDO bits.
3. Finally sends bits back.
The new format and new firmware:
C S S (D M)*size
First Command id, then size in bits, and TDI data followed by TMS data, repeating as necessary (until bit count is reached)
The firmware should look like this:
1. BP receives Command id and SIZE.
2. Enable USART interrupts
3. Executes the tap_shift(), that will wait for incoming bytes.
4. When data is available (notification from ISR) shift out/in the available bits.
5. Put the TD0 data in buffer for USART_TX ISR.
6. Jump to 4 while bits remain.
7. Disable USART interrupts. (should wait untill the TX is finished)
Note: for every 2 bytes we receive, we send out 1 byte.
I don't know how is the FTDI going to handle single bytes going out. (will it cache and then send ? or just send single byte per USB packet ?)
Probably caching the output values in buffer will help.
These are just thoughts, but i would appreciate any comment on this !
Some update:
I'm finished with the second version of the firmware. (YAY ;) )
The major update is the use interrupts to transfer the data. I will soon check it into svn.
What i'm getting now is:
wrote 31840 byte from file ./stm32_menu.elf in 15.436130s (2.014349 kb/s)
Which is somewhere where i would expect it to be.
Next milestone is to add uart speed selection. Normal, and FAST (~1mbit?)
I have also added some nice features, like:
- ability to control the VREG, LED through openocd interface (telnet, commandline)
- adc readout (well just dummy numbers for now :) )
Also this new firmware is NOT compatible with older one, so if you want to try it, you need to recompile the openocd.
UPDATE:
There is a note in the patch file about the "tms_sequence" config. It seems that some interfaces cannot handle the short sequences. But my way of transferring data handles this well, and the result is
wrote 31840 byte from file ./stm32_menu.elf in 13.517923s (2.300187 kb/s)
another UPDATE:
I have switched the UART speed to 1Mbit. It does not speed up the whole thing like one would expect (8times).
In reality it is more like 2.5times
The result is:
wrote 31840 byte from file ./stm32_menu.elf in 4.879981s (6.371695 kb/s)
I'm not sure how much further I can optimize this.
I have uploaded the current firmware into SVN. If anyone wants to try it, let me know :)
I'm going to Upload the current patch for openOCD tomorrow.
One thing should be added - fallback for the serial speed, using timer. If you leave openocd there is no way to communicate with buspirate, unless you reset it.
It is past midnight (so technically it is tomorrow). I have compiled the firmware, and created patch for openocd-0.3.0-rc0.
Patch can by found here:
http://code.google.com/p/the-bus-pirate ... te-v2.diff (http://code.google.com/p/the-bus-pirate/source/browse/trunk/documents/openocd-0.3.0-rc0-buspirate-v2.diff)
Firmware to be flashed into BP is here:
http://code.google.com/p/the-bus-pirate ... OCDv02.hex (http://code.google.com/p/the-bus-pirate/source/browse/trunk/source/OpenOCD/OpenOCDv02.hex)
The source code in openocd is much cleaner, easier to maintain. There are few new config commands:
buspirate_port - specifies the port of buspirate
buspirate_speed - normal/fast, specifies the speed to which the BP should switch to (115k/1M respectively)
executable commands:
buspirate_adcs - this should readout the ADCs on the buspirate (much like the status in BP main fw) - not implemented so far
buspirate_led <1|0> - sets the state of the led on BP
buspirate_vreg <1|0> - enables/disables the Voltage regulators on BP.
Any testers and ideas are more than welcome. :)