From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14480 invoked by alias); 29 May 2010 09:17:52 -0000 Received: (qmail 14467 invoked by uid 22791); 29 May 2010 09:17:51 -0000 X-SWARE-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,BAYES_50,SARE_PROLOSTOCK_SYM3,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.stmi.com (HELO mail.stmi.com) (70.169.254.5) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 29 May 2010 09:17:46 +0000 X-Ninja-PIM: Scanned by Ninja X-Ninja-AttachmentFiltering: (no action) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Generic GPIO framework Date: Sat, 29 May 2010 09:17:00 -0000 Message-ID: In-Reply-To: <4BFFD7CC.4020204@intefo.ch> References: <4BFFD7CC.4020204@intefo.ch> From: "Christophe Coutand" To: "Simon Kallweit" , "eCos developers" X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2010-05/txt/msg00009.txt.bz2 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=20 there is interest in such a framework by the broad community. If so, I=20 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,=20 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=20 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=20 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=20 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=20 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=20 define regions for further pins. Do you think this is OK, or should=20 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=20 observer can be used to observe the input value of a GPIO pin. The user=20 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=20 handle simple switches for example. The observer API looks like this: // GPIO observer flags typedef enum { CYG_GPIO_OBSERVER_DEBOUNCE =3D (1<<0), CYG_GPIO_OBSERVER_INTERRUPT =3D (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=20 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=20 synthetic target. The STM32 driver is very straight forward. It lets you define a list of=20 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=20 EXTI interrupt mappings for the configured pins. The synth driver is a bit more complex. It comes with integration into=20 the ecosynth GUI. It lets the user dynamically specify how the GPIOs are displayed by editing the target.tdf configuration file. Currently the=20 driver will display a simple list of 'items'. Items can be labels,=20 generic pins and LEDs (both mono and bi-color). Generic pins have a few=20 options to simulate switches etc. Now if anyone is interested to review my current implementation, I can=20 prepare a tarball and put it up somewhere. There are a few open questions, but before bringing them up I just=20 wanted to see if anyone is interested in this. Simon