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:
LoadApplication();
It’s very difficult to load a new image if the media that
SERVO 10.2010 59