RE: Generic GPIO framework

[Sergei Gavrikov <sergei.gavrikov@gmail.com>]

Hi

And may be to have even more generic I/O driver -- `parport`, then
the driver's interface would be

  cyg_io_{read,write}
  cyg_io_{set,get}_config

and to get the eCos parallel I/O devices like /dev/parX.

Generic layer:
   io/parport/*

Devices:
   devs/parport/*

My $0.02.

Sergei

On Sat, 29 May 2010, Christophe Coutand wrote:

> While I think it is possible to write generic drivers (for sensors, step
> motors, LCD etc.) using the platform GPIO, a common way of doing would
> make it easier to share drivers.
>
> Maybe the interface should be more compact:
>
> 1. cyg_gpio_set_config, which would include:
>
>    - An extended version of cyg_gpio_configure (Some devices are
> allowing more than setting IN/OUT buffer type. You might have the option
> to configure the output in open collector mode etc.. FPGA also allow to
> configure the driver type and strength, maybe some CPU have this
> option?).
>    - A way of enable / disabling interrupt for that IO
>
> 2. cyg_gpio_get_config, which would include:
>    - Allow to retrieve all settings from cyg_gpio_set_config
>    - cyg_gpio_has_irq
>    - cyg_gpio_to_irq
>
> cyg_gpio_is_valid could also be part of cyg_gpio_get_config
>
> 3. cyg_gpio_set
>
> 4. cyg_gpio_get
>
> Christophe
>
>
> -----Original Message-----
> From: ecos-devel-owner@ecos.sourceware.org
> [mailto:ecos-devel-owner@ecos.sourceware.org] On Behalf Of Simon
> Kallweit
> Sent: 28. mai 2010 16:49
> To: eCos developers
> Subject: Generic GPIO framework
>
> Hello
>
> I've been working on a generic GPIO framework for eCos. I wonder if
> there is interest in such a framework by the broad community. If so, I
> can take the effort to clean it up and make it ready for use by others.
>
> Let me quickly explain what the framework does in it's current form, any
>
> feature requests are highly appreciated :)
>
> We have a project where we need some simple digital IO (switches,
> sensors, LEDs etc.). As we mainly develop on the synth target, we wanted
>
> to be able to have a GPIO framework with drivers for both our hardware
> target (an STM32) and the synth target.
>
> The GPIO framework (CYGPKG_IO_GPIO) provides the basic infrastructure to
>
> support GPIO "devices". Using this architecture it would be feasible to
> also implement GPIO drivers for let's say SPI-based GPIO expanders.
>
> The user API is very simple:
>
> // GPIO direction
> typedef enum {
>     CYG_GPIO_INPUT,
>     CYG_GPIO_OUTPUT,
> } cyg_gpio_dir_t;
>
> // Checks if a virtual pin number is valid.
> cyg_bool cyg_gpio_is_valid(int pin);
>
> // Configures a pin with direction (input/output) and hardware specific
> flags.
> void cyg_gpio_configure(int pin, cyg_gpio_dir_t dir, int flags);
>
> // Writes to a pin.
> void cyg_gpio_set(int pin, int value);
>
> // Reads from a pin.
> int cyg_gpio_get(int pin);
>
> // Checks if a pin has a dedicated interrupt.
> cyg_bool cyg_gpio_has_irq(int pin);
>
> // Gets the interrupt vector of a pin.
> cyg_vector_t cyg_gpio_to_irq(int pin);
>
> Note that the pin number is 'virtual'. In the case of the STM32 GPIO
> driver, pins are mapped linearly. PA0 has pin number 0, PA15 has 15, PB0
>
> has 16 and so on. When having multiple GPIO devices, one would have to
> define regions for further pins. Do you think this is OK, or should
> there be some 'device id' to identify the actual GPIO device to use?
>
> Besides the simple API, there is an API to create 'observers'. An
> observer can be used to observe the input value of a GPIO pin. The user
> is notified through a callback if the input value changes. Observers can
>
> both by used in a polling mode or in interrupt mode, if the pin supports
>
> it. Also the observer implements debouncing. Observers can be used to
> handle simple switches for example.
>
> The observer API looks like this:
>
> // GPIO observer flags
> typedef enum {
>     CYG_GPIO_OBSERVER_DEBOUNCE  = (1<<0),
>     CYG_GPIO_OBSERVER_INTERRUPT = (1<<1),
> } cyg_gpio_observer_flags_t;
>
> // GPIO observer handler
> typedef void (*cyg_gpio_handler_t)(int pin, int value, void *user);
>
> // Creates an observer.
> void cyg_gpio_observer_create(struct cyg_gpio_observer *observer,
>                               int pin,
>                               cyg_gpio_observer_flags_t flags,
>                               cyg_gpio_handler_t handler,
>                               void *user);
> // Destroys an observer.
> void cyg_gpio_observer_destroy(struct cyg_gpio_observer *observer);
>
> // Enables an observer.
> void cyg_gpio_observer_enable(struct cyg_gpio_observer *observer);
>
> // Disables an observer.
> void cyg_gpio_observer_disable(struct cyg_gpio_observer *observer);
>
> GPIO drivers can be written relatively simple. One has to basically
> provide the following functions:
>
> // Driver functions
> struct cyg_gpio_device_funs {
>     void (*init)(struct cyg_gpio_device *dev);
>     cyg_bool (*is_valid)(struct cyg_gpio_device *dev, int pin);
>     void (*configure)(struct cyg_gpio_device *dev, int pin,
>                       cyg_gpio_dir_t dir, int flags);
>     void (*set)(struct cyg_gpio_device *dev, int pin, int value);
>     void (*get)(struct cyg_gpio_device *dev, int pin, int *value);
>     cyg_bool (*has_irq)(struct cyg_gpio_device *dev, int pin);
>     cyg_vector_t (*to_irq)(struct cyg_gpio_device *dev, int pin);
> };
>
> As I said, I already have implemented drivers for the STM32 and the
> synthetic target.
>
> The STM32 driver is very straight forward. It lets you define a list of
> valid pins for use by the application (optional) and a list of pins that
>
> should be mapped to interrupts. The driver automatically sets up the
> EXTI interrupt mappings for the configured pins.
>
> The synth driver is a bit more complex. It comes with integration into
> the ecosynth GUI. It lets the user dynamically specify how the GPIOs are
>
> displayed by editing the target.tdf configuration file. Currently the
> driver will display a simple list of 'items'. Items can be labels,
> generic pins and LEDs (both mono and bi-color). Generic pins have a few
> options to simulate switches etc.
>
> Now if anyone is interested to review my current implementation, I can
> prepare a tarball and put it up somewhere.
>
> There are a few open questions, but before bringing them up I just
> wanted to see if anyone is interested in this.
>
>
> Simon
>