Programming Microcontrollers

You can program microcontrollers in assembly language, but it’s not recommended. There are so many tools available to simplify programming embedded devices using higher languages that fiddling with Assembler isn’t worth the trouble, even if you already know the language. The best way is to create all of your software on a PC-class computer, then deploy it to your embedded microcomputer. It’s a two-step process.

First, you have to develop on your PC the software that will run on your microcontroller. To test the software, however, you will need a separate program that will simulate the target system. This simulation system exists only as software.

Simulate it

Think of the simulated system as a black box to which you send the control variables that your control software sets, and from which you get response variables that mimic what you should get from your target-system sensors.

The simulated system likely has its own “control panel” that you can use to manually simulate faults, changes in environmental conditions, and so forth. Remember, all you are doing is changing values of variables shared by the two programs, which run simultaneously on your PC.

Once you have written and thoroughly tested your control software, you are ready to deploy it to the microcontroller, which your hardware folks have built and connected to a pilot version of your target system.

As you can see, this is a complex process requiring you to create and integrate a lot of separate components. To do it successfully, you need all the help you can get. So start with the company that makes the microcontroller you plan to use. All major semiconductor fabricators provide development kits to help you get through the process with as little angst as possible. Three that jump to mind are Rabbit Semiconductor, Freescale Semiconductor, and Advanced Micro Devices (AMD).

3GL & 4GL

You should plan to write your application program in at least a third-generation language like C. Third-generation languages are robust, general-purpose languages that are easy for humans to understand and write. Assembler, though, is a second-generation language that works at a low level and changes with the target processor. When writing in an assembly language, you have to keep track of all the registers, memory locations, etc., yourself. Third generation languages take care of all that.

Fourth generation languages – sometimes called “frameworks” – step up one level in abstraction. National Instruments’ LabView, for example, provides objects (called “virtual instruments” or “VIs”) that collect all of the lower-level code modules needed to communicate with, for example, a data acquisition board, or a motor drive. For example, for a power-generation system, you might create VIs to control entire gas-fired generators from sub-VIs that read sensors and operate relays.

When dealing with third and fourth generation languages, you communicate with the actual hardware you are controlling through software “drivers.” Drivers are code modules written in second-generation languages by the companies that manufacture the computer-controllable hardware components (such as drives for electric motors) that you need to make anything happen in the real world.

If you program with third-generation language, you simply include the appropriate driver library and use the high-level commands the hardware manufacturer provides. With fourth-generation language, it gets even simpler.