On Sunday 07 June 2009, Duane Ellis wrote: > So what should we focus on? > > (A) Wizard type features to help *new*users* get started > > (B) Day to day operational features. > > I think your view is more (A), and mine is more (B).
Yet my example of a "flash download" tool seems more like (B) to me. :) Keep in mind also that while some "day to day" users are using GDB-over-JTAG to develop microcontroller software, others have more limited and infrequent demands, like de-bricking or (similar) installing new boot loaders. And I'd say that the former will be getting deeply familiar with command line tools, of necessity ... the latter are the ones most in need of the kind of "low learning overhead" interface which motivates GUIs or turnkey command frameworks. Plus, semi-related, this project is not doing much right now to facilitate even basic task-oriented scripting; so the limits of what can be done without GUIs are not even in sight yet. I notice the "Scripting Overview" (in the Doxygen output, technical primers section) has this disturbing statement right at the top: The scripting support is intended for developers of OpenOCD. It is not the intention that normal OpenOCD users will use tcl scripting extensively, write lots of clever scripts, or contribute back to OpenOCD. Well, why the heck should users *NOT* use the scripting? Or contribute? Color me puzzled. Classically, those are the primary reasons to include scripting. And if users don't contribute scripts, how *do* they help grow support for more systems? And how *could* the developers really understand user requirements? _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
