I have a few new feature ideas for fxload, and I was wondering if there is a preferred branch naming convention for linux-hotplug. A lot of folks tend to use uppercase for the branch names, and in the absence of any other suggestions, that's what I'll probably use.
OK by me.
* 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...)
Presumably you'd save the image in hexfile format?
* 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.
* cross-platform libusb support:
As previously discussed with David and Greg, I'd also like to add optional libusb support so that fxload isn't just tied to Linux. This one opens a bigger can of worms.
Since any current system which uses fxload will most likely have access to the usbfs device tree, I don't want to introduce an artifical dependency on libusb. The selection logic could all be crammed into the Makefile, but I was wondering how the other developers would feel about a simple autoconf script. Defaults could go either way, but my preference would be to have ./configure enable libusb support if libusb-config is installed, but have RPM .spec files explicitly disable libusb support when it is not required.
Thoughts?
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.
Since there is a valid argument for preventing feature creep on the core fxload executable (to keep hotplug scripts quick), at some point it may be desirable to split off any new debugging features (RAM upload, register readback) into another executable (fxcontrol or something).
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.)
- Dave
-------------------------------------------------------
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
