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

[Henrik Maier]

Hi Thiago,

Maybe some smaller examples would help to understand the benefits and how
such a metalanguage can be applied to a problem?

Henrik

> -----Original Message-----
> From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-
> bounces at egnite.de] On Behalf Of Thiago A. Corrêa
> Sent: Saturday, 7 February 2009 10:57 PM
> To: Ethernut
> Subject: [En-Nut-Discussion] Using boost::preprocessor (preprocessor
> metaprogramming)
> 
> 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
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion