PROGRAMMING BRAINS

Three main steps were involved in integrating EMIT software into the sprinkler-system application:

· include the emMicro code module in the application

· create the resource tables

· insert calls into the entry points of emMicro

The first task is usually handled via an include statement placed after the application code.

Information about the application is specified for the browser interface from the resource tables. Creating the resource tables is just a matter of editing the example tables included with EMIT to match the application’s needs.

For example, my sprinkler controller primarily uses the variable table to make a large number of variables (e.g., Hrs, Min, and Sec) visible to the web-browser interface. These tables tie the browser interface to the microcontroller application. Listing 1 presents a section of the variable table.

public void notifyChange(String variable, Object value){
  if(variable.equals("Sec")){
    seconds = ((Integer)value).intValue();
    timeDisplay.setSeconds(seconds);
  }
  else if(variable.equals("Hrs")){
    hours = ((Integer)value).intValue();     
    set_hours();
  }
  else if(variable.equals("Min")){
    minutes = ((Integer)value).intValue();
    timeDisplay.setMinutes(minutes); 
  }
}

The structure of each table is similar. The first byte is the number of elements in the table. This sprinkler controller uses 37 variables, so the first byte in the variable table is 37.

Next, EMIT components process user requests to view and set device information. There are two bytes to describe the type of each variable (byte or word) and whether the variable is read-only or read/write.

Finally, variable names are placed into the table in the form of NULL-terminated strings. Other tables specify events, functions, static documents, and capabilities. Once these tables are created, they are included at the end of the application source code either via include statements or by directly including the tables.

Placing calls to the emMicro entry points is straightforward because there are only two. However, there are some rules that applications must obey.

One entry point is the serial port interrupt vector entry. emMicro has its own serial ISR, but the vector has to be installed into the microcontroller’s main vector table. The other entry is the main emMicro entry (called emMicroEntry).

For an application to coexist with emMicro, the application must be written using a cooperative multitasking methodology. Each process, including emMicro, is called by a main calling loop, and it must respect all the others by releasing the process control back to the calling loop in a timely fashion.

"Timely," of course, depends on how often each process really needs to have the processor’s attention. emMicro must be called at least often enough to receive each character from the serial port.

No process should ever stall the processor in a tight loop waiting for some event to happen. That’s what interrupts are for.

The only other rule is that no process should get exclusive use of the CPU registers. Each process can use them without regard to their previous state.

This design has several advantages. First, the clock is set from the browser. Not a single line of code in the microcontroller application is occupied with how the clock is set. Also, all the configuration parameters are adjusted without any code in the microcontroller.

Forcing the browser to display new information (or fancy graphics) is as easy as changing the value of a variable in a resource table. If the microcontroller application calls for a special function to be executed when a button is pushed on the browser interface, you only need to write the code for the function. emMicro executes it for you.