If you're very new to the Propeller, you may not have considered its architecture vis-à-vis other micros. In a Propeller-based system, the program code is stored on
an external 32K EEPROM (it can be larger, but only 32K is
used for program space). On reset, the Propeller will copy
the contents of the EEPROM to internal RAM for
execution. The up-side of this architecture is that we can
modify the EEPROM with the current program to affect
things the next time it reboots. On the extreme end of
that scenario, we can replace the code in the EEPROM
with a completely new application.
In previous projects we've used SD card access
(fsrw.spin) to read files, and an EEPROM object
(jm_24xx256.spin) to read and modify the boot EEPROM.
The code presented here will combine these elements to
simulate our project being reprogrammed from an IDE
(integrated development environment), though it will
happen in place — without a computer connection — and
on demand. As was the case for our customer, this will
allow us to selectively run multiple applications that
wouldn't otherwise fit into 32K if combined on a Propeller
board that has an SD interface.
Propeller Image Files
Propeller IDEs allow us to download to RAM, or to
RAM and EEPROM. How does this work? When a
download request is made by the IDE, the Propeller runs a
bit of boot loader code that is embedded in the silicon.
The boot loader facilitates moving the code from the IDE
through the serial link and into the Propeller's RAM. If the
EEPROM update is part of the request, the Propeller will
write what's in RAM to the EEPROM.
If you use the Propeller Tool (Windows only), pressing
F8 will display the Object Info window as in Figure 1. This
displays the compilation details
and allows us to save the file in
BINARY or EEPROM format. Why
The EEPROM format creates a
32K image file that can be used by
EEPROM programmers; this allows
a high-volume manufacturer to
preload code into the EEPROM
before it is soldered to the PCB
(printed circuit board). We could,
in fact, copy an EEPROM file from
the SD card to the Propeller's
EEPROM and reboot — I've done
this and it works. That said, most
applications don't require the
entire 32K; in fact, most of the 32K
is available for variables and the
The BINARY option creates a
Load and Go!
I've written a fair number of Propeller
applications and — until recently — never
had a problem fitting one into 32K of
memory. Last year, my friend John and I
(EFX-TEK) began work with a gaming
company to develop a new controller for
one of their products. Moving from a small
PIC to the Propeller gave them the
opportunity to add exciting new features. In
the end, though, we just couldn't fit
everything into one application. On
analysis, what they wanted was, in fact,
three discrete applications for the board.
Moving between these apps would be
infrequent, and didn't need to be
instantaneous. As the product includes a
microSD card, I developed a bit of code to
load the pre-compiled apps from it.
■ BY JON MCPHALEN THE SPIN ZONE
16 February 2015
■ FIGURE 1. Object information.