Re: [avrdude-dev] Avrdude Gui problem

[Joerg Wunsch]

(Well, quite a bit of discussion during my night hours...)

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.


As Ville Voipio wrote:

> It would be nice, if the factory-floor program could use a .zip with
> all the files (binaries, fuse settings, instruction files) so that
> sending a single file to the subcontractor would suffice.

That's what the combined ELF file is intended for.

> XML is nice, but it might be that a script-like file could be better
> at this point. avrdude has already defined many of the required
> instructions, it only needs a few extensions: serial number handling
> and probably some GUI error messages (i.e. error handling).

You're missing the point that triggered me to think about moving to
XML this time: adding Xmega support will require a lot of additions.
By the same time, the current way of adding a new device is *way* too
expensive (in terms of the time it takes for the respective
developer).

> Oh, and if someone is really going to make such a tool, please try
> to keep it open for extensions (not toot tightly bound to avrdude
> API). I'd love the AVR programming tool but kill for such a tool if
> it could also program ARMs and CPLDs through the JTAG connection. I
> may not be the only one...

That's going to be an Eierlegende Wollmilchsau then, as the Germans
would call it.  (Translation: an egg-laying wool milk pig) IOW, it
will take forever to complete, I'm afraid.


As Mike Perks wrote:

> I have had good success with wxWidgets and the advantage here is
> common code for all platforms.

That's been my motivation to once start that way.

OTOH, there's certainly more available down that road.  Qt quickly
comes to mind, for example.

> The only thing different is the serial port code.

That's already abstracted in the AVRDUDE layers, so nothing the
frontend has to worry about.

> However for AVRDude it may make sense to separate out the back-end
> into a dynamic library (DLL or .so file) so that anyone can write
> their own front-end if desired.

A shared object that is not really shared by more than a couple of
applications is just producing more work than it gains.  I don't see
any advantage of that approach, compared to offering a traditional
library that can be statically linked.  If there really were a couple
of other efforts to provide different frontends (and be it privately
used ones only, that serve a very special purpose on some factory
floor of whatever), we could always offer to actually install that
library and its header files describing the API.  So far, I didn't do
that though as it will certainly require some more thoughts, a cleanup
of the header file, and an API that is really stable enough.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)