<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello Sudarshan,<br>
<br>
<div class="moz-cite-prefix">Às 18:53 de 19-10-2015,
sudarshan.rajagopalan escreveu:<br>
</div>
<blockquote cite="mid:aa0c27372112c82e89dd8fc0f99a8534@vecna.com"
type="cite">Hey guys, <br>
<br>
I have few questions/comments on the GPIO APIs, maybe to André: <br>
<br>
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. <br>
<br>
Was wondering why this wasn't added. What are your comments on
this? If this is OK I have a patch for this. <br>
<br>
</blockquote>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
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. <br>
This may be accomplished by setting a table of
<meta http-equiv="content-type" content="text/html; charset=utf-8">
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.<br>
<br>
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. <br>
<br>
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. <br>
<br>
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.<br>
<br>
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). <br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:aa0c27372112c82e89dd8fc0f99a8534@vecna.com"
type="cite">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: <br>
<br>
<a class="moz-txt-link-freetext"
href="http://stm32f4-discovery.com/2014/08/stm32f4-external-interrupts-tutorial/">http://stm32f4-discovery.com/2014/08/stm32f4-external-interrupts-tutorial/</a>
<br>
<br>
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. <br>
<br>
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. <br>
<br>
Any possible solution for this? <br>
</blockquote>
<br>
<br>
If the vectors are on a pin basis you can define a bank to contain
only one pin (
<meta http-equiv="content-type" content="text/html; charset=utf-8">
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.<br>
<br>
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.<br>
<br>
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
<meta http-equiv="content-type" content="text/html; charset=utf-8">
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.<br>
<br>
<br>
<blockquote cite="mid:aa0c27372112c82e89dd8fc0f99a8534@vecna.com"
type="cite"> <br>
Thanks and Regards, <br>
Sudarshan Rajagopalan <br>
</blockquote>
<br>
--André Marques<br>
<br>
</body>
</html>