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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
