Well, the "Harvard" architecture (with separate address spaces) has advantages and disadvantages compared to the "von Neumann architecture" with a contiguous address space. One advantage in the case of the AVR is speed: although these processors are 8-bit processors, i.e. with byte-oriented data memory ( 8-bit wide ), the program memory is organised 16-bit wide. Therefore, almost all machine codes can be loaded in one cycle. Since they are RISC processors, only very few codes are 2 words long.
I meant the spec states that about string literals (const char*)
they may be stored in read-only storage (such as
.rodata)
so my point was that it can be in SRAM as it can be stored in some places the compiler knows about than can't be (easily) messed up with (such as flash memory)
I should rephrase:
Why is the distinction even made on ARM processors with their continuous address space?
My original question has been answered and I learnt a lot - thanks to all for your replies.
The valid/invalid combination matrix by Profile - johnwasser - Arduino Forum should be made a sticky note somewhere for reference.
I still wonder though what would be best practice to conserve RAM. Relying on the compiler(ARM) optimization OR force const strings into PROGMEM? But that shall be brought up another time.
(Unless someone wants to elaborate 
)
You cannot force that with PROGMEM on arm based arduinos. The arduino core for arm ( e.g. sam/samd ) knows about PROGMEM only to be source code compatible to AVR code. PROGMEM has no meaning on these processors. If you look into the core code you see:
#define PROGMEM
so PROGMEM will be simply ignored.
And also the .._P versions of many functions are mapped to their standard functions. E.g.
#define sprintf_P(s, f, ...) sprintf((s), (f), __VA_ARGS__)
#define snprintf_P(s, f, ...) snprintf((s), (f), __VA_ARGS__)
If you write code especially for arm based arduino bords, any use of PROGMEM and its associated functions does not make any sense.
Got it.
So I might still want to use PROGMEM for (RAM-efficient) portability to AVR processors.
Yes, but remember that you can't use the "%S" format on non-avr processors and you can't use the "%s" format on avr processors where the pointer points to PROGMEM. You will need separate format strings for the avr architecture. 
Too bad the avr compiler doesn't bother to keep track of which pointers point to PROGMEM and which point to RAM.
1 Like
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.