PROGMEM Efficiency/wastage/overhead

Hello all, I dont know which to start with, a PIC or ARDUINO. i had decided to research on their capability to store data as i am considering a robot that will perform tasks sequentially. It may have so many tasks that it may need an external memory chip or by using the chip to store it in its own flash. I have done some research, and the info for PIC was easy to find (i sorta stumbled across it), which stated that it will use 14-bits to store 8-bits (at, 57% efficient. i cant find any info on the Arduino except some heresay stating that it will use a byte for every byte (at so what is the real usage? I never end up starting many of my projects so chances are it wont start, but im sure this question will help someone else who will find that they might be cutting it close, or save them some time when they miss.

for me, it will probably be 47bits of information: 12 or 13 for entry number, 20 for accuracy, 10 for duration, 4 for speed of action. 13^2 is 8192 entries maximum and with 47bits, this will total 48.1kByte - but i probably wont need half that, so 46bits * 4092 gives 23.5k (which is still kinda big for the 32k, and i dont know how many bytes the normal instruction takes nor how much code i need). using an external flash or rom probably wont have the overhead.

the idea was to use these instructions to guide a robot (or machine) over flat terrain without any external helps other than the instructions, on completion i would expect a 1% error (HA! theoretically, and probably 100% when wet!). Right now i only know VB so i still need to learn heaps.


From what I remember of 16x PIC architecture, it doesn't have an instruction to read its own program memory, so fixed lookup tables are implemented as jump tables, loading a literal constant from an instruction and returning.

If you're looking to store and modify a 23k program table (I assume you're talking about some kind of interpreter) at runtime, stop looking now, because unless you add a SD card or some other form of extension memory, then an AVR won't do it either, though a fixed table in program memory will be more efficient than on a PIC.

The ATmega has 8 bit program memory, 8 bit RAM & EEPROM memory so you will use a 1:1 ratio. A potential problem you have with your idea is the robot route cannot be altered without re-programming the device as program memory is read only in execution. A better idea may be to add an SD memory card interface and store the route on this card and the arduino can read/write this information. To change the route you could just plug the SD card into the PC and write new/modified route data, put it back in the robot an try again.

I suspect you don't want either Pic or Arduino, but instead want an Arm based microprocessor or more like, a single board based computer. I would think about something like a Rasberry Pi which typically runs Linux and has 256MB or 512MB of memory, perhaps coupled with an Arduino to control the robot. Beagle bone, mbed, etc. are other boards that are meant for the person doing one off designs.

To highlight what Riva says, the PROGMEM in Arduino is for data only. It is memory located in the flash memory that holds the instructions, and is meant to allow you to have larger read only data tables (such as strings for output) without consuming the rather limited read/write data memory.

Also if you are storing it in progmem, there is no need for the 12/13 entry number bits, you can take the size of the entry and use that to traverse a block of data from the start pgm address.

//Read first byte of entry.
pgm_read_byte( startAddress + ( sizeof( entry ) * index ) );

charlieb000: It may have so many tasks that it may need an external memory chip or by using the chip to store it in its own flash

With that much data, and the implied need for trial and error and repeated changes to the data, I would have thought that providing a convenient way to input and display it would be an important consideration. You might be better off using an SD card (which gives you vastly more space than you will need, ignoring the encoding efficiency issue, and optimising your encoding for convenience. For example you could encode that set of values representing a single command as a single ascii CSV data record. If you go ahead with this, I suggest you pay attention to the need to back up and archive these sets of commands, and not just the mechanisms needed to enter and execute them. A text file on an SD card is obviously easy enough to manipulate away from the Arduino, and you can use multiple cards to swap command sets easily.