On Fri, 22 Apr 2011 05:08:32 +0200 Peter Stuge peter@stuge.se wrote:
right now my plan is the following: an avr atmegaXXu2 is connected via usb and implements the serprog protocol
Please do not! Make good use of USB and design a protocol that actually takes advantage of relevant USB features, instead of pretending that USB is a serial port, which is really lame.
what features do you think _are_ relevant? sure serprog is pretty stupid, but that has nothing to do with its serial property. :)
At a very minimum translate the serprog protocol to native USB.
USB is a packet bus. Making it behave like a dumb stream of bytes is almost never a good idea.
if i had to transfer the content of a file i would choose tcp instead of udp. this is quite similar imho. of course factoring out the control messages is useful, but there are several drawbacks: - we cant tunnel it as easily (e.g. over tcp like serprog) - everything gets way more complicated on the microcontroller
i dont see a lot of performance improvements from it either. dropping cdc and just stream our own protocol via usb's bulk endpoints would be fine with me. i have already done this once. maybe i am missing something though. please layout your basic ideas how an USB flashing protocol should look like, what it could do (what serprog or something similar could not (as easily)).
btw do we want to support non-spi flashes at all?
Also, make a simple HAL for the AVR, so that your C firmware can be re-used with other processors. I'll make it run on LPC1342/43.
sure. spi reads, writes and cs(/hold?/wp?) will be independent. atm i am extending serprog and character reads and writes from the serial stream are basically independent. i do use avr-specific printfs though (those fetch the strings from flash memory instead of ram... harvard architecture, which is not abstracted), but that can be dealt with if need be.
without any level shifting.
Yes, is a good feature.
it costs performance in the case of the avr though... about 8MHz maximum clock instead of 16 with vcc>=4.5V.
i was also thinking about an offline mode which uses an SD-card or another flash to store/load an image for the target flash.
SD is not worth the effort. SD cards are very incompatible and it takes a lot of work to implement a well-functioning card reader.
thats true, i have tried ;)
And the filesystems are buggy as well.
we would not need one... wear leveling is done by the card and we only need a continuous block.
A second flash chip could be handy for offline mode - but what is supplying the power?
a usb power supply for example :) adding another connector for other power supplies wouldnt be a problem either.
BUT.. since there is not really interest in _my_ new flasher anyway and everyone seem to have built his own, i think we should just concentrate on the usb protocol.