drivers/gpio: improved doc for gpio_init()#7173
Conversation
haukepetersen
added
Area: doc
|
ACK for the change. Do we have to go through our gpio implementations that they actually adhere to this? Otherwise the extra doc does more harm than help. |
|
well as pointed out cc2538 does explicitly clear the gpio on init! Other do not, others do that too ... |
|
Yapp, to be clean, we IMHO need to adapt all effected GPIO drivers, but I think this effort is not too bad and easily doable. I will create a tracking issue and provide adaptions for a number of them this afternoon... |
|
See #7176 |
aabadie
added
the
State: waiting for other PR
drivers/include/periph/gpio.h
Outdated
| /** | ||
| * @brief Initialize the given pin as general purpose input or output | ||
| * | ||
| * When configured as output, the pin state is not touched. So if a specific |
There was a problem hiding this comment.
could (or should) be more strict stating
When configured as output, the pin state MUST NOT be changed by the MCU specific GPIO driver implementation!
haukepetersen
force-pushed
the
opt_gpiodoc
branch
from
12b96c6 to
3ec7563
Compare
|
@smlng: unfortunately, we can more strict on the pin state - in contrary, I even relaxed the documentation a bit more. The reason here is, that some CPUs do not keep the output state when re-configuring a pin from output to input and vice-versa, so the CPUs architecture is forcing us to touch the pin's state. I can't recall the specific CPUs right now, but some use the output data register to configure the pull resistor state in case the pin is in input mode... |
Let's make a list of them. |
|
Go ahead :-) And where to you want to put the list? |
haukepetersen
added
CI: ready for build
|
@smlng do you get my argument for being vague in the doc? @kaspar030: I think there are many aspects in the CPU abstraction/periph drivers, where the interfaces leave some space for implementation being a little vague on certain aspects (though vague here meaning that they state explicitly that certain behavior is preferred but not guaranteed). In my understanding it is common practice to look at the concrete implementation to find out the exact behavior of a platform (where the specific implementation hopefully contains some documentation on this). So creating list(s) for all these things seems way too much overhead to me... |
I think so ... |
|
doesn't sound too convinced :-) |
well, I personally would expect that when I configure a GPIO as output, that its initial state would be unset that is LOW. However, from empirical data (so to speak) I also know that some boards have an inverted logic for some of their GPIOs, so unset a GPIO actually means HIGH for them - so you got a point in saying that from the GPIO API perspective we cannot assume anything on the actual state of the GPIO without knowing the platform and the low level driver, etc ... So I'm fine with updated docu here and with your reasoning that this is low-level, hence simple as it gets API. However, for high-layer APIs such as SAUL it could be reasonable to have an explicit pin state set after init, which I proposed with #7148 |
|
Perfect, so all we need is an official ACK for this PR :-) |
|
nice, thanks! |
cpu/gpio: adapt GPIO implementations to #7173
4 participants
No description provided.