15
\$\begingroup\$

One of my projects would greatly benefit from being able to run a program that isn't stored in the microcontroller (but is instead stored in a SD card).

So, I'm looking for a device that will allow me to load the code from the SD card into RAM and then execute the code from RAM. Currently, I only have the programmer that comes with the PicKit2, so I'd prefer to stay with PICs.

Does anyone know which, if any, PICs can do this? If no PICs are capable of this, then what are some different micro controllers that would work for this? Preferably ones that are available in a breadboard compatible package.

\$\endgroup\$
3
  • 2
    \$\begingroup\$ huh?...What exactly do you need to execute from ram for? and what do you mean by 'static'? you aren't actually trying to write self modifying code are you? Are you talking about the lack of dynamic memory allocation? aka no malloc? \$\endgroup\$
    – Mark
    Oct 20, 2010 at 3:22
  • 2
    \$\begingroup\$ @Mark I want to be able to load a program from an external device, such as an SD card, and execute it. I'll try to explain better in my post. \$\endgroup\$ Oct 20, 2010 at 4:46
  • 3
    \$\begingroup\$ gotcha, the only PIC that i know of that would allow this is a PIC32. Unless you do something crazy like copy it from the SD card to the flash, which will eat flash cycles pretty fast if your switching programs often. Most small 8/16bit uC are heavily segmented between data(ram) and program(flash) space and don't allow the program counter to address ram (Harvard architecture, no memory protection, etc). \$\endgroup\$
    – Mark
    Oct 20, 2010 at 4:57

11 Answers 11

5
\$\begingroup\$

There are a few PIC's that allow you to add external program memory. I've never done this but Application Notes AN869 and AN778 has more information of how to implement the external memory.

\$\endgroup\$
13
\$\begingroup\$

Another option to consider is using an interpreted language for your programs stored on the SD card. This way, the processor isn't executing the machine code read from the card, it's just treating it as data.

This approach gives you flexibility at the cost of speed.

There are plenty of options to choose from: Survey of High-Level Language Interpreters/Compilers for Microcontrollers

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Roll your own DSL. This option appeals to me the most of all the solutions suggested. \$\endgroup\$
    – Amos
    Oct 20, 2010 at 15:55
6
\$\begingroup\$

As has already been said, PICs (other than the PIC32) cannot do this. You will probably have to go to the larger processors in any family or to a processor with an external memory bus as most microcontrollers have very limited RAM resources.

The MSP430 processors can run code from their RAM space but you will need something like the F5438 with 16k RAM space - running code in 128 bytes is not really an option!

If a processor has an external bus then you can put RAM into the code space. You may have to add some extra logic to map the RAM into two memory regions if the processor architecture does not allow data to be written into execution memory.

I have run code from RAM in an 8051 based system but that meant that the RAM had to be mapped into the EXTERN memory space for programming and then back into the CODE space for execution. The loader/monitor program handled the memory bank switching and loading. Please don't ask for the code - I did this about 30 years ago and it is long since lost (and written in PL/M-51)

\$\endgroup\$
5
\$\begingroup\$

None of the low and mid range PIC can execute from RAM because of their memory architecture.

Any ARM based CPU should execute from RAM. Although they tend to be in smd packages, there are quite a few 'DIP' size module that have the microcontroller already loaded. Have a look at the mbed or LPCXpresso for example. These both come with either a bootloader or, in the case of the LPCXpresso, a debug interface along with free compilers.

If you would prefer to stay with simple 8 bit micros, perhaps consider something from the freescale HCS08 Family. These can execute from RAM and there is a code limited version of the codewarrior IDE and C compiler available for free.

I'm fairly sure the MPS430 should also be able to do this, but I've not ever done it myself.

\$\endgroup\$
1
  • \$\begingroup\$ The mbed actually receives binaries by having them copied onto the inbuilt flash drive and then being reset. It shows up as a flash drive when connected to the USB port of a computer. If you can work out a method to either use the flash drive instead of the SD card, or set it up so that a binary from the SD card is automagically copied to the flash drive and a reset performed then you might be in luck. The mbed does not require a hardware programmer. \$\endgroup\$
    – Amos
    Oct 20, 2010 at 15:53
5
\$\begingroup\$

The Propeller loads its program from external storage.

\$\endgroup\$
1
3
\$\begingroup\$

I remember reading about a bootloader for AVRs that would re-flash the chip with a .hex file (presumably) from an SD card. I can't find the original source, but this Google search turns up a couple of interesting hits. Yes, I know this is AVR and not PIC, but you might find it useful if the PIC thing doesn't work out.

\$\endgroup\$
1
3
\$\begingroup\$

As other posters have noted, you can't execute from RAM on an 8 or 16-bit PIC, because they use a Harvard architecture (separate code and data spaces). Whether or not it is practical to load a program off an SD card and flash it to code memory depends on how often you are going to be doing this.

If you are trying to create dynamic environment like an OS which is overlaying programs constantly, then no. But in my case, I have a program that loads drivers as needed off of a 2 GB SD card. The PIC24FJ256GB110 has a 10,000 erase/write cycle minimum. Even if this was done five times per day, the flash would last a minimum of 5 1/2 years.

(Note: the 10,000 figure is a minimum. Typical erase/write cycles endurance might be five times that -- so if you are doing development, you can probably re-flash a processor 140 times a day -- every 3 1/2 minutes for eight hours -- and it might still last a year.)

\$\endgroup\$
2
\$\begingroup\$

At my school we used HC11 or HC12 processors with external RAM to load and execute programs on...but I forgot the name of the boards/kit :( In any case, Freescale HC(S)-line MCUs address RAM and ROM identically, so you can load code into RAM and execute it.

Taking a queue from blalor, the best solution might be to just add a button on your board that can reflash the PIC from data stored on an SD card that you insert with a bootloader. I can't imagine what wouldn't sort of code wouldn't fit on the larger PICs; if you have some static data (graphics, text, sound), keep that on external storage.

\$\endgroup\$
1
\$\begingroup\$

You probably can't allocate from RAM, but for your application you might be able to have a small loader in flash which can then read SD card data into the remainder of flash. I have used this approach with an SPI-controlled flash chip to allow firmware to be loaded from a wireless link and then installed once it was received completely; I can think of no particular reason it wouldn't work with an SD card, though an SD-compatible bootloader might take up some space.

\$\endgroup\$
1
  • \$\begingroup\$ I've done something similar for a device that had a few slightly different firmwares and purposes: Write all of the files to external SPI flash (which is available in sizes much larger than most microcontrollers), and reflash the controller with one of the images with the bootloader if a button is held down during reset. \$\endgroup\$ Feb 23, 2011 at 21:40
0
\$\begingroup\$

Quite a few microcontrollers will let you do this, sounds like not the pic. what you would want to do is have a bootloader that uses spi to read from the sd card, copy the program, which probably wants to be a known or hardcoded file name, probably in the root directory, parse that file into ram then branch to the program in ram. The ARM based controllers will certainly let you do something like this.

An alternative would be to have the bootloader read the sd card over spi and instead of copying to ram and branching burn to a portion of the flash. Probably want to have a button if button pressed on power up or reset then load new program from sd card, otherwise if signature or checksum looks good on that loadable portion of flash then on boot branch to that portion of the flash. Or perhaps if the sd card is present then load from it otherwise branch to the loadable portion of flash. Can use this method with arm based and avr based, possibly even pic based but my pic experience is dated. msp430 I would assume as well. Basically if you can re-program portions of the flash you execute from, from the microcontroller processor itself, and you have the few i/o pins needed for spi to talk to the sd card (and have enough flash to have a bootloader that can read from an sd card) you can use a method like this.

\$\endgroup\$
1
  • \$\begingroup\$ Hmmm, actually I have not programmed an avr from the avr, sorry that was over serial from a host. Brings up a third solution that you see a lot of cheap hobby boards doing...use two microcontrollers. In this case one would hold the other in reset, read the sd card, program the other micro, via serial or other, then release reset on the other micro. The hobby/eval boards often have one micro for the usb interface and it usually jtags to the other. \$\endgroup\$
    – old_timer
    Jun 10, 2011 at 4:03
-1
\$\begingroup\$

The PIC18F87K22 family of devices is capable of operating in one of two program memory modes, using combinations of on-chip and external program memory. The functions of the multiplexed port pins depend on the program memory mode selected, as well as the setting of the EBDIS bit. In Microcontroller Mode, the bus is not active and the pins have their port functions only. Writes to the MEMCOM register are not permitted. The Reset value of EBDIS (‘0’) is ignored and the ABW pins behave as I/O ports. In Extended Microcontroller Mode, the external program memory bus shares I/O port functions on the pins. When the device is fetching or doing table read/table write operations on the external program memory space, the pins will have the external bus function.

\$\endgroup\$
2
  • 3
    \$\begingroup\$ You should delete your other answer \$\endgroup\$
    – pipe
    May 3, 2020 at 23:55
  • 2
    \$\begingroup\$ user7181988 - Welcome :-) (a) Your two answers should be combined. (b) This answer is an uncredited copy & paste from section 8.5 of the PIC18F87K22 Family Data Sheet. As required by this site rule, when you include something in an answer (e.g. photo, image or text) which isn't your own original work, you need to properly reference it, including a link back to the original source. Therefore when you combine (or otherwise edit) your answers, please include that link. Thanks. \$\endgroup\$
    – SamGibson
    May 4, 2020 at 0:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.