[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Making better use of virtual addresses

From: Pitchumani Sivanupandi
Subject: Re: [avr-gcc-list] Making better use of virtual addresses
Date: Thu, 24 Nov 2016 12:44:48 +0530
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

On Friday 18 November 2016 04:46 PM, Georg-Johann Lay wrote:
Some of the more recent avr devices support reading from flash by LD instructions. The flash memory can be accessed by a virtual address (VMA) which is offset by a specific value from the load address (LMA).

For example, on ATtiny40 (a reduced Tiny with only 16 GPRs) the offset is 0x4000, and on ATtiny817 (a recent Tiny) the offset is 0x8000.

tiny817 is not of AVR_TINY architecture, it's actually a xmega2 according to our classification.

The ATtiny40 doesn't even support LPM so that using the VMA RAM address is the only way to read data from flash.

Unfortunately, the linker description files don't reflect this feature, and .rodata is still located in RAM. The situation is treated as always by putting read-only data into .progmem. Since avr-gcc v7, the compiler adds an offset of 0x4000 to all symbol values, so that no special functions are needed to access progmem data.

A much better and simpler solution would be to remove .rodata from RAM and put it into flash by means of an appropriate linker description file avrtiny.x like so:

  .text :
  }  > text
  .rodata ADDR(.text) + SIZEOF (.text) + __RODATA_PM_OFFSET__ :
  }  AT> text
  .data :
     PROVIDE (__data_start = .) ;
    . = ALIGN(2);
     _edata = . ;
     PROVIDE (__data_end = .) ;
  }  > data AT> text

The pm offset could be hard coded or provided by the linker script, or even be provided by a command option like --def-sym. In my example, it's defined in the ld script:


All this is completely transparent to the C code and to the compiler: Just avoid the progmem stuff and write plain vanilla C!

Only the handling of -mabsdata, which is a new option in avr-gcc v7 to support LDS / STS on reduced Tiny, has to be more conservative and reject LDS / STS for objects in .rodata.
Ok. For devices with memory mapped flash, we can also think about simplifying progmem access, both with __flash and the progmem macros in avrlibc.

For "classical" devices like ATtiny817 (not yet supported) such restrictions to LDS / STS don't apply because they can address the full 16-bit range of (virtual) RAM addresses.

What's even better, on ATtiny817 the whole memory is linearised, and it also provides virtual addresses for EEPROM (0x1400), Flash (0x8000) and RAM (0x3e00, 0x3f00 for smaller devices like ATtiny417).

Are there plans to change the ld scripts to accommodate this address layout?

Not yet. We shall do for flash. But for other address spaces we have to check with programmers/ debuggers that uses the VMA to identify an ELF segment as EEPROM, FUSE etc.

Are there plans to support ATtiny416/417/816/816?

Yes. There are some (unrelated to 817) internal modifications to the mcu def file and spec generator. We'll clean them up and post the patches.

Attached is a delta against avrtiny.x which I used to play with ATtiny40.
It will work for AVR_TINY architecture, but non-tiny parts like the 817 also have memory mapped flash, so we'll have to go for a more general approach.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]