GPIO Pin Release and Pin Specific Interrupts

[André Marques]

Hello Sudarshan,

Às 18:53 de 19-10-2015, sudarshan.rajagopalan escreveu:
> Hey guys,
>
> I have few questions/comments on the GPIO APIs, maybe to André:
>
> 1.) Most of the APIs has a way to call the BSP specific functions: pin 
> input/output initialize, pin read/write, enable/disable interrupts 
> etc, but I couldn't find a way to call a BSP specific pin release (or 
> de-init). The rtems_gpio_release_pin() disables the interrupt for that 
> pin and updates the pin state global variable, but does not allows to 
> do a bsp specific pin de-initialize. While if I want to change the 
> mode of the pin (say from input to output), I can reinitialize the pin 
> and it works. But its important to bring back the state of the pin to 
> its default reset state, deactivating the pull resistors, if the pin 
> is to be released and not used.
>
> Was wondering why this wasn't added. What are your comments on this? 
> If this is OK I have a patch for this.
>


The pin release functions were only meant to release resources on the 
software side, such as interrupt handlers, and to signal the API that a 
pin may be re-purposed.

After the pin release from the API it can be "requested back" via the 
request functions with a different configuration, which may include its 
default reset state.

Note that to restore the pin to its default reset state the API would 
have to know what it was somehow, and that is BSP/platform dependent.
This may be accomplished by setting a table of rtems_gpio_pin_conf, one 
per pin, stating its default reset state, and then after the pin release 
you can reset the pin with the default configuration.

The release function does not do this automatically because in the event 
of a pin release to evolve to a new function the pin would have to be 
configured with two potentially different functions, one for the default 
state and only then to the desired function.

This way the developer is free to reset to the default state, evolve to 
a new state, or let it be. I do agree that "letting it be" may be 
dangerous, as to the API it is like it is not being used, but underneath 
in the hardware the pin is indeed programmed for something.

This also happens if a BSP does not initialize the pin states at the 
beginning (where every pin start as Not used, even though they default 
to a specific function at startup), but can be currently solved if a BSP 
so desires by requesting all pins with the default configurations.

In the end resetting to the default state requires every BSP to provide 
a list of default states for every pin, along with the currently 
required functions. Currently each BSP is free to provide or not a list 
of the default states, such that on an user application (or driver)  
those states can be called right after the pin release (request call 
after the release).

A BSP may also currently choose to take those default states and 
initialize the API pin states, as to more accurately represent the GPIO 
state in hardware.

On an API level, the reset could be controlled during the pin releasing 
with a flag, such that in the case of an evolution to a new function the 
reset step can be omitted.


> 2.) Second, the interrupts are registered based on ports (which it is 
> in most of the processors) and the pin that caused the interrupt is 
> found as a node in the chained list. But, unfortunately the processor 
> that we are using (STM32F4/F7) has pin based interrupts :(. The link 
> below tells in brief:
>
> http://stm32f4-discovery.com/2014/08/stm32f4-external-interrupts-tutorial/ 
>
>
> There are interrupt vectors defined for each pin in STM32F4/F7 but 
> RTEMS GPIO expects vector numbers for gpio banks using 
> rtems_gpio_bsp_get_vector(), which would not work for this processor. 
> I'm been trying to break my head to figure out a way to make the 
> interrupts work, without any modification to the GPIO APIs.
>
> One way would be to send the enumerated pin_number as the argument to 
> rtems_gpio_bsp_get_vector(), decode pin number ( pin = 
> PIN_NUMBER(pin_number) ) and return the vector number for this pin and 
> install the interrupt handler. But based on the whole interrupt 
> service architecture in generic_bank_isr(), this would not work out. 
> Everything is based on bank interrupts.
>
> Any possible solution for this?


If the vectors are on a pin basis you can define a bank to contain only 
one pin ( BSP_GPIO_PINS_PER_BANK = 1). Then the bank and pin number will 
be the same, and you can define  rtems_gpio_bsp_get_vector() on your BSP 
to retrieve the vector number through a simple array, where the bank 
number would be the index.

 From the link you posted it seems that there is a vector per line 
(which seems to also have a pin number), each line containing a number 
of pins, but only one pin per line can be used at a given time.

Another option would be to have a bank per line, and then on the BSP 
implementation of the API you can define a limit (in this case to 1) to 
the number of pins enabled on a given bank (this check would go on the 
definitions for the rtems_gpio_bsp_select_* functions on the BSP side). 
Then you would still have one bank per line (bank0 would be line0), so 
you can store the vector on a simple array, and retrieve as above.


>
> Thanks and Regards,
> Sudarshan Rajagopalan

--André Marques

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20151019/c44c8a4b/attachment-0002.html>