On Monday 19 October 2009, Dean Glazeski wrote: > Hi list, > > I've been sort of bothered by the lack of a GUI for OpenOCD.
In what respect(s) ... what tasks do you find awkward today that a *Graphical* UI would help with? I think there's likely improvement to be made by noticing ways that, for example, an Eclipse-plus-OpenOCD toolchain loses by comparison to various other JTAG toolchains, and filling in gaps. > I've seen this > project: http://openocd-gui.sourceforge.net/, but I'm not entirely certain > if I like their direction. Or whether they *have* a direction for that matter! :( I saw a bunch of posts re the 0.1.x code, then nothing. Their website seems to have gotten all the attention. It's fairly zippy, but rather noisy for my taste. > What I wanted to find out from the OpenOCD community is the interest in this > and if there is any preference on how the frontend would be put together. > Right now I'm thinking of making it an Eclipse plug-in or How would you see the role of an "OpenOCD GUI" be distinct from just supporting a GUI environment like Eclipse? I think that "fit well into Eclipse's GUI" would likely be achievable, which is an important thing to have in goals. "Have a good GUI" is not a very well-formed notion today.. An Eclipse plug-in would be nice if it came with instructions about how to properly introduce Eclipse to one of my JTAG-enabled targets. How to set things up, to compile, run and step a "blinkenlights" project is a bit opaque today, though I *think* a lot of it should just be "fill in the docs". > creating a > separate JAR built using Java Swing or SWT. I'm sort of avoiding the use of > C++, C, TCL/Tk, Python, or Perl/Tk mainly because everyone should have some > form of Java interpreter that has support for Swing and Java is very easy to > work in. Toolkit is IMO of less relevance than what it does, and whether there are enough developers. Eclipse has one or two developers in its community (or so I'm told). Toolkit _integration_ will often shake loose design glitches though. > Another thing of interest is a feature list. I've started a feature list in > this email and additions are welcome. > > 1. OpenOCD server configuration > a. Telnet Port > b. GDB Port > c. TCL Port > d. Target Type > e. Interface Well, "board" type too. And there can be custom config issues, and interactions ... using interface X means you don't have access to signals Y or Z; board may have this set of config jumpers set up in this way; etc. > 2. Start and stop OpenOCD with log output to window > a. Colored output for errors, info, etc. And get rid of most of that spewage, for that matter! Almost none of it should exist. If I enter commands to a Tcl prompt, the results shouldn't be echoed in two places ... > 3. Connect to OpenOCD to issue commands > a. Perhaps a list of available commands filtered based on target and > interface > b. Target status display > c. Multiple windows for multiple targets/interfaces Some target status display sounds nice. Multi-target configs would likely shake loose problems ... I know of a few already. (Ways to debug multi-target may vary a bit. I'd expect a dual-core OMAP4 to need an SMP-ish model, but a board that's got two Cortex-M3 chips will be asymmetric and may want very different models.) > 4. Target flashing/loading of programs For example, a board vendor (or third party) should be able to say "here's now to reinstall everything" using OpenOCD. And shouldn't such a board vendor be able to provide scripts that add "flash this firmware" options to the Eclipse menu? > This is just a start for the list of features and mirrors some ideas from > OpenOCD-GUI. I'm sure I'll think of more and I'm sure the people on this > list know things that I've missed. In a week or two I'll put together some > design documentation based on suggestions and resubmit to this list for any > revisions or opinions. > > On another note, this leads me to wonder if there is a possibility of an API > in the future so that one could query an OpenOCD executable to see what it > supports in terms of target and interface hardware. It might be possible to > just make it part of the version command so that an external program can > query for what devices can be used for debugging. Or it could be a command > issued over the telnet or GDB connection. Thoughts? "interface_list" does part of that today. Characterizing boards, and the variety of ARM chips, is ... less obvious. > Anyway, lengthy email aside, I appreciate anyone's input on this as I build > up a spec for a GUI. If the guys from the OpenOCD-GUI project on > Sourceforge are on this list and are willing to talk Java, or convince me of > another method, don't hesitate to contact me off list. Thanks for any input > from users and developers out there. > > // Dean Glazeski > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
