And if the macro versions are employed a few times then they would quickly grow larger than the table anyways. -- Lucas Vinicius Hartmann
Subscription software is ransomware disguised. Em qua., 29 de jul. de 2020 às 10:41, Gregory Nutt <spudan...@gmail.com> escreveu: > > > 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. > >
