Joerg Wunsch wrote:
As Mike Perks wrote:
Note that the GUI design and implementation proceeds we may need to
tune or add to the API that already exists in AVRDude. ...
Agreed. I already did some changes during my initial pilot project,
like the ability to register a callback function for harvesting all
known programmers and AVR devices. It's used in the CLI to return the
list of programmers and devices for -c ? and -p ? options, in just the
same way as the former code had it as hard-coded fprintf()s. Now, the
CLI just registers a callback function that does the actual fprintf(),
while the library backend iterates over the list, and calls that
callback. A GUI frontend can then just go ahead, and register a
callback that collects the items into a GUI element, so it can offer a
dropdown menu or such to allow the user to select an AVR device and a
programmer type. Contrast that with the existing GUI efforts that all
either require hardcoded (and separately maintained lists), or try to
parse avrdude.conf on their own to gather that information, and the
advantage should be obvious.
Yep there are only so many design patterns out there and this is a
standard one. Here are the callbacks I implemented in my
front-end/back-end downloader tool:
/* level is message level where 0 is standard and 9 is über-debug data */
typedef void (*MessageCallback)(int level, const char * message);
/* status type */
#define STATUS_TYPE_FLASH 0
#define STATUS_TYPE_EEPROM 1
/* used to give a CLI or GUI thermometer display of percent complete */
typedef void (*StatusCallback)(int type, unsigned long current,
unsigned long total, unsigned long time);
I would suggest we have standard APIs for querying items. The returned
list is then formatted by the CLI or GUI for display. Trying to use
printfs after the fact is probably not a good approach. For a particular
data item we will need verbs like add, delete, get, set, and list e.g.
* ListParts
* GetPart
* AddPart (called from XML parser, not front-end)
* ListProgrammers
* GetProgrammer
* SetProgrammer
* AddProgrammer (called from XML parser, not front-end)
* ListFuses
* GetFuse
* SetFuse
* AddFuse (called from XML parser, not front-end)
* etc
I haven't read very much of the AVRDude code yet so I'm approaching this
from what I would do rather than what is there. Sometimes it is good to
have a "fresh" view of things.
Regards,
Mike
_______________________________________________
avrdude-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avrdude-dev