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 entities). 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 code. The original idea was to eventually enable these bitfields for all AVRs, but this never materialized. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
