[Top][All Lists]

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

Re: [avr-libc-dev] Update RFR devices header files

From: Joerg Wunsch
Subject: Re: [avr-libc-dev] Update RFR devices header files
Date: Mon, 4 Apr 2016 11:20:07 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

As Pitchumani Sivanupandi wrote:

> RFR devices (mega64/644/128/1284/256/2564rfr2) headers are included in
> the revision 2308.
> http://svn.savannah.nongnu.org/viewvc?view=rev&root=avr-libc&revision=2308
> It seems they are in struct-based format like xmega headers.

Nope, it's quite different.

If at all, you might compare them to the SAMDxx header files.

The Xmega header files have structs for each functional block,
but inside the structs, there are only plain bytes (or larger

The RFR header files (like its predecessor ATmega128RFA1) have
*bitfields* for the registers - optional, we didn't want to break
existing code that uses the normal register-as-a-byte approach.
(SAMDxx, introducing a completely new device, could start from
scratch, and offer a union for the entire register, consisting of a
bitfield plus a method to access the register as a whole.)

The biggest advantage of the bitfield approach is that you cannot
misplace bit assingments.  In classic AVR setups, nobody would warn
you here:

UCSR0A = _BV(U2X) | _BV(TXEN0); // error: TXEN0 belongs to UCSR0B

In the bitfield approach, this would give you an error:

UCSR0A_struct.txen0 = 1; // txen0 only exists in UCSR0B_struct

Note that these header files have been automatically generated from
the design databse (at Atmel Dresden), thus guaranteeing consistency
between the design and the header file (as well as the register
description in the datasheet which is also auto-generated that way).

> Atmel published
> headers for these RFR devices are updated.

I don't see any gain from reverting the header files.  After all,
Atmel just had to fix bugs in them that were never present in the
avr-libc (aka. Atmel Dresden) version ...

Also, I've seen some people (on avrfreaks) actually using the bitfield
registers in the past, so dropping support for it would break their

The original idea was to eventually enable these bitfields for all
AVRs, but this never materialized.
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

Never trust an operating system you don't have sources for. ;-)

reply via email to

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