[avr-chat] GUI wrapper for avrdude

[Juergen Harms]

We had a short discussion on the feasibility of a GUI interface for 
avrdude a couple of weeks ago. I have now implemented such a GUI and 
want to make it available. I attach the README file and a screenshot. A 
tarball (avrgui.tar.gz) and a (Mandriva) rpm package 
(avrgui-1.0.2-2mdk.noarch.rpm) can be downloaded from

http://cui.unige.ch/~harms/Download/

if you fetch the tarball, it also contains a HELP.html file - that 
should contribute to see what the frontend can do without installing it.

Some short remarks copied from the README file: This frontend is a 
"better-than-nothing" solution waiting for a more appropriate solution 
to get developed that is integrated into avrdude: the present approach 
"hides" avrdude behind the frontend. The frontend runs on Linux 
(Mandriva, but there should be no problem with other distributions) and 
Windows; Mac should be no problem, but I have neither hardware nor 
experience (well, I had a Classic once upon a time ...). The frontend 
requires, in addition to avrdude, tcl, tk and expect, and - if you want 
the help button to work, you must define a "BROWSER" environment 
variable that contains the path of your preferred browser. I have 
finished the initial testing (on what I possess: JTAGmkII and stk500v2, 
ATmega8 -32) and start using the gadget - very nice to use, on my serial 
interface even not too slow.

I would like to get some feedback - whether this will remain my privat 
fancy, or whether there is interest to share this software and how that 
is best organised. Within the time I have, I am ready to do the 
necessary maintenance and to discuss what improvements are needed.

Juergen

Introduction

Purpose and usage

Concept of implementation

Caveats

Choice of avrdude output messages to intercept

Opening and closing avrdude sessions

Open problems

Implementation, customisation

Availability of software

Installation and execution

Customisation

Files

Current status of the front-end, outlook

Debugging state, maintenance

Introduction

Purpose and usage

This program is a front-end utility that acts as a graphical user interface front-end for avrdude. The GUI uses button hits, menu selections, etc. for composing and submitting command lines and interactive commands to avrdude. All avrdude output lines returned in response to these commands and statements are intercepted by the front-end: the front-end (1) copies the raw output to a monitor window, and (2) it extracts all information that is relevant for the front-end's perception of the state of avrdude and the part.

The monitor window mentioned above is an important component of the front-end: it behaves like a write-only console emulator, recording each line that is sent to and received from avrdude. It provides the user with information that is identical to what he would see when using avrdude without the front-end. This provides the user with a maximum amount of information and allows to reduce the information to be handled and presented by the GUI to a minimum.

Concept of implementation

Avrdude and the front-end GUI run in parallel, they communicate with each other through a pipe (the pipe is established by launching avrdude with the "spawn" command of "expect"): avrdude is practically "hidden" behind the front-end. The implementation of the front-end does not use any of the avr libraries; however, it uses the avrdude.conf file to construct the menus that the GUI offers for selecting the part and the programmer, as well as to help determine an adequate port on the host computer.

The first version of the front-end used a simpler strategy for implementing the parallelism between avrdude and the front-end: avrdude was simply opened with a piped "open" command, reading of input lines was triggered with "fileevent". This approach had the advantage that the expect extension was not needed. However, fileevent does not work for current Windows implementations of Tcl/Tk - the "expect" based implementation is a work-around for this problem.

This concept of using an independent front-end GUI is simple and very easy and quick to implement. However, it is far from ideal: an integration of the GUI into avrdude itself would be preferable - in fact, it is currently being considered. The front-end has been realised with the purpose of providing an immediately available solution for a limited set of usage scenarios. It is implemented as a set of Tcl/Tk modules, currently mainly tested and debugged on a (Mandriva) Linux platform. It should run without problems on any other Linux distribution. Porting it to Windows and MacIntosh should be very easy - one of the strong points of Tcl/Tk. Having Tcl/Tk with the Expect extension installed would be the only pre-requisite beyond Avrdude.

The parallelism between Avrdude and the front-end has been a certain challenge to the implementation: it is essential that avrdude is called only once at a time - for instance, rapid successions of hitting address step buttons should only launch calls to avrdude when the preceding execution has been terminated. The corresponding locking mechanism simply consists in blocking all panel buttons and mouse events as long as avrdude is still working. For batch sessions (-U command-line calls), that means locking the GUI until the session has terminated; interactive calls unblock the GUI as soon as the interactive session launches an input sollicitation and until a new interactive command is submitted.

The front-end opens and closes avrdude sessions as needed in response to the user's actions - which might have negative consequences on the response time. My initial experience, using a jtagMKII and an stk500v2 programmer connected to a serial port of a 1.8 GHz Pentium 4 desktop, did not reveal any major problem of this kind. Connections via USB are reported to be sluggish when a sessions is opened - response time might be slow in this case.

The GUI only offers access to a subset of the functions of avrdude. The choice of these functions has been made with every-day user activities in mind - typically those that a user with limited experience expects in support of straightforward program development tasks. As a result, the user interface can be kept simple and easy to use - and the implementation effort remains small.

A similar consideration applies to the decision on which avrdude output lines to intercept in the front-end: only those lines are detected and acted upon that are essential for maintaining the front-end in a state that is consistent with that of avrdude and of the part - typically the catching of messages that arrive when avrdude has been launched with inadequate options (e.g. incorrect programmer, part or port-speed). As a "luxury" add-on, the outcome of verification operations is detected and translated in to the display of a pop-up window that says "verification ok" or "verification failed ...".

Caveats

Choice of avrdude output messages to intercept

This is probably the most "ugly" aspect of the implementation of this front-end GUI: the front-end must monitor the output sent from avrdude and detect the arrival of messages that need to be specifically dealt with - for instance, messages that indicate the need to close a session, trigger the popping up of a warning to the user, etc. But the precise text of messages to be intercepted can only be discovered empirically.

Due to the restriction that I only could do tests with the programmers and parts I possess, it is likely that unforeseen and additional messages that require interception will appear when the front-end is used elsewhere, and corresponding fixes will need to be applied.

Consult the "Monitor.tcl" module (procedures MonitorCommand and MonitorAction for information on specific intercept rules, the module contains detailed comments for each rule.

Opening and closing avrdude sessions

It is important that sessions, once opened, are also properly terminated again - otherwise CPU registers might be left in a state that is not consistent with what the user had intended to establish. Such a situation is not specific to the use of the front-end GUI, it may also arrive if an ordinary avrdude session is not properly terminated, or if concurrent sessions of avrdude are opened. However, the presence of a front-end adds an additional layer where things may go wrong.

Two mechanisms are available for reducing the risk of an uncoordinated session termination: (1) the front-end intercepts messages from avrdude that indicate a situation leading to non-clean termination, and (2) it "catches" termination events such as a window-bar close-button hit or Unix signals.

As mentioned above, (1) cannot be put in place in an entirely satisfactory way. Considering (2), the SIGKILL signal cannot and must not be caught, SIGINT and SIGTERM are caught and handled to all tidying that is necessary; closing the main window with the window-bar close button is caught, and a possibly open avrdude session is properly closed before shutting down.

Catching SIGINT and SIGTERM can have an awkward side-effect if the tcl program breaks: it may become difficult to kill the broken interpreter. As a precaution, I have commented out the "trap" command in the module MainPanel, which temporarily will keep SIGINT and SIGTERM un-caught.

This comment must be dropped once things are stable !! (about line 100 - search for "trap" or SIGINT)

In case or difficulties killing the program after it breaks: if a window is displayed, the easiest way is to drop an xkill bomb; otherwise, do "ps -A | grep tclsh" and than "kill -9 <pid>"

In the current release, sessions are closed as infrequently as possible in order to avoid degrading the response time (avoid waiting for new sessions to get started). This strategy optimises the response time, but it increases the risk of leaving CPU registers in an inconsistent state. Experience will show whether a change of strategy is necessary - for instance, the session could be closed each time a CPU register has been modified by the user.

Open problems

In the current version (1.0.1-2), multiple front-end sessions can be opened on the same port. Since avrdude sessions are dynamically opened, that may lead to severe problems. A port-specific locking mechanism will be introduced in a future version.

The "raise monitor window" button does not always work properly. This may be a problem that is specific to the present version of Tcl/Tk or – more probable - to its implementation on the Mandriva platform (tcl-8.4.14-1).

Implementation, customisation

Availability of software

This software is available under the GNU public licence with all restrictions and obligations applicable. It exists as a tarball and as an rpm package (Mandriva), available for download (some 300 Kbytes) at - presently

http://cui.unige.ch/~harms/Download/

Pre-requisite software is

• the avrdude executable,

• the avrdude.conf file (it must be in the <local-lib>/etc directory, where the avrdude executable is at <local-lib>/bin/avrdude - in my system <local-lib> is at /usr/local/avr),

• Tcl/Tk, version 8.4

• the expect extension of Tcl

Tcl, Tk and expect are available as packages for practically all Linux distributions. An alternative - and a good solution for Windows systems - is to fetch them from the ActiveState site

http://www.activestate.com/store/activetcl/download/

The packaged version of Tcl there also contains Tk and Expect.

Installation and execution

All you need to do for installation is to unpack the tarball into a directory and to make the main script (module avrgui.tcl) executable. You also need to define the "BROWSER" environment variable (see customisation, below) - if you don't, everything except the Help button will work fine. To execute, call the main script.

Customisation

There is an important issue in finding a browser - needed for showing the help file. In Unix, the front-end expects an environment variable “BROWSER” to be defined, its value being the path of the browser executable. If this is not defined, just add it to your environment and define the value as the path to your preferred browser. In Windows, at least for the time being, the same solution holds: go to Settings -> System -> Advanced -> Environment and define the BROWSER variable as the path of your browser; as an example: I use "Mozilla Firefox" and found the path by searching for an executable file with firefox in its name (i.e. C:\Program Files:\Mozilla Firefox\firefox ; for the Internet Explorer I haveC:\Program Files:\Internet Explorer\EXPLORE.EXE).

All important configuration and customisation parameters are defined in the module "Parameters.tcl" ("library" directory). But there should be no need to change any parameter to get the front-end running.

Files

• avrdude.conf

  This is the configuration file where avrdude defines all parts, programmers, etc. The front-end uses this file for initialising the choices offered in various menus. In Unix, this file is at <library_directory>/etc/avrdude.conf, where <library_directory>/bin/avrdude is the avrdude executable. In Windows, avrdude.conf is next to the executable file.

• .avrguirc

  This is the user configuration file where all user-configurable parameters are saved between sessions of the front-end. It is written when a session is terminated (if the corresponding checkbox is selected), it is read when a new session is started. Unix first looks for a .avrguirc file in the directory where a session is started, otherwise it tries the home directory.

• tcl scripts
  the main script is avrgui.tcl, all modules are in the library directory; the scripts alos need HELP.html and Changelog to be present

Current status of the front-end, outlook

Debugging state, maintenance

I have tested and used the front-end on my Mandriva Linux platform, using an stk500v2 and a jtagMKII programmer, with ATmega8, ATmega16 and ATmega32 parts. It works to my full satisfaction, and I consider that my development work advances more rapidly than when I use command-line avrdude. The minimum scenario for the future is that I keep the front-end in good working order for my own use until some better solution for running avrdude with a GUI becomes available.

The front-end has been adapted to allow execution on a Windows platform. This works quite well, but some more debugging is required for that environment. At present I will concentrate on correcting / improving the front-end on Linux platforms.

If other users consider it worth while to test and use this front-end, I will commit to do the necessary maintenance and development. I do not expect any problem running the front-end on other Linux / Unix distributions, but I expect surprises as soon as other parts and other programmers start getting used (due to the appearance of additional output messages from avrdude that need to be intercepted) - and some plain bugs will certainly also show up. However, it is realistic to assume that I will be able to fix these problems at short notice. Feedback to <address@hidden>, please. It should also be easy to discuss and improve the selection and presentation of avrdude functions that are offered in the GUI front-end - to be determined whether via pm or some adequate list.

This software and its maintenance should be moved away from my private environment to some better organisational background when it gets used by others. At present, the source code is stored in my private area of my department's web site, see "availability of software".