Re: [avrdude-dev] Avrdude Gui problem

[Ville Voipio]

First of all, let me emphasize I am strictly talking about the factory
floor. Whatever I say is not intended as a criticism against what is
being done. Someone, however, just said the magic words "factory floor",
which triggered my interest.

---

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

Almost. But what I think is missing in the ELF file is the possibility
to include written instructions plus pictures in a helpfile-like manner.
The point here is that on the factory floor the people do not
necessarily know where to put the programming connector, how to sequence
the power, etc.

Anything goes, HTML, even PDF which then opens in another program, etc.

This is a question that should not arise with embedded developers in the
lab, as usually we try to remember where and which way we have put the
programming connector. And if we make a mistake, we suffer, not others.

If the GUI has no such possibility, the only other alternative I know od
is having written, printed, laminated instructions on the table next to
the computer. In the subcontracting world every batch seems to be
programmed by a different person.

---

> 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).

Ok. This sounds like a very good reason. (And, yes, in general I like XML.)

---

> 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.

I know, I know. I was just dreaming. (As I am the poor bastard who has
to make the friggin' pig you just described.)

---

To summarize: If you want to be able to use the GUI on the factory
floor, there are three factory-floor-specific things which need to be there:

1. A simple interface (not too many buttons or choices to confuse people.)

2. The possibility to attach written instructions with pictures.

3. The possibility to embed serial numbers into flash/eeprom.

---

> 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.

I vote for this approach. Statically linked libraries would make me
happy. They are easier from the distribution point of view, and in this
case the library should be so small in terms of size and memory
footprint that there should be no problems. (And also, there should be
only one at a time running, anyway.) Fighting with all sorts of dll's,
so's, and dylib's is not worth the trouble, IMHO.

- Ville