[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [avr-libc-dev] Re: Adding (some) Procyon AVRlib functionality toavr-
From: |
Weddington, Eric |
Subject: |
RE: [avr-libc-dev] Re: Adding (some) Procyon AVRlib functionality toavr-libc |
Date: |
Sun, 20 Sep 2009 16:48:36 -0600 |
> -----Original Message-----
> From: Jan Waclawek [mailto:address@hidden
> Sent: Sunday, September 20, 2009 2:03 PM
> To: Weddington, Eric
> Cc: David Brown; address@hidden
> Subject: Re: [avr-libc-dev] Re: Adding (some) Procyon AVRlib
> functionality toavr-libc
>
> > One possibility: When an API is being designed and is being
> considered for inclusion, there must be some work done to
> make it fit for the existing devices, even it's for the 100+
> devices that are currently in the AVR family. Yes, it's time
> consuming, but that would ensure that we've at least thought
> of ramifications for all devices, even if they haven't been
> fully tested out.
> >
>
>
> Could someone perhaps give a real example we could chew upon?
> What should an "API" or whatever look like?
> Isn't the issue with multiple different AVRs related more to
> the library routines themselves rather than to an API?
>
Well, actually a few of us have provided examples.
API means Application Programming Interface, which is nothing more than a set
of function calls: their names, what parameters they accept (and their types)
and what the function returns, and the meaning of what the function does.
For example, I sent to this list an example of set of routines that I and other
colleagues have written and tested. These routines are categorized into
different areas, such as an SPI driver. The API (list of functions) that are
provided to drive the SPI peripheral on the AVR should be designed in such a
way that they will be relevant to all AVR devices that have such an SPI
peripheral. The underlying implementation of these API functions could be
different, depending on any differences in the SPI peripheral on the various
AVR devices. However, the interface itself should be designed in a way that it
can be used across the entire range of exsiting AVR devices.
Various APIs should be developed for the various on-chip AVR peripherals.
- Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc, (continued)
- Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc, Joerg Wunsch, 2009/09/18
- RE: [avr-libc-dev] Adding (some) Procyon AVRlib functionalityto avr-libc, Weddington, Eric, 2009/09/18
- RE: [avr-libc-dev] Adding (some) Procyon AVRlib functionality toavr-libc, Weddington, Eric, 2009/09/18
- [avr-libc-dev] Re: Adding (some) Procyon AVRlib functionality toavr-libc, David Brown, 2009/09/20
- RE: [avr-libc-dev] Re: Adding (some) Procyon AVRlib functionalitytoavr-libc, Weddington, Eric, 2009/09/20
- Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc, Joerg Wunsch, 2009/09/18
- RE: [avr-libc-dev] Adding (some) Procyon AVRlib functionality toavr-libc, Weddington, Eric, 2009/09/18
- [avr-libc-dev] Re: Adding (some) Procyon AVRlib functionality to avr-libc, David Brown, 2009/09/20
- RE: [avr-libc-dev] Re: Adding (some) Procyon AVRlib functionality toavr-libc, Weddington, Eric, 2009/09/20
- Re: [avr-libc-dev] Re: Adding (some) Procyon AVRlib functionality toavr-libc, Jan Waclawek, 2009/09/20
- RE: [avr-libc-dev] Re: Adding (some) Procyon AVRlib functionality toavr-libc,
Weddington, Eric <=
- Re: [avr-libc-dev] Re: Adding (some) Procyon AVRlib functionality toavr-libc, Jan Waclawek, 2009/09/20
- RE: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc, John Myers, 2009/09/19
- RE: [avr-libc-dev] Adding (some) Procyon AVRlib functionality toavr-libc, Weddington, Eric, 2009/09/19
Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc - C++, David Brown, 2009/09/21