Re: [ECOS] Re: Alpha release eCos NAND Flash, eCos YAFFS

[Nick Garnett <nickg at ecoscentric dot com>]

"GÃbor TÃrÃk" <tgabor84@gmail.com> writes:

> On Sun, Nov 30, 2008 at 11:53 AM, Andrew Lunn <andrew@lunn.ch> wrote:
> > On Fri, Nov 28, 2008 at 01:30:23AM +0100, Rutger Hofman wrote:
> >> Last time I visited a conference, everybody spoke about 'Release early,
> >> release often'.
> >>
> >> Here comes an alpha release of the eCos NAND Flash library and the eCos
> >> YAFFS wrapper library (r536 of our repository).
> >
> > Thanks for showing us the code at this early state. I just started
> > browsing through it.
> >
> > ... ...
> >
> >
> > The idea of generic GPIO functions needs to be discussed in the bigger
> > context. More likely these need to be HAL macros, CYG_HAL_GPIO_SET().
> > We want these to be fast as generally they are just two or three
> > assembly instructions. Doing a function call is too expensive in most
> > cases. You also need a generic way to address pins. The AT91 var hal
> > has some ideas here.
> >
> 
> I think also that generic GPIO woukld be a good idea. This would
> simplify writing generic drivers, etc.

I've looked at this several times and decided that it does not make
sense.  The problem with a generic API is that GPIO pins have a large
number of properties. Different manufacturers have wildy different
ways of configuring GPIO lines, from setting a overall mode to large
numbers of registers to control each property. 

Even generating a generic abstract API for something as straighforward
as the AT91 would result in a very large number of functions. Just
look at how complicated the AT91 code is already, when no attempt is
made at abstracting the concepts. This would also place yet another
large burden on the implementor of a new microcontroller port: to try
and map the GPIO abstractions onto the actual hardware.

I can think of very few device drivers that need to control GPIO pins
that would not be target specific. Any truly generic driver needs some
sort of customization to the target, such as register base addresses
and interrupt vector numbers; GPIO setup and control macros can be
provided from the same source.

There may be an argument for having generic macros to set the output
and read the input of a given GPIO pin. But such macros don't really
address the real issue of getting the GPIO pin into the correct mode
in the first place.

In general, I think the current approach of having microcontroller
specific macros for GPIO is the best we can do for now.


-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales:                        Reg No: 4422071


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss