Issue 132 July 2001
Liquid Crystal Delight

Start • Working Glass Hero •Quarter Horse •Software To Boot •Widge Warrior •Highway Star •Beta Site •Take It Easy •Sources & PDF

HIGHWAY STAR
Let’s give the starter kit a whirl around the block. I’m a novice when it comes to web page editors and HTML, so it’s all the better that I needed to fill the gap in my quiver of display options. I figured I would be a good test case to see whether or not the Easy GUI concept truly lives up to its name.

I decided to prototype a simple automotive display. Judging by the amount of e-mails I receive, the articles I’ve written about combining computers and cars strike a chord with a lot of you. Someday, I hope to update my last mobile project (“On the Road Again” Circuit Cellar 118 and 119), which put an SBC into my van’s J1850 network, and a mid-range bitmap display would be the ticket.

My sample interface (see Photo 3a) consists of various widgets including numeric field, bar graph, and line plot representations of a variable (rpm), and four touch-sensitive function buttons. The rpm is updated from the host via RS-232. Pushing any of the buttons causes a unique code signifying the event to be sent to the host.

To make a long story short, I was indeed able to get my sample interface working in relatively short order, as you can see in Photo 3b. Referring to the HTML source (see Listing 1) is a good way to see what’s going on. It starts with some preamble stuff, including the “Amulet” META statement, which conveys hardware-specific information (in this case, the baud rate) to the chip without upsetting the web page editor or browser. As this is a monochrome unit, all color designators are simply ignored.

Next, you see the definition of a 320 × 240 table (corresponding to the resolution of the LCD) that’s required to set the stage for your interface.
Following are seven applet code sections, one each for the (numeric) Field, BarGraph, LinePlot, and four FunctionButtons. Each incorporates a list of parameter names and corresponding values that define the appearance and behavior of the widget. Let’s go through them one by one for the Field.class, the first numeric field showing rpm.

The fontsize and fontstyle parameters are self-explanatory. Note that currently Amulet supports only a single sans serif font, and size choice is limited to 8, 10, 12, 14, and 18 points.

Href defines the data interchange with the host, with “1” identifying variable 1 as the source of the rpm value. Skipping down to the last entry, you can see that the desired update rate is 1.0 (allowed range is 0.01 to 655.35 s). So, once per second the Amulet board will send a request to the host for the value of variable 1.

One limitation is that variables are only 8-bits wide, so I decided to have the host send rpm divided by 20. On the other hand, a nice touch is that the widget incorporates scaling as defined by the min, max, minfld, and maxfld parameters. The variable value between min and max (i.e., 0–250) is automatically scaled to the corresponding value between minfld and maxfld (i.e., rpm multiplied by 20). Finally, the printf parameter defines the way the field is displayed using, as the name implies, C-like format options and syntax.

Similarly, the BarGraph and LinePlot parameters define the data source (also variable 1, rpm) appearance, update rate, and so forth.

Skip down to the function button widgets. What happens when they are pressed is defined by the href parameter. In this case, the value is Amulet:function(1) for the first button, Amulet:function(2) for the second, and so on.

This means that when the first button is pressed (Tach), the Amulet board will send a command to the host to invoke function 1 for the first button, function 2 for the second button, and so forth. Other options for handling a button press include switching to a specific page or returning to the previous page.