avr-libc-corelib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Frédéric Nadeau
Subject: Re: [Avr-libc-corelib] Mappings from pins to capabilities?
Date: Wed, 4 Aug 2010 03:33:13 -0400

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
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]