[ Just catching up ]
On 26/04/2015 9:26 pm, Ben Gras wrote:
> All,
>
> I think the API as it is (for digital GPIO's) is pretty close to
> generic. I like my suggestion (gpio_* in my previous mail) better as
> more generic. (More configuration is hidden from the application.)
>
> Joel I just read your presentation.
>
> I have come up with a minimal GPIO API based on the above (so
> ultimately based on the RPI API) that just covers the GPIO digital out
> case but allows expansion (with more defines and functions).
>
> https://devel.rtems.org/wiki/TBR/User/BenGras
>
> Is this an idea? Then we can merge this code implementing a reasonably
> generic API without having to flesh out the whole thing.
>
How do we define hardware specific details without bloating the API ?
For example on a zynq project I am working on I needed a GPIO interface
and I decided to use a struct to define the pin and the API takes
references to it. For example to control the write enable pin on a flash
device I have:
static const gpio_pin_def gpio_Flash_WD =
{
pin: 4,
output: true,
on: GPIO_FLASH_WD_EN,
outen: true,
volts: gpio_LVCMOS33,
pullup: true,
fast: false,
tristate: false
};
and then I have:
gpio_error ge = gpio_setup_pin(&gpio_Flash_WD);
if (ge != GPIO_NO_ERROR)
return FLASH_WRITE_LOCK_FAIL;
....
gpio_output(gpio_Flash_WD.pin, GPIO_FLASH_WD_EN);
....
I need to set the voltage on the pin on the Zynq but this is Zynq specific.
We need a way to let a user convey specific hardware details to the BSP
driver through the API plus we need a light weight API with minimal
internal translations. This approach also lets me define an array of
pins and a single set up call configures them.
So you could have:
typedef struct
{
int pin; /* The pin number. */
bool output; /* True for output, false for input. */
bool on; /* True default output is on */
bool outen; /* True for output enable on, false for off. */
bool pullup; /* True to enable the pull up. */
bool tristate; /* True to enable tri-state. */
void* platform; /* Opaque hardware specific set up details. */
} gpio_pin_def;
where the 'platform' references a struct agreed between the BSP (or
device layer) and the user code. For the generic cases this is not
needed and NULL. It also allows layering where a device set up phase of
user code sets the voltages and the generic code can play with the pin
at a generic level, eg direction etc.
What locking is being considered in this API ?
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
