Hi all,
The attached file buspirate.c is an updated version of the buspirate.c found in the current avrdude trunk (which can be found here (http://http://svn.savannah.nongnu.org/viewvc/trunk/avrdude/?root=avrdude)). It includes a number of modifications mostly to do with implementing some suggestions that Ian put forward in this (http://http://dangerousprototypes.com/forum/index.php?topic=1419.0) thread.
In order of importance, here's what I would change:
1. Eliminate the reset, we'd really like to keep the confirmation (but it also might change)
2. Don't parse the command prompt. Any firmware since v2 supports binary SPI mode. On earlier firmwares AVR Dude would also have problems parsing the UI, so it couldn't report the need for an upgrade anyways. I can add a binary version string command if you feel that feature is missing.
3. Assuming the AVR uses a basic !CS/write/read/CS pattern, the new read/write command should speed up programming by 10x or more (from 12 hours on flashrom to minutes).
In the attached code I've removed the initial buspirate reset and have instructed avrdude to immediately enter binary SPI mode instead. I've removed the command prompt and header parsing entirely, as this is unnecessary if we're assuming that the firmware supports binary mode. Furthermore, I've completely removed ascii mode SPI support - although I may put this back in so that it can be enabled in the config file if needed.
The biggest change, however, is the addition of a new function buspirate_paged_write() which uses the buspirate's "Write Then Read" binary SPI command to write entire pages of flash at at once. (Use of this function is disabled in the attached buspirate.c, but can be enabled by removing the comments around
/* pgm->paged_write = buspirate_paged_write; */
in buspirate_initpgm() at the end of the file.
This new write function should speed up the writing of AVR flash memories considerably. (Test writes on small 2k ATtiny2313 resulted in a 4x speed increase.) HOWEVER, the writes using "Write Then Read" currently fail - I believe due to the fact that the existing implementation of WTR ends by raising CS. As avrdude uses CS (or AUX or AUX2 when programming more than one AVR) to talk to the AVR's reset pin, raising CS directs the target MCU to leave its programming mode and hence ignore (or misinterpret) subsequent programming instructions.
As I see it, there are two possible solutions to this problem:
- Re-enter programming mode before writing each page. I haven't had time to try this yet, but will as soon as I can.
- Modify the Bus Pirate's WTR command so that it doesn't touch CS. This might make the WTR command more generally useful, as applications that need CS to be toggled can do this themselves.
Note that as AVRs need a delay between page writes, the speed improvement that using WTR offers is limited by the page size of the flash in the particular chip. This varies between 32 bytes for the ATtinies and upwards of 128 bytes for the ATmegas.
All the best,
Tim
p.s. Once we get this working on a level everybody's happy with, I'll contact the avrdude devs and ask that they consider adding these modifications to the current development trunk.
Thanks Tim,
Here is an updated Bus Pirate firmware with new SPI binary command 0x05 - write then read with no CS state change. Maybe this will help.
It might be smart to add a w-t-r setup command, that chooses CS, no CS, or /CS instead.
Sorry, attached.
Sweet, thanks Ian. I'll give this a shot. I like the idea of a write then read setup command - if the default behaviour is to toggle CS, it'll avoid introducing any incompatibility with flashrom. (Provided adding such a command won't add too much bloat to the firmware..)
It works! The buspirate_paged_write() function now successfully writes to the flash at almost exactly 4x the speed that the old code managed. (e.g. 4s compared with 17s to write the whole 2k of flash contained in an attiny2313).
Weirdly though, with the modified firmware in place _both_ the 0x04 and 0x05 SPI binary write then read commands result in successful writes. I don't understand this at all!
Less importantly (but also weirdly), the UI of the modified firmware appears corrupted in my terminal (screen running inside xterm) while the v5.9 UI looks perfect. Did the modified firmware you posted perhaps contain some modification to the UI as well? If not, this is also very strange.
I'm pretty happy that my new code works at all though. :-)
Thanks for the update.
I tested the wrong variable, that's why CS never flipped. Thanks for the report. It's fixed now in SVN
Sjaak added some PIC stuff to the translation file last night that made the main firmware too big, I had to get rid of it and I probably didn't do the greatest job. I just wanted to get a test out ASAP. We need a better solution for the terminal text in the spit part libraries.
Ah, good. Glad I wasn't just going mad. :)
We'll have a final with all these updates (and the avrdude 5.8 fix) before the end of the week.
Brilliant! I just hope the next avrdude release isn't too far away either. (The space after the > on the prompt is definitely prettier!)
Ooh - just one tiny request: can you increment the SPI binary mode version number if you include the new WTR command?
That's a whole other can of worms :) Unknown commands always return 0x00, so you can usually use that to determine if the new command is present in the current firmware.