[En-Nut-Discussion] Using boost::preprocessor (preprocessor metaprogramming)

Thiago A. Corrêa thiago.correa at gmail.com
Sat Feb 7 13:56:57 CET 2009


Hi,

   I require some preprocessor metaprogramming to handle the AVR32
interrupt controler, and I wonder if ethernut developers would want
and be open to include boost::preprocessor into ethernut.

  It's quite handy when you need it, and it works with C compilers.
I'm already using it on a product we have that has many compile time
configuration options for a year or so (atmega128) and now I see that
I will need to generate interrupt tables for different AVR32 devices,
as it's vectors are per priority, not interrupt. To figure out what
caused the interrupt one must read registers to get group and signal.
The Application Framework uses it's own preprocessor macros to do that
metaprogramming, tailoring a table in compile time, just right for the
CPU specified by -mpart thanks to the toolchain defines.

  I am using Atmel's macros right now (less in source code size, but
uglier and less complete than boost) but I would like to rewrite the
table generation using boost::preprocessor. Both will generate the
same binary size. The main advantage of using boost is that other
archs or users could benefit.

  I would just add boost/preprocessor (all headers) to nut/include
then apps, drivers, etc could use it as it's documented in boost
website.

  What do you guys think? Are there other places in ethernut that could benefit?

  One obvious place might be drivers for repetitive devices, like
usarts (4 of them). Another one is the GPIO signals. In AVR32 we have
one gpio IRQ for each 8 pins, with packages going up to 14 gpio irqs
to be written as ih_gpiox.c.

  Harald, would like to hear from you if that's ok.

Thanks,
   Thiago A. Correa


More information about the En-Nut-Discussion mailing list