Re: [Avr-libc-corelib] Mappings from pins to capabilities?

[David A. Mellis]

Wow, that looks great!  It would be really useful to have something like that 
in avr-libc or avr-corelib.

On Aug 4, 2010, at 3:33 AM, Frédéric Nadeau wrote:

> Take a look at bug issue 25300 in avr-libc
> http://savannah.nongnu.org/bugs/?25300
> Proposed solution gives you something like this
> #define OC1D_N_DDR DDRB
> #define OC1D_N_PORT PORTB
> #define OC1D_N_PIN PINB
> #define OC1D_N_BIT 4
> 
> I have a cleaner version of this home, unfortunatly I'm working out of
> town for the week so I won't be able to update the patch before
> augusth 13th.
> 
> Frédéric Nadeau ing. jr
> On Tue, Aug 3, 2010 at 10:18 AM, David A. Mellis <address@hidden> wrote:
>> Hi,
>> 
>> I'm the lead software developer for Arduino, an ATmega8, 168, 328, and
>> 1280 based development platform.  One of the issues we struggle with
>> is mapping, across multiple cpu's, the port / bit of a pin to the
>> other capabilities of the pin (i.e. the labels in the pin
>> configurations section of the datasheet) - for example, in order to
>> write a function to both set a pin as an output and enable PWM on that
>> pin.  Right now, that requires maintaining a mapping between, say, PG5
>> and 0C0B.  This seems like it would be a great thing to include in the
>> corelib in some form.  The ideal would be a way to go in both
>> directions.  One possibility is to define this as a series of macros,
>> which could run at compile-time if the parameters are known.  But
>> really, any implementation would be fine.  I know there are a lot of
>> complications in doing this across the whole AVR line, but that's one
>> of the reasons that it seems to make sense in the corelib: it would be
>> a chance to resolve all the tricky issues once in a way that other
>> developers could take advantage of.  Certainly, it would be a big help
>> for Arduino.
>> 
>> What do you think?
>> 
>> David
>> 
>>