Serial Ports & User Interfaces

Serial Ports

The Arduino, the Basic Stamp2 and other similar development tools often use the Serial Interface for communicating with attached computers. This is clearly the most efficient and cost effective method since it requires very little overhead, unlike using ETHERNET or Radio Communications, etc.

Creating a user interface for these devices with either a Linux or Windows PC is as simple as writing a terminal program that drives a custom GUI. I could use Visual Basic or C if I wanted stick with windows. To be really flexible, I could use a language like Perl, Python or TCL/TK.

So I did some research. I really like the way TCL/TK works. It understands that you might want to interact directly with the operating system. It has not forgotten that we love our serial ports. In essence, I think TCL/TK is ideal for working with PC’s and micro-controllers via the serial port.

On the other hand, the serial port seems to be destined to become a legacy item. While the Arduino now uses a built in USB-Serial bridge on board, getting connected to the communications port that the USB creates is sometimes a little tricky. You see, serial ports were historically considered to be physically part of a machine. Why would you even need more than 4 or so, right? Now, with the USB, you could easily have many more than 4 since the USB port needs to avoid the potential of stepping on physical ports.

Many Microsoft programming languages and API’s had built in support for up to 9 serial ports. If your USB-Serial bridge created COM11… you might run into trouble writing code to access it. Another problem, many of the freely available terminal programs have limited support for high com ports. Some actually stop at COM4.

Back to TCL/TK

This scripting language is mature and just plain cool.  Few scripting language solutions let you take Graphical User Interface  code written for a UNIX platform and plop it unchanged on a Windows platform (with TCL/TK installed) and have it run… with no modifications.  There is also a solution that wraps the “interpreter”  and script into and executable so a system doesn’t really have to have TCL/TK installed.

TCL/TK is available on the PC for Windows as well a Linux.  This amount of flexibility is really interesting to me.  Being able to use either with practically the same code means that I don’t  have to decide immediately which platform I’m coding for.