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

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

Re: [Avr-libc-corelib] Style guidelines up! Let's get coding...


From: Frédéric Nadeau
Subject: Re: [Avr-libc-corelib] Style guidelines up! Let's get coding...
Date: Sun, 13 Dec 2009 16:40:57 -0500

Hi there,

I just posted a patch #7024. I think you could use it in SPI init.
Since not all device as SPI port on same location, this could be use
to set directions:

DDR_MOSI |= 1<<MOSI_IDX
and so on.

 As for a comment on the API, I think it would be nice to have the
possibility to initiallize the SPI in the 3 following mode:
Master only - Leaving the SS pin as a general output
Master and Slave - Using the SS pin as input(whit possible pull-up
enabled) for slave selection
Slave - Well, you know.

Whenever I make a project where the AVR is the master with only one
SPI slave, I tend to use the SS pin as a mean to select the SPI
device.Low count pin issue.

I'm currently working on a API for the CAN controller, if that interrest anyone.

On Tue, Dec 8, 2009 at 4:44 AM, Ruddick Lawrence <address@hidden> wrote:
> Hey everyone,
>
> I just put up the avr-corelib webpage
> (http://www.nongnu.org/avr-libc/avr-corelib/), which has the style
> guidelines we all hashed out a few months ago. It's pretty refined, except
> for how error messages work, but I think we'll have a better idea of that
> once we actually code a few modules, which bring us to....
>
> Our first modules! I think we should start with two modules so that it gives
> us an idea of the differing challenges and requirements that different
> functionality will require. We've already started talking a little about
> SPI, so let's make that one of the modules. Given that everyone has a lot of
> ideas, but little time, I would like to propose that the second module be
> anything (fairly simple) that someone is passionate about and would be
> willing to lead development on. It can range from something as simple as a
> ring buffer to more complex like an A/D module. If possible, I'd like to get
> some more people involved in this because I believe it will create a better
> library (so tell your friends!).
>
> A good jumping off point for the SPI library is Ron Kreymbourg's thread
> about an SPI implementation from this list
> (http://lists.gnu.org/archive/html/avr-libc-corelib/2009-09/msg00022.html).
> It's late now, but I'll work on getting out an API that we more-or-less
> agree on in the next few days.
>
> Happy coding!
> Ruddick
>



-- 
Frédéric Nadeau ing. jr




reply via email to

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