David Brownell said: >> * Memory Upload: > > Various folk have asked for this. It'd only work for the > on-chip memory, but could be useful nonetheless. (Unless > you wanted to get fancy, and read the on-chip memory first, > then load new firmware that could read the external mem...)
heh. maybe later... (I don't have anything at the moment with external memory.) > Presumably you'd save the image in hexfile format? I could. Right now, my prototype code only does binary because it's simpler. You don't gain as much from hex as you do when downloading because you don't know where the memory "holes" are when reading RAM. >> * Register readback: > > I thought only the reset bit in CPUCS was supposed to be > available? If that's not so, then sure -- have a way to > dump that info. I saw this in the AN2131 TRM: "The CPUCS register is the only USB register that can be written using the Firmware Download command." Call me optimistic, but it doesn't say you can't read that register :-) I'll give it a try, anyway. > In general, it's worth avoiding multiple code paths. If "libusb" > will do the vendor control messages, just use it everywhere; it'll be > simpler to maintain/debug that way. OK. > Those "development-oriented" features could just be #ifdeffed when they > get merged back. It's not like they'd take lots of memory, except maybe > for the "two stage read-from-RAM" case. Though another program would be > fine too. (Maybe "fxdevel"? Since "fxload" also has a > control function.) Sounds good. Thanks for the input. -- Charles Lepple <[EMAIL PROTECTED]> http://www.ghz.cc/charles/ ------------------------------------------------------- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
