Support for ATtiny416/417/816/817 ?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Support for ATtiny416/417/816/817 ?

Georg-Johann Lay-2
Hi, the devices in $subject are not yet supported by the tools, mainly
because of missing Binutils support.

Are there plans to add the needed emulation to Binutils?

Johann

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for ATtiny416/417/816/817 ?

Pitchumani Sivanupandi-2
On Wednesday 03 May 2017 08:01 PM, Georg-Johann Lay wrote:
> Hi, the devices in $subject are not yet supported by the tools, mainly
> because of missing Binutils support.
>
> Are there plans to add the needed emulation to Binutils?

These devices are belongs to existing avrxmega2 family.
device-specs files for these devices are present as part of Atmel ATtiny
Series pack (http://packs.download.atmel.com/)

Regards,
Pitchumani


_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for ATtiny416/417/816/817 ?

Georg-Johann Lay-2
On 05.05.2017 07:53, Pitchumani Sivanupandi wrote:
> On Wednesday 03 May 2017 08:01 PM, Georg-Johann Lay wrote:
>> Hi, the devices in $subject are not yet supported by the tools, mainly
>> because of missing Binutils support.
>>
>> Are there plans to add the needed emulation to Binutils?
>
> These devices are belongs to existing avrxmega2 family.

This emulation might be used but will result in suboptimal code.

For the mentioned devices, we want .rodata to be *not* a part of
data because just like avrtiny, what's definitely preferred is

 From avrtiny.x:

__RODATA_PM_OFFSET__ = DEFINED(__RODATA_PM_OFFSET__) ?
__RODATA_PM_OFFSET__ : 0x4000;

...

   .text :
   {
     ...
   }  > text

   .rodata  ADDR(.text) + SIZEOF (.text) + __RODATA_PM_OFFSET__ :
   {
     *(.rodata)
     *(.rodata*)
     *(.gnu.linkonce.r*)
   } AT> text

   .data :
   {
     PROVIDE (__data_start = .) ;
     *(.data)
     *(.data*)
     *(.gnu.linkonce.d*)
     . = ALIGN(2);
     _edata = . ;
     PROVIDE (__data_end = .) ;
   } > data AT> text


whereas avrxmega2 reads:


   .text :
   {
     ...
   }  > text

   .data :
   {
      PROVIDE (__data_start = .) ;
     *(.data)
     *(.data*)
     *(.rodata)  /* We need to include .rodata here if gcc is used */
     *(.rodata*) /* with -fdata-sections.  */
     *(.gnu.linkonce.d*)
     . = ALIGN(2);
     _edata = . ;
     PROVIDE (__data_end = .) ;
   } > data AT> text


This part of avrtiny.x is what we also want to use for ATtiny816 and
friends, and the canonical way to provide it is to supply a new
emulation for "avrxmega2 + .rodata in flash".


Or are you saying that avrxmega2 like ATXmega16A4 also come with a
linear memory?  I skimmed the data sheet but I found no reference
to that feature.  Maybe the data sheets are outdated or bogus?

The data sheet I found is from June 2013.

Johann


_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for ATtiny416/417/816/817 ?

Pitchumani Sivanupandi-2
On Friday 05 May 2017 02:42 PM, Georg-Johann Lay wrote:

> On 05.05.2017 07:53, Pitchumani Sivanupandi wrote:
>> On Wednesday 03 May 2017 08:01 PM, Georg-Johann Lay wrote:
>>> Hi, the devices in $subject are not yet supported by the tools, mainly
>>> because of missing Binutils support.
>>>
>>> Are there plans to add the needed emulation to Binutils?
>>
>> These devices are belongs to existing avrxmega2 family.
>
> This emulation might be used but will result in suboptimal code.
>
> For the mentioned devices, we want .rodata to be *not* a part of
> data because just like avrtiny, what's definitely preferred is
>
> From avrtiny.x:
>
> __RODATA_PM_OFFSET__ = DEFINED(__RODATA_PM_OFFSET__) ?
> __RODATA_PM_OFFSET__ : 0x4000;
>
> ...
>
>   .text :
>   {
>     ...
>   }  > text
>
>   .rodata  ADDR(.text) + SIZEOF (.text) + __RODATA_PM_OFFSET__ :
>   {
>     *(.rodata)
>     *(.rodata*)
>     *(.gnu.linkonce.r*)
>   } AT> text
>
>   .data :
>   {
>     PROVIDE (__data_start = .) ;
>     *(.data)
>     *(.data*)
>     *(.gnu.linkonce.d*)
>     . = ALIGN(2);
>     _edata = . ;
>     PROVIDE (__data_end = .) ;
>   } > data AT> text
>
>
> whereas avrxmega2 reads:
>
>
>   .text :
>   {
>     ...
>   }  > text
>
>   .data :
>   {
>      PROVIDE (__data_start = .) ;
>     *(.data)
>     *(.data*)
>     *(.rodata)  /* We need to include .rodata here if gcc is used */
>     *(.rodata*) /* with -fdata-sections.  */
>     *(.gnu.linkonce.d*)
>     . = ALIGN(2);
>     _edata = . ;
>     PROVIDE (__data_end = .) ;
>   } > data AT> text
>
>
> This part of avrtiny.x is what we also want to use for ATtiny816 and
> friends, and the canonical way to provide it is to supply a new
> emulation for "avrxmega2 + .rodata in flash".
>
>
> Or are you saying that avrxmega2 like ATXmega16A4 also come with a
> linear memory?  I skimmed the data sheet but I found no reference
> to that feature.  Maybe the data sheets are outdated or bogus?

No, linear memory is not common for all avrxmega2 devices.
IMHO, instead splitting ISA emulation because of linear memory,
we could try splitting/ parameterizing linker script to have .rodata
in flash if possible.

Regards,
Pitchumani

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for ATtiny416/417/816/817 ?

Georg-Johann Lay-2
On 05.05.2017 12:07, Pitchumani Sivanupandi wrote:

> On Friday 05 May 2017 02:42 PM, Georg-Johann Lay wrote:
>> On 05.05.2017 07:53, Pitchumani Sivanupandi wrote:
>>> On Wednesday 03 May 2017 08:01 PM, Georg-Johann Lay wrote:
>>>> Hi, the devices in $subject are not yet supported by the tools, mainly
>>>> because of missing Binutils support.
>>>>
>>>> Are there plans to add the needed emulation to Binutils?
>>>
>>> These devices are belongs to existing avrxmega2 family.
>>
>> This emulation might be used but will result in suboptimal code.
>>
>> For the mentioned devices, we want .rodata to be *not* a part of
>> data because just like avrtiny, what's definitely preferred is
>>
>> From avrtiny.x:
>>
>> __RODATA_PM_OFFSET__ = DEFINED(__RODATA_PM_OFFSET__) ?
>> __RODATA_PM_OFFSET__ : 0x4000;
>>
>> ...
>>
>>   .text :
>>   {
>>     ...
>>   }  > text
>>
>>   .rodata  ADDR(.text) + SIZEOF (.text) + __RODATA_PM_OFFSET__ :
>>   {
>>     *(.rodata)
>>     *(.rodata*)
>>     *(.gnu.linkonce.r*)
>>   } AT> text
>>
>>   .data :
>>   {
>>     PROVIDE (__data_start = .) ;
>>     *(.data)
>>     *(.data*)
>>     *(.gnu.linkonce.d*)
>>     . = ALIGN(2);
>>     _edata = . ;
>>     PROVIDE (__data_end = .) ;
>>   } > data AT> text
>>
>>
>> whereas avrxmega2 reads:
>>
>>
>>   .text :
>>   {
>>     ...
>>   }  > text
>>
>>   .data :
>>   {
>>      PROVIDE (__data_start = .) ;
>>     *(.data)
>>     *(.data*)
>>     *(.rodata)  /* We need to include .rodata here if gcc is used */
>>     *(.rodata*) /* with -fdata-sections.  */
>>     *(.gnu.linkonce.d*)
>>     . = ALIGN(2);
>>     _edata = . ;
>>     PROVIDE (__data_end = .) ;
>>   } > data AT> text
>>
>>
>> This part of avrtiny.x is what we also want to use for ATtiny816 and
>> friends, and the canonical way to provide it is to supply a new
>> emulation for "avrxmega2 + .rodata in flash".
>>
>>
>> Or are you saying that avrxmega2 like ATXmega16A4 also come with a
>> linear memory?  I skimmed the data sheet but I found no reference
>> to that feature.  Maybe the data sheets are outdated or bogus?
>
> No, linear memory is not common for all avrxmega2 devices.
> IMHO, instead splitting ISA emulation because of linear memory,
> we could try splitting/ parameterizing linker script to have .rodata
> in flash if possible.

You have some proposal of how such a linker description file would
look like?  As far as I know there is no support for conditional
portions of scripts, just DEFINED, which is not powerful enough
to express what is needed.

Moreover the compiler might start generating different code, for
example we could identify __flash address space with generic address
space.  The advantage is that generic space allow more instructions.


Just consider

extern const char __flash data[];

char get_data (int i)
{
     return data[i+1] + data[i+3];
}

this could use LDD Ra,Z+1 and LDD Rb,Z+3.


Moreover the code will be different w.r.t. referencing __do_copy_data,
hence we start generating different code which is a strong indication
that we need a new multilib variant anyway.


Johann


> Regards,
> Pitchumani
>


_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for ATtiny416/417/816/817 ?

Pitchumani Sivanupandi-2
On Friday 05 May 2017 06:02 PM, Georg-Johann Lay wrote:

> On 05.05.2017 12:07, Pitchumani Sivanupandi wrote:
>> On Friday 05 May 2017 02:42 PM, Georg-Johann Lay wrote:
>>> On 05.05.2017 07:53, Pitchumani Sivanupandi wrote:
>>>> On Wednesday 03 May 2017 08:01 PM, Georg-Johann Lay wrote:
>>>>> Hi, the devices in $subject are not yet supported by the tools,
>>>>> mainly
>>>>> because of missing Binutils support.
>>>>>
>>>>> Are there plans to add the needed emulation to Binutils?
>>>>
>>>> These devices are belongs to existing avrxmega2 family.
>>>
>>> This emulation might be used but will result in suboptimal code.
>>>
>>> For the mentioned devices, we want .rodata to be *not* a part of
>>> data because just like avrtiny, what's definitely preferred is
>>>
>>> From avrtiny.x:
>>>
>>> __RODATA_PM_OFFSET__ = DEFINED(__RODATA_PM_OFFSET__) ?
>>> __RODATA_PM_OFFSET__ : 0x4000;
>>>
>>> ...
>>>
>>>   .text :
>>>   {
>>>     ...
>>>   }  > text
>>>
>>>   .rodata  ADDR(.text) + SIZEOF (.text) + __RODATA_PM_OFFSET__ :
>>>   {
>>>     *(.rodata)
>>>     *(.rodata*)
>>>     *(.gnu.linkonce.r*)
>>>   } AT> text
>>>
>>>   .data :
>>>   {
>>>     PROVIDE (__data_start = .) ;
>>>     *(.data)
>>>     *(.data*)
>>>     *(.gnu.linkonce.d*)
>>>     . = ALIGN(2);
>>>     _edata = . ;
>>>     PROVIDE (__data_end = .) ;
>>>   } > data AT> text
>>>
>>>
>>> whereas avrxmega2 reads:
>>>
>>>
>>>   .text :
>>>   {
>>>     ...
>>>   }  > text
>>>
>>>   .data :
>>>   {
>>>      PROVIDE (__data_start = .) ;
>>>     *(.data)
>>>     *(.data*)
>>>     *(.rodata)  /* We need to include .rodata here if gcc is used */
>>>     *(.rodata*) /* with -fdata-sections.  */
>>>     *(.gnu.linkonce.d*)
>>>     . = ALIGN(2);
>>>     _edata = . ;
>>>     PROVIDE (__data_end = .) ;
>>>   } > data AT> text
>>>
>>>
>>> This part of avrtiny.x is what we also want to use for ATtiny816 and
>>> friends, and the canonical way to provide it is to supply a new
>>> emulation for "avrxmega2 + .rodata in flash".
>>>
>>>
>>> Or are you saying that avrxmega2 like ATXmega16A4 also come with a
>>> linear memory?  I skimmed the data sheet but I found no reference
>>> to that feature.  Maybe the data sheets are outdated or bogus?
>>
>> No, linear memory is not common for all avrxmega2 devices.
>> IMHO, instead splitting ISA emulation because of linear memory,
>> we could try splitting/ parameterizing linker script to have .rodata
>> in flash if possible.
>
> You have some proposal of how such a linker description file would
> look like?  As far as I know there is no support for conditional
> portions of scripts, just DEFINED, which is not powerful enough
> to express what is needed.
>
> Moreover the compiler might start generating different code, for
> example we could identify __flash address space with generic address
> space.  The advantage is that generic space allow more instructions.
>
>
> Just consider
>
> extern const char __flash data[];
>
> char get_data (int i)
> {
>     return data[i+1] + data[i+3];
> }
>
> this could use LDD Ra,Z+1 and LDD Rb,Z+3.
>
>
> Moreover the code will be different w.r.t. referencing __do_copy_data,
> hence we start generating different code which is a strong indication
> that we need a new multilib variant anyway.
>
Don't have any idea to implement conditional in linker script yet.
But thinking of different solution than splitting emulation as number of
emulations grow if new such device comes from other emulations.

How about having rodata in flash based on flag/ feature (avr-mcus.def
and specs file)?
E.g.
   Compiler puts rodata in section .flash.rodata if device has unified
memory map
   else puts in .ram.rodata. Linker script aggregates the .flash.rodata
to mapped region
   similar to the change you made in avrtiny.sc.

Analyzing if it is possible to implement.

Regards,
Pitchumani


_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for ATtiny416/417/816/817 ?

Georg-Johann Lay-2
Pitchumani Sivanupandi schrieb:

> On Friday 05 May 2017 06:02 PM, Georg-Johann Lay wrote:
>> On 05.05.2017 12:07, Pitchumani Sivanupandi wrote:
>>> On Friday 05 May 2017 02:42 PM, Georg-Johann Lay wrote:
>>>> On 05.05.2017 07:53, Pitchumani Sivanupandi wrote:
>>>>> On Wednesday 03 May 2017 08:01 PM, Georg-Johann Lay wrote:
>>>>>> Hi, the devices in $subject are not yet supported by the tools,
>>>>>> mainly
>>>>>> because of missing Binutils support.
>>>>>>
>>>>>> Are there plans to add the needed emulation to Binutils?
>>>>>
>>>>> These devices are belongs to existing avrxmega2 family.
>>>>
>>>> This emulation might be used but will result in suboptimal code.
>>>>
>>>> For the mentioned devices, we want .rodata to be *not* a part of
>>>> data because just like avrtiny, what's definitely preferred is
>>>>
>>>> From avrtiny.x:
>>>>
>>>> __RODATA_PM_OFFSET__ = DEFINED(__RODATA_PM_OFFSET__) ?
>>>> __RODATA_PM_OFFSET__ : 0x4000;
>>>>
>>>> ...
>>>>
>>>>   .text :
>>>>   {
>>>>     ...
>>>>   }  > text
>>>>
>>>>   .rodata  ADDR(.text) + SIZEOF (.text) + __RODATA_PM_OFFSET__ :
>>>>   {
>>>>     *(.rodata)
>>>>     *(.rodata*)
>>>>     *(.gnu.linkonce.r*)
>>>>   } AT> text
>>>>
>>>>   .data :
>>>>   {
>>>>     PROVIDE (__data_start = .) ;
>>>>     *(.data)
>>>>     *(.data*)
>>>>     *(.gnu.linkonce.d*)
>>>>     . = ALIGN(2);
>>>>     _edata = . ;
>>>>     PROVIDE (__data_end = .) ;
>>>>   } > data AT> text
>>>>
>>>>
>>>> whereas avrxmega2 reads:
>>>>
>>>>
>>>>   .text :
>>>>   {
>>>>     ...
>>>>   }  > text
>>>>
>>>>   .data :
>>>>   {
>>>>      PROVIDE (__data_start = .) ;
>>>>     *(.data)
>>>>     *(.data*)
>>>>     *(.rodata)  /* We need to include .rodata here if gcc is used */
>>>>     *(.rodata*) /* with -fdata-sections.  */
>>>>     *(.gnu.linkonce.d*)
>>>>     . = ALIGN(2);
>>>>     _edata = . ;
>>>>     PROVIDE (__data_end = .) ;
>>>>   } > data AT> text
>>>>
>>>>
>>>> This part of avrtiny.x is what we also want to use for ATtiny816 and
>>>> friends, and the canonical way to provide it is to supply a new
>>>> emulation for "avrxmega2 + .rodata in flash".
>>>>
>>>>
>>>> Or are you saying that avrxmega2 like ATXmega16A4 also come with a
>>>> linear memory?  I skimmed the data sheet but I found no reference
>>>> to that feature.  Maybe the data sheets are outdated or bogus?
>>>
>>> No, linear memory is not common for all avrxmega2 devices.
>>> IMHO, instead splitting ISA emulation because of linear memory,
>>> we could try splitting/ parameterizing linker script to have .rodata
>>> in flash if possible.
>>
>> You have some proposal of how such a linker description file would
>> look like?  As far as I know there is no support for conditional
>> portions of scripts, just DEFINED, which is not powerful enough
>> to express what is needed.
>>
>> Moreover the compiler might start generating different code, for
>> example we could identify __flash address space with generic address
>> space.  The advantage is that generic space allow more instructions.
>>
>>
>> Just consider
>>
>> extern const char __flash data[];
>>
>> char get_data (int i)
>> {
>>     return data[i+1] + data[i+3];
>> }
>>
>> this could use LDD Ra,Z+1 and LDD Rb,Z+3.
>>
>>
>> Moreover the code will be different w.r.t. referencing __do_copy_data,
>> hence we start generating different code which is a strong indication
>> that we need a new multilib variant anyway.
>>
> Don't have any idea to implement conditional in linker script yet.
> But thinking of different solution than splitting emulation as number of
> emulations grow if new such device comes from other emulations.
>
> How about having rodata in flash based on flag/ feature (avr-mcus.def
> and specs file)?
> E.g.
>   Compiler puts rodata in section .flash.rodata if device has unified
>   memory map
>   else puts in .ram.rodata. Linker script aggregates the .flash.rodata

Then the new option must be a multilib option, hence we need a new
multilib version anyways.  It's just much clearer if we add yet another
-mmcu= as multilib option, for example -mmcu=avrxmega3.  There are
currently no devices in that multilib set and Binutils already features
avrxmega3.

And as I already mentioned, we'd like to adjust more of the code
generation then where we put .rodata.

Johann

>   to mapped region
>   similar to the change you made in avrtiny.sc.
>
> Analyzing if it is possible to implement.
>
> Regards,
> Pitchumani

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Loading...