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.