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 [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
