Dave N6NZ wrote:
Right now avrdude supports CLI. It needs to have the GUI interface as
well.
You still haven't said why exactly. Other than examining and tweaking
fuse settings, programming a uCtlr just doesn't seem like a highly
interactive process to me. Describe this user and the problem a
full-blown gui solves for him. Is it simply the matter of finding the
right command line options?
Yes. One of the reasons I would like to contribute to this effort
(assuming it is organized appropriately) is that I always have to refer
to the AVRDude documentation to remember the command line options.
Perhaps this is because I use it less often than Studio or AVRProg
(shock, horror) but nevertheless a GUI will make it more approachable to
a certain user set (and some would say a larger set than the command
line only people). Arguments of "if you cannot understand the AVRDude
command line options then you shouldn't be programming an AVR" don't
hold up.
Without getting into a religious argument here but it is similar to the
discussion between using C and using assembler. I prefer C as it is more
productive and can handle almost everything I need. Now that hasn't
excluded me from examining lss files to tune code, adding some assembler
instructions for a bootloader jumptable etc. However writing assembler
is just not something I want to do everyday.
Part of good user interface design is to first examine your users and
come up with come user roles (some people call them persona). So
actually you ask a good question - what kind of people use AVRDude and
how do they use it? With a bit more time I could write up a 2 or 3
persona profiles for the different users of AVRDude(-Gui) if people are
interested.
Regards
Mike Perks
oakmicros.com
_______________________________________________
avrdude-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avrdude-dev
