Hi Neil, hi Kees,
though named bitfields are kind of nice when it comes to code
readability, they behave very poorly when it comes to code size. This is
especially true for register maps, as these are typically volatile. For
this reason, we don't use them in RIOT and I strongly advice not to use
those.
As example I was able to save several 100 bytes of ROM when removing the
named bitfield use from the samr21s peripheral drivers.
Cheers,
Hauke
On 26.10.2016 21:24, Kees Bakker wrote:
On 26-10-16 16:52, Neil Jones wrote:
Hi,
What is RIOT's position on using named bitfields for register
definitions ? I know they are frown upon as there are no endian
guarantees in the C standard, personally I don't use them, but the PIC32
device files supplied by Microchip do include bitfield structures for
most registers so could make life easier ? (thankfully there are #define
for most register fields too, if the answer is not to use them).
I can't speak for RIOT, but personally I don't have a problem with them
when they are used for register definitions.
And I know that SAMD21 uses them too in Atmel's CMSIS include files.
In many cases it makes the code much nicer. That doesn't mean the
SAMD21 already uses them a lot. For example, we currently have code
like
dev(bus)->CTRLA.reg |= SERCOM_SPI_CTRLA_SWRST;
while ((dev(bus)->CTRLA.reg & SERCOM_SPI_CTRLA_SWRST) ||
(dev(bus)->SYNCBUSY.reg & SERCOM_SPI_SYNCBUSY_SWRST));
...
while (!(dev(bus)->INTFLAG.reg & SERCOM_SPI_INTFLAG_DRE)) {}
...
dev(bus)->CTRLA.reg &= ~(SERCOM_SPI_CTRLA_ENABLE);
which could use bitfields and be written like this
dev(bus)->CTRLA.bit.SWRST = 1;
while ((dev(bus)->CTRLA.bit.SWRST) ||
(dev(bus)->SYNCBUSY.bit.SWRST)) {}
...
while (!(dev(bus)->INTFLAG.bit.DRE)) {}
...
dev(bus)->CTRLA.bit.ENABLE = 0;
_______________________________________________
devel mailing list
[email protected]
https://lists.riot-os.org/mailman/listinfo/devel
