Re: [Openocd-development] OpenOCD GUI
Dean Glazeski wrote: Another thing of interest is a feature list. I've started a feature list in this email and additions are welcome. I don't see how a GUI will improve my work in any of these areas: 1. OpenOCD server configuration a. Telnet Port b. GDB Port c. TCL Port d. Target Type e. Interface I need to write a custom board config file in most cases. A GUI won't help me set up SDRAM controller registers and other board details. 2. Start and stop OpenOCD with log output to window a. Colored output for errors, info, etc. Reduce the number of printed messages. Those remaining don't need any colouring in order to be understandable. 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 How would the GUI know about the target and interface configs I have written? I think xterm+telnet provide everything that is needed in this category. 4. Target flashing/loading of programs I usually add a do_flash procedure to my board scripts - a GUI can't provide much improvement here. I do think GUIs are fine for the right job - eg. for a debugger. A GUI that replaces simple commands with buttons does not provide much merit for me. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD GUI
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 Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD GUI
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Michael Schwingen Sent: dinsdag 20 oktober 2009 8:48 To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] OpenOCD GUI Dean Glazeski wrote: Another thing of interest is a feature list. I've started a feature list in this email and additions are welcome. I don't see how a GUI will improve my work in any of these areas: 1. OpenOCD server configuration a. Telnet Port b. GDB Port c. TCL Port d. Target Type e. Interface I need to write a custom board config file in most cases. A GUI won't help me set up SDRAM controller registers and other board details. 2. Start and stop OpenOCD with log output to window a. Colored output for errors, info, etc. Reduce the number of printed messages. Those remaining don't need any colouring in order to be understandable. 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 How would the GUI know about the target and interface configs I have written? I think xterm+telnet provide everything that is needed in this category. 4. Target flashing/loading of programs I usually add a do_flash procedure to my board scripts - a GUI can't provide much improvement here. I do think GUIs are fine for the right job - eg. for a debugger. A GUI that replaces simple commands with buttons does not provide much merit for me. IMHO a GUI is a good idea but it has to be cross-platform. I have been using WxWidgets for cross platform development for several years and I must say the transfer between Windows and Linux is seemless. I don't think a GUI is usefull for debugging because OpenOCD is a man-in-the-middle. A GUI will be usefull though for testing setups and flash programming. Console commands are fine for pro's but for a beginner a GUI is much easier. Perhaps there should be a log window which shows the commands send to OpenOCD. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD GUI
IMHO a GUI is a good idea but it has to be cross-platform. I have been using WxWidgets for cross platform development for several years and I must say the transfer between Windows and Linux is seemless. Cross platforms w/dependencies during compilation or running is not great either. For now the consensus(Duane and I have mostly discussed this in the past) is a built in web server for basic operations and special pages for target specific peripherals. Take the builtin httpd server for a spin. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD GUI
-Original Message- From: Øyvind Harboe [mailto:oyvind.har...@zylin.com] Sent: dinsdag 20 oktober 2009 9:33 To: Nico Coesel Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] OpenOCD GUI IMHO a GUI is a good idea but it has to be cross-platform. I have been using WxWidgets for cross platform development for several years and I must say the transfer between Windows and Linux is seemless. Cross platforms w/dependencies during compilation or running is not great either. The GUI doesn't need to be part of OpenOCD. For now the consensus(Duane and I have mostly discussed this in the past) is a built in web server for basic operations and special pages for target specific peripherals. Take the builtin httpd server for a spin. Does the httpd server support PHP, database access, sessions, cookies, etc, etc? Without that the functionality of a builtin webserver is extremely limited because it is very cumbersome to make active web-pages. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD GUI
Cross platforms w/dependencies during compilation or running is not great either. The GUI doesn't need to be part of OpenOCD. The alternative is to create a complete API and stick to it. We're not keen, nor do we see the need for the sort of simple functionality that has been outlined. For now the consensus(Duane and I have mostly discussed this in the past) is a built in web server for basic operations and special pages for target specific peripherals. Take the builtin httpd server for a spin. Does the httpd server support PHP, database access, sessions, cookies, etc, etc? Without that the functionality of a builtin webserver is extremely limited because it is very cumbersome to make active web-pages. It doesn't sound like you've had a look at the stuff that's already done. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD GUI
On Tuesday 20 October 2009, Øyvind Harboe wrote: The alternative is to create a complete API and stick to it. We're not keen, nor do we see the need for the sort of simple functionality that has been outlined. Web access *IS* an API ... at least, as soon as any client starts to use it that way. That's why there's been such a lot of interest in web programming interfaces that uplevel things from screen scraping to something that's more maintainable. IMO that's kind of moot until whatever non-commandline UI starts to get more users, though. :) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD GUI
I would like to see openocd always start, even if the config file is invalid. Then, it can be configured via telnet and, hopefully, Have a command to dump a config file. If the telnet interface supported completion a la Cisco routers (press ? to list available completions), it would not be difficult to write flexible GUIs that wrap around it, and it would be nicer to use in and of itself. -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of David Brownell Sent: Tuesday, October 20, 2009 11:19 AM To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] OpenOCD GUI On Tuesday 20 October 2009, Øyvind Harboe wrote: The alternative is to create a complete API and stick to it. We're not keen, nor do we see the need for the sort of simple functionality that has been outlined. Web access *IS* an API ... at least, as soon as any client starts to use it that way. That's why there's been such a lot of interest in web programming interfaces that uplevel things from screen scraping to something that's more maintainable. IMO that's kind of moot until whatever non-commandline UI starts to get more users, though. :) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD GUI
Hi list, I've been sort of bothered by the lack of a GUI for OpenOCD. I've seen this project: http://openocd-gui.sourceforge.net/, but I'm not entirely certain if I like their direction. My main concern is the lack of activity and the goal of using C++ or TCL/Tk. At any rate, I was going to start putting together some documents to outline what a GUI application for OpenOCD might look like. This includes some rough sketches of how I might envision the UI and what properties would be configurable etc. 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 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. 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 2. Start and stop OpenOCD with log output to window a. Colored output for errors, info, etc. 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 4. Target flashing/loading of programs 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? 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
Re: [Openocd-development] OpenOCD GUI
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
Re: [Openocd-development] OpenOCD GUI
Dean Glazeski wrote: Hi list, I've been sort of bothered by the lack of a GUI for OpenOCD. I've seen this project: http://openocd-gui.sourceforge.net/, but I'm not entirely certain if I like their direction. My main concern is the lack of activity and the goal of using C++ or TCL/Tk. At any rate, I was going to start putting together some documents to outline what a GUI application for OpenOCD might look like. This includes some rough sketches of how I might envision the UI and what properties would be configurable etc. 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 Some people use OpenOCD - GDB - Eclipse: http://elinux.org/BeagleBoardEclipse I'm not sure if OpenOCD should be used directly? Or is OpenOCD 'just a library' that interfaces to full blown debuggers? Which then are controlled by a GUI? Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
