Atmel toolchain AVR compiler provides a transparent in-flash object support using __flash and __memx symbols. The former indicates to compiler that this is a flash-based object. The later used with pointer indicates that the referenced object may reside either in flash or in RAM. The compiler automatically makes 32-bit pointer with flag indicating whether referenced object is in flash or RAM and generates code to access either in run-time. Thus, any function that accepts __memx object can transparently work with RAM and flash objects.
For platforms with a Harvard architecture and a very small RAM like AVR this allows to move all constant strings used in trace messages to flash in the instruction address space, releasing resources for other things.
This change introduces IOBJ and IPTR type qualifiers. The 'I' indicates that the object may like in instruction space on a Harvard architecture machine.
For platforms that do not have __flash and __memx or similar symbols IOBJ and IPTR are empty, making the types equivalent to, for example, 'const char' and 'const char*'. For Atmel compiler these will become 'const __flash char' and 'const __memx char*'. All printf() functions and syslog() functions are changed so that the qualifier is used with the format parameter.
From: Dimitry Kloper <dikloper@cisco.com>
Atmel's AVR8 toolchain is similar to WinAVR, but at present moment
it has one important feature that WinAVR does not. The __flash and __memx
allow built in comiler support for transparent program memory pointers.
Functions that use such pointers will work both with RAM arrays and
flash memory arrays. The compiler generates an appropriate code automatically.
For systems with tiny memory like atmega, this is very important and
allows to move all static const strings into flash.
The main challenge is to change the context switch code to be aware of the
extra byte that is saved on stack during call and intterupt. This relates also
to the task startup and signal handling.
For AVR chips (Atmega2560) Program Counter register larger than 16 bits
EIND represents the most significant byte that is used for EICALL and EIJMP
instructions.
Setting of EIND is normally managed by compiler, but I have seen a situation
when for first 64K flash segment compiler didn't set EINT explicitly. Thus
setting EIND at system startup makes sure we are safe.
Disabling interrupts at the very beginning of system init does not
make sense after reset since interrupts are disabled anyway. But
it is very convenient for debugging purposes, in situations when the
system misbehaves and ocassionally jumps to zero.
