Servo - October 2010

5150 Capability in a Microcontroller?

Before I wedged in that 5 MB hard drive, my trusty old 5150 booted Bill’s DOS from floppy disk A:. All of the 5150’s hardware drivers (BIOS) were loaded into a couple of ROMs, and DOS or any other program loaded into the 5150’s memory depended on being able to access the BIOS services. The same computing paradigm that my 5150 used is still being used in today’s PCs. The difference is that modern PCs store their BIOS routines in Flash or EEPROM. Instead of installing a new set of ROMs, BIOS is changed or updated by downloading new firmware to the BIOS media via a loader program running on the PC itself.

Hard drives and floppy drives are not normal participants in smaller embedded environments under the control of a microcontroller. However, that same 5150 computing paradigm can be a useful addition to a small microcontroller-based embedded system. In most instances, a microcontroller application is coded, assembled, linked, and programmed into the microcontroller’s program Flash. The microcontroller application does not change unless the microcontroller is reprogrammed with a differing piece of application firmware. If we were to allocate a portion of the microcontroller’s program Flash area for a nonvolatile resident sub-application that could load an application into the microcontroller’s program Flash on the fly, we could load and run differing embedded programs in the same manner as we do on a laptop or desktop PC.

The 5150’s applications lived in RAM. Thus, the “program memory area” of the 5150 being RAM could be read, written, and erased at will. For the 5150 boot device paradigm to work in a microcontroller, the microcontroller’s program Flash must also be able to be read, written, and erased just like the 5150’s RAM. Most all of the new PIC microcontrollers have the capability to read, write, and erase their program Flash areas without any external assistance. Thus, if we can select a suitable PIC to interface to the MicroSD card hardware, allocate a bootloader program area, and write some bootloader code, we can load applications saved on the MicroSD card into the PIC. That one-trick robot now has the capability of loading and running any application that it can access from the MicroSD card.

Building a Bootloader

PCs have operating systems such as Windows and Linux that provide the power behind moving data between storage devices and the CPU complex. In the case of the PIC, the power wielded by Windows and Linux is contained within the Microchip memory disk drive file system.

/* Initialize the boot loader IO */
BLIO_InitializeIO();

The PIC’s SPI portal is initialized and the analog-to-digital lines are configured depending on the needs of the application. By the way, the MicroSD card communicates with the PIC18F46J50 via a SPI connection. So, initializing the SPI portal as quickly as possible is very important.

Following the initialization sequences, the bootloader sub-application begins a timed wait to determine if it needs to load a new image from the MicroSD card or simply restart the application that is currently blown into program Flash:

while (i < 300000)
{
/* Check to see if the user requested
/* loading of a new application */
if (BLIO_LoaderEnabled() == TRUE)
 {
  BLIO_ReportBootStatus(BL_LOADING, “BL: Loading
  new application image\r\n”);

In the case of the PIC18F Starter Kit, the user depresses a pushbutton which is tied to a PIC18F46J50 I/O pin to force BLIO_LoaderEnabled() to return a Boolean TRUE. A adhoc software debounce routine is executed which falls into the meat of the bootloader sub-application if the debounce code is navigated successfully: