I have used a couple of single board computers (SBC's) from New Micros Inc. in Dallas, TX as controllers for oceanographic sensors. The particular boards I've used are the 68HC11 and 68HC12 cards, along with a few accessory cards. Schematics of controllers using these cards can be found in the TAPS-6 and TAPS-8 sections on this site.

The 68HC11 card came with FORTH embedded in the ROM on the cpu chip. A later variant added floating point to the ROM and I exchanged this CPU for all the previous ones to get this feature. I had actually heard of FORTH before I got my hands on one of these SBC's. A friend in Oregon had told me casually, one day, that he had written some code in FORTH and that it was very strange stuff indeed. Used things like commas as commands. Strange indeed. But I needed a very low power CPU card to run some sensors I was building for a mooring that would have to run on batteries for long periods unattended. And this SBC had the least current draw of any that I found. So ... I had to learn FORTH.

I bought the book by Leo Brodie, "STARTING FORTH" (available on-line at FORTH, INC) and started learning. With the 68HC11 SBC, the card became the language lab. Hooked it up to a PC running a serial terminal program (BitCom for the 80386 cpu -- still use it today!) and applied power. The card sent a startup message line and was now ready for me to program.

FORTH is a peculiar sort of O/S, reminiscent of the BASIC O/S that came on the early Apple computers. It consists of defined WORDS which you can call directly from the command line. You can also define new WORDS using the old WORDS and any new WORDS you have previously defined. Typing the name of any of these WORDS will cause that WORD to be executed. If you think SUBROUTINE for WORD, then this isn't all that strange. Generally, one builds a program by defining WORDS that do specific things -- collect data from an ADC, generate ping gates on a digital line, convert a number to dB, etc. Each word can be tested by itself until it is working properly. When the whole program is done, there will be a last WORD (I always call mine MAIN) that starts the whole thing going.

Another peculiarity of FORTH is the use of stacks to hold data. WORDS exchange data using the stack. If a WORD requires some input data, the typical way to provide it is to put the data on the stack before calling the WORD. Being FORTH, this is done as schematically as possible: if the data were held in locations called, say, DATA1 and DATA2, and the WORD that needed the data was called PROCESS, then the calling sequence would look like


In other words, naming a data variable and calling the WORD "@" (fetch) puts the data on the stack and naming (typing) the WORD "PROCESS" evokes this code. The answer will, in all likelihood, also be placed on the stack.

On the 68HC11 board, I tested the program by loading it into RAM in the upper 32K of the 64K memory map. The SBC had a socket for a memory IC. When I was happy with the program, I would make a Motorola S-file image of the program (by running a program supplied by NMI) and save it in a capture file on the PC. I used this file to burn an EPROM which I installed in place of the RAM chip and there was an operating sensor controller. (There are some details left out here, such as autostarting the code. But since the supplier has closed shop, the details are now moot). The picture below is one of the 68HC11 cards offered by NMI:


I've used these SBC's to control acoustic sensors, including TAPS-6 and TAPS-8, as well as weather stations and little lab gadgets where a bit of smarts were required. One nice feature is the ability to enter a sleep mode where current draw is too low to measure accurately (maybe 100 microamps). I use a RTC chip to issue timed interrupts to wake up the CPU and cause it to collect data

More recently, I've switched over to a 68HC12 SBC. This was partly to get the faster processor on the HC12 and partly in order to save a large amount of code I've written for the HC11 which can be migrated over to the HC12 chip. I figured out how to interface the HC12 SBC to a compact-flash RAM card so that I had lots of memory for data and even for programs (see the DOWNLOADS page). The new-generation TAPS-6 uses a controller with the 68HC12 SBC and a 128 MB CF-RAM card. The operating programs run in RAM on the SBC and are loaded from the CF-RAM card as needed. A relatively small section of the CF-RAM card is devoted to program space and the rest is available for data. This is the processor in the WHAPS/SandScan series of sensors, as well.

The principal drawback of the 68HC12 is that it seems to be impossible to invoke a low-current STOP or WAIT mode in a practical circuit. I have searched diligently for the proper sequence of calls, port setups, etc. to obtain the low current shown in the electrical specs -- including email dialogs with a factory engineer -- without any success. This 'feature' severely limits the value of this processor in battery-powered sensors.

There are other choices available for SBC's for embedded systems. The Persistor is a terrific card with many nice features; I have one that I'm going to embed in something one of these days. The main drawback -- to me -- is that the only way to program this card is via a complicated programming environment in, of course, C. I've already mentioned I don't like C. The Rabbit cards are also pretty slick. They have quite a choice of cards with various I/O possibilities, including USB and ETHERNET. I have two of these that I'd also like to embed in something. Again, however, the code support comes in a C environment. Ugh.

Late last year (2014), I ordered a computer card from EZsbc, their model EZsbc1. This card is built on a 40-pin DIP outline so it could be considered a chip as well as a computer card. It comes with BASIC installed so programming it requires only a terminal program running on an external computer. It is powered by, and communicates to the host, on a USB port. Gettting it up and running was pretty simple. I didn't have anything particular in mind for this card when I bought it, but for $40 it was worth just for curiosity's sake.

I experimented with it as a controller for an acoustic echosounder. It was pretty easy to set it up to generate Transmit gates and sample analog signals (although the adc speed isn't high enough for my HF applications). It has an SPI bus so it could control a DDS chip (and I could certainly put a faster ADC on this bus but I don't know if it would be fast enough or not, yet). Other than being a bit rusty at BASIC, it was dead simple to program.

Then I had an inspiration. Looking around the web for sensor modules, I ran across Adafruit and their various sensor cards. One of these sensors is a GPS module -- a complete GPS on a chip, mounted on a small pcb with a 9-pin connector. The I/O is TTL-level serial -- which the EZsbc1 conveniently has as well -- and the only other required inputs are +5V and ground. One of the outputs from this module is speed over the ground. you think this could be used to make a speedometer for my lakester? So do I! So a module is on its way to me.

They also offer a large (1.2") 4-digit LED display with a backpack card containing a sophisticated driver chip. This card has 5 pins: two pins for an I2C bus, two power pins, and ground. I bought one of these at an electronics store in San Antonio and, after a fair bit of flailing about, got it to work with the EZsbc. Now Adafruit offers a lot of software support for their modules, largely for the Arduino and Raspberry Pi computer cards. And the libraries they offer are in C, of course, since that is the programming environment most often used with these computer cards. I heartily dislike C and, after perusing the library functions supplied by Adafruit, was no closer to being able to drive the display than I was before I got it. Looking at a ton of alternate sites, and at the almost impenetrable spec sheet for the driver chip, I finally figured out the sequence of commands and data that have to be sent to this card to make it display numbers. After overcoming a hiccup in the I2C write command for the EZsbc, I got it to work.

I expect considerably less difficulty interfacing the GPS module. Then, with a simple 5V fixed regulator and a bit of wiring, I should have a speedometer. Can't wait to put in on the dash of the Durango and test it! A link to the page describing the build is here.