OpenOCD has started some work on a GUI using a web interface, look at the httpd server in the development section, the builtin web server works today. It should include some memory browsing, flash programming page, simple small scale production page for non-engineers, etc.
A web interface is great because OpenOCD's gui requirements are tiny and such a GUI works on *all* platforms. Duane Ellis has worked on target specific scripts to manipulate peripherals. Other than that great support for GDB, reducing noise, improving documentation and quality of target scripts would be a few things that would greatly help usability of OpenOCD. For non-builtin web server, I have a soft spot for Eclipse & Java, but I'm not sure what GUI functionality I would want in Eclipse at this point, except to get CDT quirks fixed. > 1. OpenOCD server configuration > a. Telnet Port > b. GDB Port > c. TCL Port > d. Target Type > e. Interface I see very little win in configuring the above in a GUI. It would essentially build a command line to launch OpenOCD. Take a look at the builtin httpd server in OpenOCD. I think you'll find a lot of what you're looking for is more or less there already. > 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? With the builtin web server, you just execute Tcl code to build web pages. That's your API effectively. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
