On Mon, Apr 12, 2010 at 1:17 AM, Joerg Wunsch <[email protected]> wrote: > The question is probably whether there is *any* known application that > really runs AVRDUDE in such an (embedded) application right now, or > can be expected in the near future. So far, I've only seen AVRDUDE > operating in classical PC (or alike) desktop environments.
It started as a discussion thread about the Bifferboard embedded device I mentioned in my first message: http://groups.google.com/group/bifferboard/browse_thread/thread/7c4835cb1773b5d4/1ae4238738a7c763?lnk=gst&q=avrdude To sum up the discussion: Ivan implemented an AVR programmer in Perl to use his Bifferboard GPIO lines to program an AVR. I suggested that it would be better to add this as part of avrdude to reuse all the MCU definitions. Biff expressed an interest and I decided to do it as an exercise during the weekend. So currently there are 2-5 potential users :). > At the least though, the patch should auto-probe to see whether the > required generic GPIO interface is available in the target system or > not, i.e. it must contain the necessary autoconf glue logic. I'm not good with autoconf, but that may be a good occasion to do some reading. I don't know if it will be possible to automatically detect this though. Usually for embedded systems you cross-compile so testing about sysfs-gpio support in the kernel of the system doing the build is not of much use. Probably a better approach would be to provide a configure option or something to enable/disable this programmer if needed. How is this usually handled for other similar cases in avrdude? This uses nothing more than file open/read/write/close functions so it should build on all platforms. If you try to use it and the expected /sys/class/gpio directory is not there it will exit with an error. _______________________________________________ avrdude-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avrdude-dev
