Also in the same header file as PROGMEM is defined to nothing pgm_read_byte expands to:
#define pgm_read_byte(addr) (*(const unsigned char *)(addr))
Does PROGMEM work on this board?
Moderators: adafruit_support_bill, adafruit
Please be positive and constructive with your questions and comments.
- danhalbert
- Posts: 4650
- Joined: Tue Aug 08, 2017 12:37 pm
Re: Does PROGMEM work on this board?
The AVR chips are a so-called "Harvard" architecture, where the data memory and program memory are in different address spaces. There's a special machine instruction LPM (Load Program Memory) to load data from the flash memory to a register, and that's what pgm_read_byte() et al are doing.
The ARM architecture uses a uniform address space, where RAM and flash are in different sections of the same address space, so all this trickery is not necessary.
The ARM architecture uses a uniform address space, where RAM and flash are in different sections of the same address space, so all this trickery is not necessary.
- zencuke2
- Posts: 237
- Joined: Sun Feb 15, 2015 2:40 pm
Re: Does PROGMEM work on this board?
Thanks. I assumed that's what it was. I've used a couple over the years. BTW The flat or shared code/data model is usually called the von Neumann model though I've heard it called the Princeton model. I think von Neumann was at Princeton at the time the relevant paper was published. That was one of the few history of computer events that actually happened before I was born. ;-) At least it sometimes seems that way.
- zencuke2
- Posts: 237
- Joined: Sun Feb 15, 2015 2:40 pm
Re: Does PROGMEM work on this board?
Interesting side note. In early computer days (before my time) it was thought that a major benefit of the von Neumann architecture was that it allowed self modifying code. Imagine implementing the equivalent of a case statement or complex if/else by editing the address field of the final branch instruction. Subroutines calls on machines with no stack were implemented by writing the return address at the top of the subroutine so the subroutine knew where to go when it was done.
Turns out self modifying code is a very powerful technique, so powerful that it made debugging almost impossible. It is hard enough to debug code when it doesn't change as it runs. The technique is still used but mostly at the OS level for specialty techniques like loading a program from disk into memory and general task management. To an OS your program is data. The most useful special features were replaced by special hardware like flags for complex conditional branching and push/pop registers to implement stacks. A lot of the remaining useful techniques of self modifying code can be done with pointers in C. Also there are lot of benefits to leaving the code alone like recursion and shared libraries; so the technique has mostly died out.
However I once had a tee shirt which read "Real programmers write self modifying code."
Turns out self modifying code is a very powerful technique, so powerful that it made debugging almost impossible. It is hard enough to debug code when it doesn't change as it runs. The technique is still used but mostly at the OS level for specialty techniques like loading a program from disk into memory and general task management. To an OS your program is data. The most useful special features were replaced by special hardware like flags for complex conditional branching and push/pop registers to implement stacks. A lot of the remaining useful techniques of self modifying code can be done with pointers in C. Also there are lot of benefits to leaving the code alone like recursion and shared libraries; so the technique has mostly died out.
However I once had a tee shirt which read "Real programmers write self modifying code."
Please be positive and constructive with your questions and comments.