Go Down

Topic: does PROGMEM works succesful on CHIPKIT? (Read 3335 times) previous topic - next topic


hi. i know this is arduino forum but i think someone will know the answer.

becouse i need more SRAM i want to know if PROGMEM works on chipkit UNO32 that uses the same IDE.
and if yes? how much SRAM can i use from program memory?


The PIC32 has a single address space, and all you need to do to put your variables in flash instead of RAM is declare them "const."


wel using const it uses the flash memory? just so easy?


hi. i know this is arduino forum but i think someone will know the answer.

Doesn't the PIC forum help on these questions? Just curious. No wonder more people are using the Arduino.
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics


using const it uses the flash memory? just so easy?

Yep.  Consider:
Code: [Select]
char x[1000] = "this is a test";

void setup() {}
void loop() {Serial.print(x);}

As shown, you get:   text    data     bss     dec     hex filename
   5572    1028    4484   11084    2b4c /tmp/mpide/applet/sketch_mar01a.cpp.elf

Adding "const" moves things around so that you have:
const char x[1000] = "this is a test";
   text    data     bss     dec     hex filename
   6576      28    4484   11088    2b50 /tmp/mpide/applet/sketch_mar01a.cpp.elf

Since it's all in the same address space, you don't need special functions like pgm_read_byte(), either, though I think they are defined appropriately for compatibility.

Doesn't the PIC forum help on these questions?
Sure.  There's more impact by answering it here, though.


The other nice thing about chipKit (and presumably ARM CPUs as well) is that "string literals" will normally be put in flash instead of RAM.  So a statement like:
Code: [Select]
Serial.println("This kind of string is called a string literal");uses about 40 bytes of RAM on an AVR, but none on ChipKit...


sorry that i am talking about chipkit/uno32 on this forum (too). but the language is the same and there is much more support here

Code: [Select]
#define _6x8_gr_big_A { B00111111,B01000100,B01000100,B01000100,B00111111,B00000000 }
#define _6x8_gr_big_B { B01111111,B01001001,B01001001,B01001001,B00111110,B00000000 }

const byte index_small[2][6]={_6x8_gr_big_A,_6x8_gr_big_B};

on this code i am comfused with memory
it starts with define and there is an index array that holds all there,

where that bytes are stored? (dont forget this code is for chipkit uno32)


but the language is the same and there is much more support here

But the hardware is completely different! The number of people using this forum vs. that forum is completely irrelevant when you have core hardware/software questions.

Fords and Chevys both use spark plugs that Autolite makes. That does not mean that the Chevy dealer will answer questions about your Ford.
The art of getting good answers lies in asking good questions.


People can't answer questions that haven't been posted - so yes more interaction here because people are asking questions here.  Ask your question in the chipKIT forums and they will be answered.

Perhaps not as quickly but they will get responces.


ok this is the wrong forum. but if someone knows the answer he can answer.


You really should be asking this over on the chipkit/mpide forum:

Most AVR based Arduino users are not playing with pic32s and probably will not be familiar
with these types of issues.

The simple answer is there is no such thing as PROGMEM on CHIPKIT.

AVR processors using gcc have progmem and pic32 processors don't.
AVR processors are Harvard architecture and pic32 are not.
pic32 does not have to deal with all the complexity of multiple address spaces like the AVR.

On pic32 since there is no such thing as progmem as it simply is not needed,
so when you define things as "const" they land
in the code space (flash) with no RAM overhead and you can also access them directly vs having to use access functions.

That said, mpide has included macros to try to make things transparently
compatible with existing AVR code that had code to deal with progmem.

Go study the core files included with the pic32.
There are macros that try to deal with and hide the complexities of the AVR progmem
that are not necessary with the pic32.
Have a look at wiring.h in the pic32 part of mpide
in {mpide installdir}/hardware/pic32/cores/pic32/wiring.h

you will see that PROGMEM is defined to be nothing
and the corresponding pgm_read_xxx() are nothing more than direct access casts.

These are done to try to allow existing AVR gcc code that used progmem and its access routines
to function on the pic32 processors even though these types of declarations and access routines
are unnecessary on the pic32 processors.

--- bill

Go Up