Give Your Robot
the Bootloader
by Fred Eady
I’m a 1950’s kid. Thus, my first encounter with a robot was via television.
If a robot didn’t look like and act like Robby, it wasn’t a robot. Later in my
elementary school days, Robby was replaced by Robot B9 of the Lost in Space series.
It is speculated that Robot B9 was also known as GUNTER which is an acronym for
General Utility Non-Theorizing Environmental ROBOT. As movie and television robots
became more cerebral, I remember going on a ninth grade science club road trip to
see HAL in the movie 2001, A Space Odyssey. I actually fainted in the theater.
As the years passed, the robots amassed. Good old Star Trek offered up every kind of robot that one could imagine, ranging from the beautiful bevy of Harcourt Fenton Mudd’s Women and the android copy of his nagging wife Stella, to
the Borg. The robots that were missed in the Star Trek
series were realized in the Star Wars chronicles.
Here’s a question for you. How many QWERTY
keyboards can you remember seeing being used to update
the firmware in robots like Robby or B9? How about,
NONE! Recall that Star Wars’ R2 units routinely attached
themselves to data access portals on star cruisers and star
bases. To me, that implies that any type of initial R2-D2
firmware loads came by way of a process we currently call
bootloading.
As a child, I saw robots as humanoid programmable
electromechanical devices with super human strength. As
an adult, my robots are television set-top boxes, network
routers, personal computers, cameras, telephones, and the
gadgets that you and I build. The common factor in all of
my “robots” is their ability to update the way they work
without having to be reprogrammed by a human with a
physical device programmer. For instance, from time to time
the satellite box that services my television informs me that
it downloaded a new feature or a program fix via the
satellite link. The Canon 7D that I use to capture the photos
for our SERVO discussions can also be fixed or updated via
an image that I can transfer to the camera using the USB
portal on my laptop. My Canon and my satellite box have
one thing in common: They are endowed with some sort of
bootloader core.
Not every device capable of accepting fixes and
features via the bootloading process needs to have a
satellite, USB, or Ethernet connection. We can use proven
58 SERVO 04.2011
“it ain’t dead yet” RS-232 techniques to load executable
images into the robotic devices that you and I create.
Bootloaders From a
Robotic Perspective
As a robot head, bootloading provides yet another
layer of control for you. Once the base bootloader code is
loaded into the robotic device’s program Flash, you have
the ability to read, write, and erase the program Flash
without having to use a hardware programmer. Since you
have privy to the microcontroller’s program Flash, you also
have programmatic access to all of the microcontroller’s
resources which include the microcontroller’s EEPROM,
SRAM, and configuration memory area.
To utilize the bootload process, the target
microcontroller must be able to store the incoming image in
a buffer for later programming if the currently running
application cannot be interrupted. If the resident application
can be interrupted and the new incoming bootload image
data is coming in faster than the microcontroller can write it
to Flash, the microcontroller is still required to be able to
store the bootload image in a buffer.
Today’s microcontrollers can do some incredible things.
However, they can’t compute on their own. Thus, a
bootloader program must be initially loaded into the
microcontroller’s program Flash manually. The core
bootloader code is loaded and positioned as to allow the
bootloader application to always reside in a protected
portion of the microcontroller’s program Flash. Normally,
the entry point to the core bootloader program is loaded at
the microcontroller’s execution start point. This allows the
bootloader program to run at every microcontroller reset. It
