[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] ATMega 2560 + RAMPZ + 128Kplus and the real problem o
Senthil Kumar Selvaraj
Re: [avr-gcc-list] ATMega 2560 + RAMPZ + 128Kplus and the real problem on GCC
Sat, 6 Apr 2013 14:23:11 +0530
On Fri, Apr 05, 2013 at 03:59:02PM -0300, Carlos Delfino wrote:
> Hello everyone, I'm new here on the list and went in search of knowledge,
> learn from the questions and answers posted here.
> Reading the AVR datasheets, User Manuals GCC and AVR-LibC sources of the,
> still could not find the need to understand 100% without a doubt, the
> operation of the AVR family PC that uses more than 128KiB memory, all speak
> of some problem, but has not picked up where the problem is, I understand
> the participation of the register RAMPZ in addressing process of program
> memory above 128K, but I can not see what the difficulty is in relation to
> the GCC compiler.
The size of a pointer is fixed to 16 bits for the AVR target in GCC,
which means that addresses >= 128 KB (64 kilowords) won't fit into a
There are two scenarios - dealing with code beyond 128 KB, and dealing
with accessing data from flash beyond 128 KB.
Here's a brief document that describes what works and what doesn't
(http://saaadhu.github.io/appnote.html). Starting with gcc 4.7.x, code
beyond 128 KB works right away provided you link with relaxation turned
on and you don't explicitly set the EIND register from code. The only
exception is calls through function pointers that are initialized by a
cast from an integer constant.
> I'm keeping the FreeRTOS port for the Arduino environment, kept its
> original name and made a Fork since the original version is no longer being
> I studied and unite some suggestions posted by NET to allow FreeRTOS runs
> well (through DuinOS) in ATmega2560, but this specter is haunting my work
> and do not feel safe with the generated code.
> I inserted the necessary parameters in functions related to the TASK which
> are placed below 128K, but I've been told that I will have problems with
> other functions placed above this limit.
> Well, still could not reproduce the problem in my environment, indications
> of articles, experiments and suggestions already help a lot.
Provided you're using a recent version of the compiler, you won't see any
problems, as the compiler handles this properly.
Hope this helps.