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 _______________________________________________ avrdude-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avrdude-dev
