On 7/29/2020 7:41 AM, Gregory Nutt wrote:
What about platforms like AVR? That would not be a good decision for
AVR since it is a harvard machine and cannot access data in ROM
without special operations.
This is not a show stopper, at least not for the AVR. While a
table-driven solution is not optimal for AVR, it will support access
to constant data in ROM if the data has the storage class IOBJ as
defined in include/nuttx/compiler.h. I don't know if the compiler
will automatically generate the correct instruction to access the
table across the bus bridge; I am not an AVR expert. There is a up_
function may need to be used to access the ROM table???
AVR Memory: https://microchipdeveloper.com/8avr:memory
C Interface:
http://ww1.microchip.com/downloads/en/AppNotes/Atmel-2575-C-Functions-for-Reading-and-Writing-to-Flash-Memory_ApplicationNote_AVR106.pdf
Hmm.. I notice that compiler.h defines IOBJ as __flash but the above
document says: "The datatypes are actually used as __flashor
__farflashpointers (consequently 16 and 24 bit)." That should be
change to __farflash.
Much clearer information here:
https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html