11.07.2015 Views

Imagecraft c compiler and development environment for the atmel avr

Imagecraft c compiler and development environment for the atmel avr

Imagecraft c compiler and development environment for the atmel avr

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

ICCV8 <strong>for</strong> AVR – C Compiler <strong>for</strong> Atmel AVRSince changing RAMPZ affects data SRAM access via <strong>the</strong> Z pointer registers, if youneed to modify RAMPZ, <strong>the</strong>n you should save <strong>the</strong> previous value <strong>and</strong> restore it whenyou are done. We provide a set of library functions <strong>for</strong> accessing extended flashlocations that preserves <strong>the</strong> value of RAMPZ; see Greater Than 64K AccessFunctions <strong>for</strong> details.With <strong>the</strong> o<strong>the</strong>r RAMP registers, you can just safely use a register <strong>and</strong> set it to zeroafterward. This ensures that RAMP registers have <strong>the</strong> default values except in <strong>the</strong>cases where you need to modify <strong>the</strong>m.Checking <strong>the</strong> AddressesTo check <strong>the</strong> address of a data or constant data, use View->”Map File” <strong>and</strong> search <strong>for</strong><strong>the</strong> symbol’s name. The addresses are in hexadecimal, so any address greater than64K bytes would have more than four hexadecimal digits.Using Library FunctionsWe provide a set of library functions to access flash <strong>and</strong> SRAM beyond <strong>the</strong> 64K byteboundary <strong>and</strong> preserve <strong>the</strong> values of any RAMP registers <strong>the</strong>y use. See Greater Than64K Access Functions. While using library functions is less straight<strong>for</strong>ward than if <strong>the</strong><strong>compiler</strong> directly supports mixed word <strong>and</strong> long addresses, in terms of code efficiency,<strong>the</strong>re should not be any meaningful differences. (Never<strong>the</strong>less, we are investigating<strong>the</strong> feasibility of supporting mixed-size addresses, <strong>and</strong> will support <strong>the</strong> feature in alater update if possible.)Managing Constant DataThe <strong>compiler</strong> puts constant data (e.g. initialized global data that is qualified with <strong>the</strong>__flash keyword) in <strong>the</strong> .lit area, <strong>and</strong> <strong>the</strong> linker is set up to allocate space <strong>for</strong> all<strong>the</strong> literal areas be<strong>for</strong>e <strong>the</strong> code area. There<strong>for</strong>e, in most cases, unless you have a lotof constant data, it should all fit in <strong>the</strong> lower 64K byte flash memory space. In <strong>the</strong> casethat you do have more than 64K of constant data, <strong>the</strong> simplest approach is to identifysome data that you want to allocate to <strong>the</strong> upper 64K bytes, <strong>and</strong> <strong>the</strong>n allocate it to itsown area:#pragma lit:upper64K_lit__flash int atable[] = { ....#pragma lit:litIn <strong>the</strong> Project->Options->Target, add-bupper64K_lit:0x?????128

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!