Loading code from sd, possible?

[uN_Eof]

Hey all, I want to load some code from a SD card, is this even possible?

Thanks in advance.

[FvM]

Except for few special devices with external memory interface, e.g. PIC18F852x and similar, 8- and 16-Bit PICs can only execute from internal (flash) program memory. Code from SD card must be programmed to flash before it can be executed. Due to limited flash durability, it's only usable for occasional code update.

PIC18F852x in contrast would allow code execution from external RAM.

[Ttelmah]

You could though build a bootloader, which looked for a specific filename on an SD card, and loads this. However, it will be quite builky (FAT file system, SPI drivers, etc. etc....).
Or of course, write yourself an interpreter, which runs 'script' operations from an SD card in your own language.

Best Wishes

[uN_Eof]

I think writing my own language its (or at least looks like) difficult.
Can you please explain a little bit the "sd bootloader"?

Thanks in advance again

[FvM]

See an example of a ready-made SD bootloader:
http://www.brushelectronics.com/

[arunb]

The script language is easy enough to make, something similar to BASIC should be good enough for most applications.

[uN_Eof]

@FvM what that does is reprogramming the internal flash of the pic and thats what i domt want.
What i want is to directly load the code from sd.

[Ttelmah]

Fvm, has already told you - you can't.
Code directly 'run' by the PIC processor can come from:
1) The internal ROM.
2) In a very few cases externally connected _parallel acces_ ROM.
3) Something like an ICD.
SD, is none of the above...
You either have to copy the SD into the ROM (which is what the bootloader does), or have an interpreter running in the PIC, that uses the SD card contents as it's 'program'...

It is worth realising, that even on the PC, you can't 'run' code on an SD card. On the PC, because it has a 'flat' memory architecture (only one memory space for RAM, and ROM), when you 'run' code on an SD card, it is copied into the local RAM, and run from here. It is slightly harder on the PIC, with separate RAM, andf ROM spaces, but if you selected one of the chips which will run code from an external memory, you could attach a static RAM, with 'dual port' access, then write the code from the SD into the write port of the RAM, and then run this. However it is still going to have been copied into the PIC's memory space, not 'run from the card'.

Best Wishes

[collink]

The interpreter idea is basically the only thing that would work across all chips. It could likely be made to fit in 4-5k of program ROM and less than 1K of RAM if FAT support is not there (thus requiring a RAW file system or something else less complicated than FAT.) The higher level the interpreted language is the faster things will likely run. At the low end the scripting language could be straight PIC assembly but that would be very slow as the interpreter would have to individually parse and run each asm instruction. It's thus faster to have each scripting item be a larger, higher level construct that runs many instructions per script action.

Ideally such a language would be like BASIC (as it's fairly simple to create a BASIC interpreter) but also have a large number of built-in functions that the script can call. For instance, if the scripted program does a lot of menus then have menuing functions built-in. If it does a lot of serial I/O then have those built-in, etc. Obviously every built-in function adds to the overhead of the interpreter.

In the end this sort of scheme could be somewhat tricky to do but would effectively create unlimited program space. Some of the potential snags:

1. Have to support demand loading of SDCard pages. I believe that SDCards tend to be read in 512byte chunks so the script would have to be loaded 512 bytes at a time. If FAT isn't used then something else has
to track how the script is stored and which piece to grab.
2. What if the script has functions and there are two functions, one calls the other, and they end up in different 512 byte chunks? Say hello to thrashing! This can be eased by loading more than one chunk (say, by saving the last loaded chunk so that the two more recently used chunks are resident.)
3. Interpreters are slow. Doubly/triply/majorly so if you have no idea what you are doing.

All that having been said... This has got me thinking about it anyway. I've got an application where I can't change the hardware but I've got an SDCard and I'm really tight for code space. This sort of scheme might be viable.... Sounds like a lot of work though.

Is anyone aware of a good open source interpreter for PIC that supports sdcard loading? That seems like a tall order. ;-)