Scripting or - How to Control Your AVR From Your PC

Transcription

1 Scripting or - How to Control Your AVR From Your PC Dave Harper Introduction As a member of this forum for a few years now, there is one thing I have seen many times with new users. First, they discover the AVR and get wildly excited about the possibilities. The price of the hardware is right, there is a choice of software development tools that are either free or inexpensive and there is an active user community from which to seek help. The next step is to start getting familiar with the AVR and how to program it. By spending a modest amount of money, starter hardware such as an STK500 or AVR Butterfly can be purchased and before long our newbie is happily generating code, programming it on their hardware and getting it debugged. For many projects, this is all that is required; once developed, the project can operate in a standalone manner. Other projects may require a control interface running on a PC, but are simple enough that a terminal emulator, such as HyperTerminal or Bray's terminal, is all that is required. However, there is another class of projects where a custom interface running on the PC may be required. This could be due to the complexities of the project, or the fact that it deals with binary data. Traditional programming tools for the PC, available from companies such as Microsoft and others, can often cost hundreds of dollars. There are free alternatives for the hobbyist on a budget, such as MINGW (Minimalist GNU for Windows), but these are often better suited to the experienced user who is comfortable tracking down and integrating the components required to create a complete toolset. Fortunately, there are other alternatives. This article will describe one such approach, using scripting languages, that is relatively simple to implement, costs absolutely no money to get started, and even has the benefit that it can control your hardware from multiple platforms, such as a PC running nearly any version of MS Windows or any version of Linux. Sound interesting? Background Scripting is not new; it s been around in various forms almost as long as the computer itself. However, nearly all implementations have many characteristics in common: Scripts can be constructed and executed quickly. A person need not be an expert programmer to use them. In fact, more often than not, script languages are designed for individuals that need to perform a specific task using a computer but their expertise is in other areas rather than programming. They are interpreted, meaning that they require another computer program to perform the actual execution. 1

2 Scripting languages are generally in the high level language category; they deal with concepts that are common regardless of the computer or operating system being used. Given an interpreter on the target platform, a script can often run with little or no changes across a range of systems. Early scripting languages, often referred to as job control languages or batch programming at the time, were rather primitive compared to modern offerings. One obvious example that nearly everyone is familiar with is the autoexec.bat batch file that ran under DOS on a PC. This file allowed a user to configure his or her computer so that it started up the same way every time. All you needed was a simple text editor and you could modify the file to incorporate your preferences. In this case the interpreter was DOS itself and the capabilities of the batch file were limited. However, batch programming was fairly simple and many people who edited their autoexec.bat file had limited knowledge of computers and didn t even realize that they were writing a computer program, albeit a simple one. As scripting languages matured, they started to incorporate concepts found in more traditional programming languages. Control constructs (if / then), looping capabilities (for, while) and the ability to create and use internal variables led to languages that would allow a relatively unsophisticated user to quickly create a powerful script that otherwise would have required an expert programmer. By the early 1980 s general purpose scripting languages, such as Tcl (Tool Control Language) and Perl (Practical Extraction and Report Language), were starting to appear. Tcl (usually pronounced tickle ) was developed by John Ousterhout at the University of California at Berkeley and was originally targeted to ease interfacing with interactive integrated circuit design tools. However, it quickly evolved into a more general purpose language and found a range of other uses as well. Key to the design of the language was the ability to easily add extensions that would enhance the capabilities of the language, something that would prove to be vital in the years to come. Also in the 1980 s there was a revolution involving the user interface on computers. The command line interface, which had been the mainstay since the early days of computing, was starting to yield to a graphical approach. On Unix systems this was being implemented with an approach called X Windows, based on pioneering work done by Xerox. Even in the PC world the graphical interface was being introduced by Apple in what turned out to be the short lived Lisa system. Microsoft followed shortly thereafter with an operating system simply called Windows. While this GUI approach was a vast improvement for the casual computer user, the complexity of computer programs increased dramatically. It now required extensive knowledge by the programmer and several hundred lines of code just to pop up a simple window that said the ubiquitous Hello, World! along with a button to close the window. John Ousterhout addressed this problem with the first big extension to Tcl - a package called Toolkit, or simply Tk. This extension simplified the generation of a graphical user interface in the same way that the original language had simplified the generation of general purpose programs. Using the Tcl/Tk combination, the same Hello, World! program could be created with a single line of code! As a bonus, it ran both under Windows and Unix systems, as interpreters had already been developed for both. In fact, the Tk extension was so popular it was ported to many other scripting languages, such as Perl, and even newer languages like Python, which have been 2

3 designed from the ground up to support modern programming concepts, such as Object Orientation. Getting Started The remainder of this article will concentrate on creating a script interface to an AVR. To do this, some assumptions will be made: 1. The scripting language used will be Tcl/Tk, although nearly any modern language such as Perl, Python or even Ruby could be used. 2. Since the STK500 is one of the more popular development platforms, we will use this for the target hardware. It will be connected to the PC through an RS-232 link. 3. The PC end will be a standard PC running one of the flavors of Microsoft Windows. It could just as easily be a system running AIX, HP-UX, Linux, Mac OS X or Solaris since interpreters exist for all these platforms. Okay, the first thing that needs to be done is to install a Tcl/Tk distribution on your system. Actually, if you have installed WinAVR, you already have an interpreter since many of the tools used by this package are written in Tcl. However, the WinAVR package contains mainly the interpreter itself; it doesn t include help files, demos, etc., so we ll go ahead and install a complete distribution (don t worry - it won t interfere with anything you already have if you do have WinAVR installed). We will use the ActiveState distribution since it is one of the best supported, most comprehensive distributions I ve found. To install it, perform the following steps. 1. Open your favorite browser and go to 2. In the upper right-hand corner of the main web page, there will be a list of script distributions provided by ActiveState. Click on Tcl. 3. You should now be on the Tcl Solutions page. At the bottom left corner of the page is a box that describes ActiveTcl. Click on the Download now link. 4. This will take you to a forms page where you can chose to provide contact information if you wish to be notified about product updates. If not, simply click on the NEXT button. 5. You should now be on the download page. Select the appropriate package for your platform and begin your download. Be advised that the packages are quite large (15-20 MB depending on the platform) so you need either a broadband connection or a lot of patience. 6. HTML documentation is also available on the same page for another 3 MB, but if you are downloading the Windows distribution, standard help files are already included. 7. Once you have completed the download, double click on the file and the installer will start. I find that the standard defaults for all options works best and, once the install begins it will be done in less than a minute. 8. Part of the install process will update the registry and associations such that the interpreter will start automatically any time you execute a file with a.tcl extension. 3

4 I mentioned previously that you could create the simple Hello, World! program with as little as one line of code. Ready to try it? Open your favorite text editor and type in the following: tk_messagebox -message Hello, World! -type ok Save the file as hello.tcl. Note that this must be saved as pure text; some editors, such as Wordpad, will default to Rich Text Format (RTF) unless you force it to save as text. Other editors, such as Notepad, will try to append an extension of.txt so you may need to manually change it to.tcl. Next, double click on the newly created script file and you should be rewarded with a popup window that looks like: This screenshot was produced on a Windows XP system so the popup has the look and feel of the Windows XP style. The same script run under Linux would have the look and feel of the native window manager being run on that platform. Click on the OK button at the bottom of the popup and it should close. Note, however, that there is still another window that popped up on your desktop. This is the main toplevel window and it is blank because our simple little script didn t insert any widgets into it. For now, simply close it by clicking on the X in the upper right-hand corner. Okay, let s modify our script so that we don t have to close the toplevel manually each time. Open the script with your text editor and add a second line that simply says exit : tk_messagebox -message Hello, World! -type ok exit Rerun your script by double-clicking on it and this time, when you close it by selecting the OK button, the toplevel window will also close. Congratulations, you ve just written your first Tcl script! Let s take a look at what we did. The line that does all the work consists of three parts. The first part, tk_messagebox, invokes a built-in dialog box which causes the popup. In fact, this is the only thing that is required on the line. If your line consisted of this and nothing else, you would get an empty dialog box with the default OK button. The next section specifies the message we want to display. This can be as short or as long as you want and the window size will automatically adjust to accommodate it. The last section allows you to specify the button or buttons at the bottom of the window. These are predefined and consist of things such as the YES NO pair, ABORT RETRY IGNORE, or the default OK. The OK button simply closes the popup; other button combinations allow you to specify the action to be taken when the particular button is selected. 4

5 Now would be a good time to explore some of the demo programs that come with the distribution, since they will give you an idea of the sort of things you can accomplish with simple Tcl scripts. From the Start Menu, highlight the ActiveState distribution you installed and you should see a small window open up to the right of it. This is called a cascading menu (easy to implement in Tcl/Tk!). Highlight ActiveTcl Demos and click on the bottom tk selection in the final cascading menu. This should pop up an application called Widget Demonstration. If you are unfamiliar with GUI programming, a widget is a low-level graphical item such as a label or button. They are the alphabet that will make up the text of your GUI. Play with some of the selections in the application to see what they do. The really great thing about this application is that each time you pop up a window that demonstrates a particular widget, you can click on a button that will show you the script that it took to produce the window. You will probably be astonished at the amount you can accomplish with just a few lines of code. Mini Tcl Tutorial Towards the end of this article we will actually produce a windows script and a short AVR program that allows us to talk to the AVR on an STK500. However, before we are ready to produce that script, we need to learn a little bit about the Tcl language itself. Fortunately, we do not need to become experts. One of the great things about scripting languages in general, and Tcl in particular, is that you don t need to know a lot to get started. Just a few basic concepts and you are off and running. New concepts about the language can be added as you need them and you can continue to build and improve upon your scripts. This section will try to highlight some of the basic concepts so that the final script will be more meaningful once we get to it. The reader is urged to supplement this information by going through the help documentation that comes with the ActiveState distribution (selected from the same cascading menu that listed the demos), as well as consulting some of the many resources that are available on the Web (some of which are listed at the end of this article). The first thing to keep in mind is that Tcl and Tk are separate. Tcl was developed first and can operate standalone, producing scripts that run in a command line environment. Tk, on the other hand, is simply an extension, and as such can work with different core scripting languages other than Tcl. Given this separation, we can look at each part individually. The first section will concentrate on some of the characteristics of the Tcl core. Everything is a String If you work with Tcl for very long, you will see the above phrase repeated many times - it goes to the heart of the language design. Simply put, Tcl represents all data types internally as strings. Conversion to or from other formats is often done automatically by the interpreter. For example, if you had a variable whose value was 2 and you wanted to print it, you would simply print the variable and it would be kept in its normal string format. If, on the other hand, you wanted to add a value of 5 to it, Tcl would temporarily convert the string to its integer representation, perform the addition to come up with the integer value of 7, and then convert it back to a string to be stored as the new value of the variable. 5

6 Variables Unlike some other languages, Tcl distinguishes between the name of a variable and the value of the variable. The value of a variable is obtained by preceding the variable name with a dollar sign. Assigning a value to the variable is done with the set command. For example, if we have a variable called foo, we can assign a value to it through a statement such as set foo 3. Now, if we want to reference the value itself, we could do something like set bar $foo. This would now give us a second variable whose name is bar and whose value is also 3. Had we instead written something like set bar foo, then $bar would be the value foo not 3. Note also that Tcl does not require us to declare variables before they are used; the interpreter will create them the first time they are encountered. The only requirements that Tcl lays down is first, that variables must be initialized with some value prior to trying to use them. This makes sense; if above we had executed the statement set bar $foo before the statement set foo 3, then the interpreter would not know what to assign to the variable bar. The second requirement is that we must be consistent. If we initially define and use a variable as an integer, we cannot turn around and later try to use the same variable as an array. In both these examples, the interpreter would halt with an error message. Lists Lists can be thought of as an ordered sequence of elements, where the element can be any valid Tcl data type, including another list. Syntactically, a list is represented by the form {a b c d, where this would be a list of four separate elements. Since the space character is used as a separator within lists, any element containing embedded spaces should be enclosed in double quote characters so that Tcl can recognize the fact that it is a single element. There are a number of commands pertaining to lists, which allow the user to access individual elements, perform search, sort or modify operations, or even convert the list into another Tcl data type. Comments Like most languages, Tcl provides a method of adding comments to a source file to provide further details in a more straightforward manner. In Tcl, the start of a comment is denoted with the pound sign (#) character and it continues through the end of the line (note that, like many other languages, a line can be continued by placing a backslash (\) character at the end of the line). Although comments can appear anywhere on a line, the Tcl parser expects a comment to be the first part of a command, otherwise the # character may have a different meaning. To allow us to append comments to the end of a command, we simply need to terminate the command by placing the semicolon (;) character at the end of the command, something which otherwise is not required if a comment is not present. One thing that often confuses new users of Tcl is unexpected consequences of comments. We can see this in the following example. In addition to describing lists, curly braces are used for grouping and it is a requirement that the number of left curly braces match the number of right curly braces. The general format of a compound Tcl statement might look like: if {test condition { command command 6

7 It is common practice during debug to comment out sections of code as we explore alternate approaches. Thus, we might be tempted to try something like: #if {test condition1 { if {test condition2 { command command Unfortunately, this probably won t work as expected. The reason for this lies in the Tcl parser itself which matches up curly braces before checking comment conditions. A better way to disable the first line would be to simply terminate the command portion of the statement by appending a right curly brace (and perhaps keeping the comment character at the beginning for clarity) so that it becomes: #if {test condition1 { This will satisfy the requirements of the parser while still allowing us to accomplish the goal of trying a different if statement without having to completely delete the original. Looping Tcl provides two of the more common looping constructs: while and for. The while statement is fairly simple and has the form: while {test condition { command As long as the {test condition evaluates to a non-zero value, the command will be executed. The for statement is a bit more complex and operates in a manner similar to the way it does in the C language. Here, there is a loop variable which is defined by an initial condition, an ending test and a modifying action. Unlike C, which uses semicolons to separate these three parts, Tcl groups them using the curly braces. Thus, a for loop that iterates over all even numbers between 0 and 10 might look like: for {set i 0 {$i <= 10 {incr i 2 { command An additional loop command, designed to iterate through elements of a list, is the foreach command. The format for this statement looks something like: foreach i $j { command 7

8 Here, the value of the variable i will take on the value of each successive element in the list j. Note that since we are accessing values from the list we must precede the variable name with the dollar sign. Two other commands, familiar to C users, are break and continue, which allow additional control within the loop. The break command will abort the innermost loop and the continue command immediately causes the next loop iteration to be started. Procedures Virtually every language provides the ability to define a section of code that can be executed from many different places. These are called subroutines, functions or, in the case of Tcl, procedures. A procedure is identified by the keyword proc and has the general form: proc name {inputs { command command The first set of curly braces allows a list of input arguments to be passed to the procedure. The curly braces must be present, even if the procedure requires no arguments. All variables used within a procedure have a scope that is local to the procedure unless they have been identified with the global keyword. In this case they will inherit a value set elsewhere in the script and possibly modify that value for use outside the procedure. An optional return command will allow the procedure to return a single value to the calling routine. The value can be any valid Tcl data type including a list, which allows us to bundle several return items into a single entity. Return values are captured by the calling routine through the use of square brackets which, in this case, can be thought of as meaning the value of. For example, let s say we have a procedure called add that adds two input numbers and returns the sum. We would like to pass this procedure the current values of variables a and b and assign the sum to a variable called c. This statement might look like: set c [add $a $b] One more thing to keep in mind about procedures is that the Tcl interpreter requires them to be defined prior to the first instance where they are invoked. Thus, it is common to see the overall structure of a Tcl script start with (perhaps) header information that describes the script and its usage, followed by a section which defines and initializes global variables, followed by all of the procedures used in the script. The actual "body" of the script may turn out to be just a few lines of code at the very end that starts things going! Input / Output To be useful, all programs need to be able to communicate with the outside world, whether gathering data to process or returning the results of that processing. With Tcl, this can be to or from filesystems, such as files on a hard drive or CDROM, or communication channels such as a COM port or a socket interface to another program. Like most modern languages, there are open 8

9 and close commands, along with other commands which configure the I/O. This includes various access methods, such as read-only or append, as well as commands which determine channel operation, such as baud rate in the case of a COM port or end of line definitions for a character oriented device. One particularly useful command is fileevent. This command allows the programmer to define the operations to be performed whenever a channel becomes readable or writable. This is analogous to an interrupt service routine which means that a Tcl program does not need to poll a channel to see if it has data available for reading or is able to accept data for writing. The Event Loop With event-driven programming, when there is nothing that currently needs to be done, the interpreter waits in an Event Loop. Within this loop it checks for system events that have been registered by the script and will take the defined action when the event occurs. For example, let s say that we have defined a GUI that contains some buttons labeled Start, Stop and Quit. With each of these buttons we have registered the command or commands that we would like performed when the button is selected. Shortly after we start our script, it opens up the toplevel window that contains these buttons. Once the construction of the toplevel window is complete, the Tcl interpreter may have nothing else to do, in which case it will enter the Event Loop. Eventually, the user may click on the Start button. This will be detected by the interpreter and those commands or procedures that have been previously registered will begin execution. It is important to note that even though the interpreter has begun executing code due to the button press, the Event Loop continues to run; if the Quit button was also selected while the Start code was still executing, the Quit commands would also be processed, likely causing the script to terminate. Further, the Event Loop is not associated with only the windowing capabilities of the language; the fileevent command mentioned above also invokes the Event Loop. Tk This next section describes the features of Toolkit, the first major extension to be added to the Tcl core. As mentioned previously, Tk was created to address the problem of how to extend the capabilities of Tcl into the emerging graphical approach starting to be incorporated as the user interface for many operating systems. Toplevel In Tk, toplevel is both a concept and a command. Toplevel refers to a standalone window that appears on the desktop. It is within this window that the programmer will construct all or portions of the GUI using the individual lower-level widgets. Tk allows for the creation of multiple toplevel windows, identifying each with a unique name that allows the script to access them individually. Toplevel windows can be created or destroyed at will within the script; when the last toplevel window is destroyed, the script exits. Widgets As mentioned previously, widgets are an atomic graphical entity that you use to construct your graphical interface. Every widget instance in the script is identified by a unique name, consisting 9

10 of the hierarchy where the widget is located. For example, a button widget can be located within a particular frame widget which is then part of a particular toplevel. If the toplevel is defined with the name.a, the frame widget with.b and finally the button with the name.c, the full name of the button widget would be.a.b.c. Once we completely specify the name of a widget, allowing us to uniquely identify it, we can perform various operations involving the widget. For example, we could change the background color of a button widget to indicate whether it is currently active or not, or we might read the contents of an entry widget allowing us to capture user input. One nice thing about widgets is that they can be combined together to make up more complex widgets or mega-widgets. Once defined, these mega-widgets can be used as individual entities within the script. For example, nearly everyone is familiar with the file selection dialog box: Looking at it we can see that it is composed of a toplevel window that contains smaller widgets such as buttons, entry boxes, etc. Further, some of the lower level widgets can look entirely different depending on how they are configured. In the bottom right-hand corner we have two obvious button widgets labeled "Open" and "Cancel". However, at the top of the screen, just to the right of the "Look in:" entry box are four more button widgets. These just happen to contain an image such as the stylized "left arrow" or "up arrow" instead of text. Another thing to note is that widgets are constructed using the tools supplied by the window manager running on the particular platform. Thus, the example above looks like a normal file selection dialog box running on a Windows XP platform. The exact same code running on a Windows 2000 or Linux platform would take on the characteristics supplied by that window manager. This can be both good and bad. It's great that you can run your application across multiple platforms and they 10

11 look like they were native to each individual platform. However subtleties, such as differences in available fonts, may cause text that fits fine in a widget on one platform, to overlap into adjacent window on another platform. The remainder of this section provides a brief description of the more commonly used low-level widgets that are part of the Tk extension. Button - this is an entity that can be selected by a mouse, causing some predefined action to be performed. It can contain a label (text or image) and relief characteristics, such as raised, sunken, flat, etc. Checkbutton - this widget consists of two parts; a label (text or image) and an indicator box that toggles between checked and unchecked when selected by the left mouse button. Radiobutton - this is similar to a checkbutton in appearance but individual radiobuttons can be associated as members of a group, where they act in a mutually exclusive manner. In other words, if one of them is checked all other radiobuttons in the same group will become unchecked. An example might be where the GUI provides a list of acceptable baud rates, but only one of them can be selected by the user. Entry - this widget provides a single line entry box (with optional label) that allows a user to type in text from the keyboard. Spinbox - similar to an entry widget, but has up and down buttons that let you scroll through a list of predefined defaults. Frame - a rectangular widget that can be used to contain other widgets that should be treated as a group. Label - a simple widget that can contain a text string or an image. Menubutton - similar to a regular button except, when selected, this one opens up a drop-down menu of selections. A common example would be the File menubutton in the upper left-hand corner of many applications. Menu - closely associated with the menubutton above, this command allows the programmer to define the contents of a drop-down menu. Listbox - used to display a list of strings, one per line; can optionally contain a scrollbar if the list being displayed exceeds the size of the listbox. Text - similar to a listbox except the text can be edited. Can also contain a scrollbar. Scrollbar - a narrow widget that contains an arrow at each end and a slider bar in the middle. Can be used with either a listbox or text widget to horizontally or vertically position the display over a portion of information that would otherwise be too big to display in the defined space. Geometry Managers Once the programmer has decided which widgets need to be contained in the toplevel window, the next step is to design the layout that describes where they will be positioned within the window. Tk provides three different geometry managers to accomplish this task. All can create identical windows but, depending on a particular layout, one may be easier to use. Additionally, a programmer may prefer to use one over another simply because it tends to make more sense with the way they tend to approach GUI design. 11

12 The first geometry manager to be created was the pack manager. Like the other two, this one starts with a "parent" window which is usually, but not always, a frame widget. Within the "parent", one or more "child" widgets are packed by defining the characteristics that control their position. The packer will then try to position these widgets as best it can in the order in which they are given to the packer. For example, a widget could be defined as having an anchor position of "sw" (southwest). If this is the first widget to be packed, it will occupy the bottom left-hand corner of the parent. If another widget has previously been packed into the parent and already occupies this position, the packer will try to best place the new widget based on its dimensions, the remaining space available within the parent and the conditions that describe the placement of the new widget. Often this can lead to unexpected results for the novice user of the pack manager. This is due to the fact that normally the boundaries of each widget are invisible by default. It is possible, however, to temporarily display the widget boundaries by adjusting the widget options. When this is done, it is like looking at the individual pieces of a puzzle within the overall boundary of the puzzle. This can make it much easier to adjust the characteristics and pack order of the widgets so that you can achieve the overall layout that you desire. The next geometry manager to be added to Tk was the place manager. In many ways, the placer is the simplest of the geometry managers; the programmer specifies either the exact size and position or relative size and position of a widget within its parent. While this gives the programmer a great deal of control over exactly where a widget will appear in the parent window, the specifications can become tedious if there are a large number of widgets to be placed. The most recent geometry manager to be added is the grid manager. With this approach the programmer can divide the parent window into a series of variable sized rows and columns. Widgets can then be placed into the parent based on a row and column number. Often this approach provides the novice programmer with the best compromise between the complexities of the pack manager and the tedium of the place manager when creating relatively complex graphical interfaces. There are two things to note about the geometry managers. First, it is possible to mix the usage of the managers within a large graphical interface. Within any given parent, you must use the same geometry manager for all of the children positioned within that parent. However, at the next level up you are free to use a different geometry manager as those parents are positioned within their parent. In this way you can take advantage of the strengths of a particular geometry manager in that section of the GUI where it makes the most sense. The other thing to note is, despite the availability of the three geometry managers, it can often be difficult for even seasoned programmers to get the exact look that they want in their layout. This has led to a class of application programs called "GUI Builders". For Tk, two of the most popular are TKproE and Visual Tcl. Both of these programs are completely written in Tcl/Tk so once you have the interpreter installed you can run them like any other Tcl script. Each provides a blank toplevel window within which you build your GUI. Once you are happy with the way it looks, the application will generate the code that it takes to produce the window. Visual Tcl is particularly nice in the fact that it features drag and drop capabilities; you simply click on the widget you want from a toolbar and drag it into the position you want on the surface of the toplevel window, 12

13 resizing the widget in the process. Both programs allow you to define any operations to be associated with a particular window and, in fact, will allow you to create and test the entire script all from within the framework of the GUI Builder. This can be a big time saver for programmers of all skill levels. Defining Our Project We want to keep our project fairly simple while still demonstrating the ability to interface the PC to the STK500. The STK500 has 8 pushbutton switches for input and 8 LED displays for output. With this in mind, let's come up with programs running on the STK500 and PC that will allow us to turn on or off an LED display on the STK500 by pushing a button on our GUI. We will also have a set of 8 indicators on our GUI that show the current state of each button on the STK500. For communication, we will use a simple RS-232 link between the PC and the AVR. The link will be set up to run 9600 baud with 8 bits of data, no parity and a single stop bit. The "protocol" of the communication will be about as simple as is possible; whenever the AVR detects that a button is pushed, it will send a single byte of data to the PC where a bit position will be low if the corresponding button is pressed. The PC will send a single byte of data to the STK500 whenever a button on the GUI is selected, again with an active low bit value representing a button that is pushed. Although the buttons on the STK500 are pushbutton, let s make the buttons on our GUI act like toggle buttons; we will click on them to turn them on and click on them again to turn them off. We will change the background color of the button as an indicator of whether it is on or off. So we now have a working idea of what our GUI is going to look like and how it will operate. It will need a row of 8 buttons that control the LED displays on the STK500 and a row of 8 indicators that reflect the STK500 button press state. The only other thing that is needed is a graceful way to exit the program when we are done. While we could just click the "X" button in the upper right-hand corner of the application to close it, let's instead add a "Quit" button at the bottom of our GUI. For the STK500 we will need to make some working assumptions about the hardware and software we have available. We will write our program in assembly language, so the user should have downloaded and installed a recent version of AVR Studio. Further, we will assume that the processor installed on the STK500 is an 8 MHz AT90S8515 since that is what was shipped with many of these development boards. We will use the external clock set to run at 3.68 MHz. We will also use PORTA to read the pushbutton switches and PORTC to drive the LED displays. If the user needs to change to a different device, speed grade or use different I/O ports than what are used in our project, the assembly source file can easily be changed to what the user needs. We will keep the operation our program as simple as possible. When it starts up, it should perform any initialization, such as setting up the UART that will be used to communicate with the PC. As a sanity check, we will walk a bit through the LED displays on reset; this will at least let us know that the AVR is operating and has been programmed correctly. Otherwise, if things don't work it would be hard to narrow down whether the problem is on the PC end or the STK500 end. After initialization, the AVR will go into a polling loop where it will do two 13

14 things. First, it will check the UART to see if there is a byte of data that has been sent by the PC. If there is, the data will be read from the UART and written to PORTC. Next, PORTA will be read and the state of the pushbutton switches will be compared to the previous setting. If there is a change, the current switch setting will be saved for the next check and the new value will be written to the UART. Given the simplicity of our project we will take some shortcuts that we might not be able to do in a more complex project. For example, all actions that occur are based on human operations, such as pressing a button on the STK500 or clicking a button on the GUI. As such, these actions will occur quite slowly compared to the speed of program operation on both the PC and the AVR. Thus, there is no need for flow control in our protocol. Further, when a hardware pushbutton switch is pressed, it tends to "bounce" a few times over a period of milliseconds prior to closing completely. This would result in several high to low and low to high transitions on the input port of the AVR. In many applications this could be important and steps would need to be taken to "debounce" the switch in software. Since we will only be using it to control an indicator in our GUI, we can safely skip this step. Okay, we now have everything we need to start coding. Let's begin with the Tcl/Tk program that runs on the PC. The PC Interface Program All programmers tend to develop their own style over time. For myself, after the program definition is complete and I have a good idea of how the GUI should look and how the script should operate, I start with the GUI design first. The toplevel window is created and populated with the widgets that will make up the GUI. Usually, at this point I am not concerned with script operation; I am simply trying to get the GUI layout to look the way I want. For example, buttons may be present and labeled properly, but clicking on them will do nothing (with the possible exception of a "Quit" button which will allow me to exit the script early in the design process). Typically, this is done through the use of "stubs"; when a button is selected it will call the appropriate procedure, but that procedure will simply be defined and empty to start with. Once the GUI design is complete, I can start filling in the details by adding and debugging individual procedures until the script is up and working. The complete listing of the script is shown at the end of the article, but let's start by looking at some of the individual sections and what they do. The GUI procedure is the "heart" of the script, so we'll start there: 14

15 proc GUI { { frame.main; pack.main; # create the frame that will contain our GUI # pack it into the top level window Tcl automatically creates a toplevel widget for us called "."; in fact, when we tried the early "Hello, world!" script, this was the empty window that popped up to the side of our dialog window. Now we are going to use it to construct our GUI. We will first create a parent frame called ".main" that contains three child sections; one for the row of buttons, one for the row of indicators and a final row that simply contains the Quit button. Once we have created the frame, we must use one of the geometry managers to install it in the toplevel window. If we didn't do this step, it would never be seen in the GUI despite the fact that it exists. For our purposes, we'll use the packer and all we have to do is pack the frame. It will automatically expand to contain everything we put in it. The next step is to create our first row, which will contain the buttons we use to light the LED displays on the STK500. Since there will be multiple widgets, we ll put them in their own frame: # create a row of 8 buttons, left to right, labeled with the button number frame.main.row1; # create a frame within which to pack the buttons pack.main.row1 -side top -pady 20; # install it as the top row label.main.row1.lab -text "AVR LED Control" pack.main.row1.lab -side top for {set i 7 {$i >=0 {incr i -1 { button.main.row1.b$i -text $i -relief raised -bg white \ -command "readbutton $i" pack.main.row1.b$i -side left -padx 10 Here again we will start with a frame widget that we will then serve as the container for the individual buttons. Since all widgets must have a unique name, we will call this widget ".row1". Since it is to be inserted into the frame we created previously, its full name will be ".main.row1". Again, we need to pack it within its parent, but this time we will supply a bit more information to guide the packer. We want it packed starting from the top and we would like to leave a little vertical space between the top of the window and the top of this first frame so we specify "-pady 20", which gives us a vertical pad of 20 pixels. Since it would be nice to indicate to the user the purpose of the row of buttons, we'll add a simple label that says "AVR LED Control" and pack it towards the top of its parent. Finally, we are ready to create our row of buttons. Since we have 8 buttons to create and pack, it will be easiest to do this within a for loop. Our loop variable will simply be called "i" and, since each button must have a unique name, we can use the value of this variable in the construction of the name. Remember that a for loop can count up or down. For our purposes, we will want to put button #7 on the left hand side and button #0 on the right, so we start with an initial value of 7 and work down to 0. Within the button, we will display some text in the center that indicates the button number (the current value in $i), we will raise the relief of the button so that it "stands up" a bit, we'll set the background color to white and, when the button is selected with the mouse, we will call a procedure named "readbutton" with a single input parameter of the number of the button to read. It will be the responsibility of that procedure to change the background color of the button just selected plus send the new value to the AVR so that it can be displayed on the correct LED. Once we have constructed our button with the complete command line, we next need to pack the button into the.row1 frame. We will put the buttons starting on the left hand-side and work our way to the right. We could just as 15

16 easily have started on the right-hand side and worked our way to the left. In that case we would have had our for loop count up instead of down. Having completed our row of buttons, we are now ready to construct our row of indicators. Tcl does not have a round display widget, although we could easily construct one. However, for simplicity, we can also use the button widget as our indicator! Since we can set the background color to whatever we want, we can use this to indicate whether a button on the STK500 is pushed or not. As long as we don't give it a command of something to do when the button is selected, it will simply look like a square lighted widget. As a bonus, it should be exactly the same size and shape as the buttons in the first row so we won't need to do anything fancy to make the second row line up correctly below the first row. With that in mind, our section of code for row 2 looks a lot like the code we used for row 1: # next, do the same thing for the indicator row frame.main.row2; # create a frame within which to pack the indicators pack.main.row2 -side top -pady 20; # install it as the next row down label.main.row2.lab -text "AVR Button State" pack.main.row2.lab -side top for {set i 7 {$i >=0 {incr i -1 { button.main.row2.b$i -text $i -relief raised -bg white pack.main.row2.b$i -side left -padx 10 The last row is the easiest of all. Since it only contains the Quit button and nothing else, there is no reason to create a separate row frame to contain the single widget; we can pack the widget directly at the bottom (or "last from the top") of the.main frame: # last, make a quit button to exit the program button.main.quit -text Quit -relief raised -command "destroy." pack.main.quit -side top -pady 20 If we had the above procedure coded in our source file, we would very nearly have enough to try and execute. The only problem we would have would be the fact that there is a procedure (readbutton) called from within the body of this procedure. We could get around this by simply adding a stub that does nothing: proc readbutton { { The last thing that we would need would be a line of code that calls the GUI procedure to actually create the screen. This could be done with a single line of code that the end of the file: GUI With just this code in the file you would have enough to pop up the window and see that it looked the way you wanted. It wouldn't do much at this point, however; the only thing that would be operational would be the Quit button at the bottom whose command "destroy." was completely defined in the construction of the button. The screenshot on the next page should be what the window looks like: 16

17 Now that we have the overall framework for our program, we can proceed to fill in the rest of the details. We already have the stub for the readbutton procedure and it turns out that this one is fairly easy to implement: proc readbutton {num { global buttonval port if {[.main.row1.b$num cget -bg] == "white" {.main.row1.b$num configure -bg "green" else {.main.row1.b$num configure -bg "white" update idletasks set buttonval [expr $buttonval ^ (1<< $num)] puts -nonewline $port [format %c $buttonval]; # write the byte to the AVR The purpose of the procedure is to check the background color of one of the buttons on the top row of the GUI. The specific button is passed in as an input parameter. Since we have decided that the button would act as a toggle, all we need to do is get the interpreter to tell us what the current background color is and then set it to the opposite. This is done by giving the full widget name of the button we are interested in, using the "cget" command and indicating the configuration option that we want to get. Note the square brackets around the statement which will cause it not only to be executed, but the output value returned to us. This should be the string "white" or "green" and we will turn around and set it to the opposite color. Our script is fairly simple, but it is still possible that the interpreter could be performing other processing in the Event Loop. Consequently, although we have made a change to the display, if the interpreter is busy the change could be delayed. Fortunately, we can tell the interpreter to update the display immediately and this is done with the update idletasks statement. We also maintain a byte value of all button settings in a global variable called buttonval. We can update this by toggling the appropriate bit position (ie: Exclusive ORing it with the value 1). Finally, this byte value is written to the COM port using the puts command. Recall that variables are in string 17

18 format but we want to write binary data. We can use the format command to convert it with the %c parameter, indicating that we want it converted to binary. Also, Tcl normally appends a newline character whenever we use the puts command, but since we are writing a single byte of binary data, we don't want this and can prevent it with the -nonewline option. The next procedure we need to add handles the second row, which contains the indicators that reflect which pushbuttons are being pressed on the STK500: proc updatedisplay {pb { for {set i 0 {$i < 8 {incr i { if {[expr $pb & (1<<$i)] {.main.row2.b$i configure -bg "white"; else {.main.row2.b$i configure -bg "blue"; update idletasks # bit is high (off) # bit is low (on) The procedure is passed a byte value that represents the switch setting on the STK500. Each bit is examined in turn and the background color of that button is set. Here, we'll use blue to indicate a pushbutton that is pressed. Like before, when we have finished with our changes, we can force the interpreter to update the display. The last procedure we need to complete our script is the one that opens up the COM port and processes any incoming data: proc openport { { global comport combaud comparity comdatabits comstop port if [catch {open $comport r+ port] { return $port; # we got an error - return it to the calling routine fconfigure $port -mode $combaud,$comparity,$comdatabits,$comstop fconfigure $port -blocking 0 -buffering none -translation binary \ -encoding binary We have "hard coded" our serial port parameters as global variables in the front of the program. A more user friendly approach might be to allow the user to specify them to the running script by providing radiobuttons for the baud rate or an entry box where different values could be typed in. However, this would add a layer of complexity that we are trying to avoid in this simple example, so for now we will use the embedded values and the user can change to variables at the front of the script if needed. The first thing we need to do is open this communications channel. Like most operating systems, Windows keeps track of which process is using a given resource, so if it turns out that the COM port we need is busy or perhaps doesn't exist, Windows will return an error. We need to be able to handle this error and in Tcl this is done with the catch statement. If everything goes as planned, the COM port will be opened and we will get back a channel identifier that we can use to refer to that channel in future transfers. That ID will end up in the variable "port". If 18

19 Windows returns an error, the catch statement will handle it (rather than having the interpreter halt due to the error) and the error information instead will be placed in the variable "port". In the case of an error, we return immediately with this "non-zero" value to indicate to the routine that called this procedure that the channel is not open. Assuming that the channel opened correctly, we next need to configure it. This is done with the fconfigure command. UARTs have some unique additional parameters that are required, such as baud rate and parity, which we will set up first. We will also use the fconfigure command to tell the interpreter that we will be working with binary data, rather than ASCII, and not to try to automatically perform any translations for us (Tcl can automatically handle things like end-ofline character translations between different platforms). The last thing that needs to be done is to install a fileevent handler which tells the interpreter what to do when data is received on the UART. The handler will work almost like an interrupt service routine, performing whatever actions we have specified when read data is available: fileevent $port readable { if [catch {read $port 1 byte] { tk_messagebox -message "Error reading COM port data: $byte" -type ok return else { scan $byte %c comdata updatedisplay $comdata; # use the input byte from AVR to set indicators return 0 Within the handler we will read 1 byte from the channel using the $port identifier. Since there is always a possibility of getting an error, which would be returned by Windows to the Tcl interpreter, we need to handle this with the catch statement. If this happens, we will pop up a window letting the user know that an error occurred, but otherwise we'll keep running. If the data is retrieved successfully, we need to convert it from the incoming binary to the string representation that Tcl uses. This is done with the scan command and performs the opposite function of the format command we used in the readbutton procedure. Next, we will call the updatedisplay procedure with the data as the single argument so that our GUI will reflect the new button press information. This completes our procedure; if we got this far, then we can return a value of "0" to the calling routine to indicate that the COM port is open and ready for business. That's pretty much it for the PC end of things; we have now covered nearly everything present in the listing at the end of this article. The only thing we didn't cover is the setting of the global variables at the front of the script, whose purpose should now be obvious, plus the small section of code at the end that calls the openport procedure and processes the return value. 19

20 The AVR Program The operation of the program for the STK500 was described previously and has been intentionally kept as simple as possible. It is implemented in assembly language since it is hoped that this could be a common denominator between most users, having only to download AVR Studio to have all the necessary development tools. The only thing that might not be readily available to all users is the STK500. However, if the user has access to any other hardware that supports an RS-232 interface, it should be relatively easy to adapt the program. Since it is assumed that the user already has some familiarity with the AVR and assembly language programming, we won't go into the levels of detail that we did for the Tcl script. Suffice to say that the program is implemented with two main sections; a startup portion that initializes the I/O ports, UART and then walks a bit through the displays to indicate the program is operating. This is followed by a main loop that reads the pushbutton switches and writes their value to the UART if there is a change, and then checks the UART to see if there is new data from the PC to be used to update the LED display. That's all there is to it. Like the Tcl script, the assembly language listing is also shown at the end of the article. Setting Up The Hardware Connect the RS232 CTRL port on the STK500 to a COM port on the PC using an RS-232 cable and then connect a power source. To be able to program the AVR from Studio, you will need to connect a 6-pin ribbon cable between the ISP6PIN header and the adjacent SPROG3 header. A 10-pin ribbon cable will be used to connect the SWITCHES header to the PORTA header and another 10-pin ribbon cable will connect the LEDS header to the PORTC header. We also need to hook up the RS-232 pins that the AVR will use; this is done with a 2-pin jumper cable between the header marked RS232 SPARE and the top row of pins on the PORTD header. Verify that the pin marked RXD is connected to PD0 and that the pin marked TXD is connected to PD1. When you are done, it should look like the picture below: 20

21 The next thing we need to do is assemble our AVR program using AVR Studio. Open AVR Studio and, in the New Project Wizard, click on the Create New Project button. Enter a name for the project and click on the Finish button at the bottom of the Wizard window. This should take you to the main screen where there will be an empty window to be used for the creation of the program. Copy and paste the program from the listing at the end of the article and then press the F7 key to assemble the program. Apply power to the STK500 and then click on the AVR programming icon located in the Studio toolbar. As small as the assembled file is, it will only take a moment to program the AVR. Once finished, close Studio and power down the STK500. The RS-232 used by the AVR is on the connector marked RS232 SPARE so move the serial cable to this connector and power up the STK500 again. You should see each of the LED displays light up briefly as part of the sanity check we put in the initialization section. Once this completes the program will be in the main loop looking for something to do. If you have not already done so, copy and paste the AvrControl.tcl script from the listing at the end of the article. Once created, start the script and you should see the GUI pop up. Click on any of the buttons on the top row and the corresponding LED should light on the STK500. Next, press any button on the STK500 and the corresponding indicator in the second row should turn blue while the button is pressed. 21