The HAL function to read the current output status of a GPIO

[diverger]

Posted on September 13, 2017 at 08:24

If I configure one GPIO pin to output. Is there a function in HAL to read back the current output status of it?

[David SIORPAES]

Posted on September 13, 2017 at 18:20

You can use HAL_GPIO_ReadPin().

Even if the pin is set to output the IDR register will give you its current output status.

[hdmi87]

It is not true. If a pin is configured as open-drain output and its ODR bit value is 1, it may be pulled down externally. Then its IDR bit is 0, but ODR bit still is 1. So, HAL_GPIO_ReadPin will return 0 while output state is 1.

[waclawek.jan]

Well spotted, @hdmi87​ , even if this is a rather old thread, it's always good to correct a mistake.

It appears that there's no function in Cube/HAL to read GPIO_ODR, it appears that the pin-toggling function is the only one which mentions ODR at all.

OTOH, reading back ODR has a relatively rare usage. Cube/HAL, as inevitably every "library" does, implements only a subset of possible functionality, and of course that subset is based on the "most often used" functionality. I'd leave this to simply reading the register.

JW

[diverger]

Hi,

​

Thanks for your attention to such an old question from me.

​

Yes. Though it is wired, in a project I had to do this​. So, if I'm sure the output pin is not configured as OD, the method David proposed should work, right?

​

Best​ regards.

​

Diverger​

[remco2]

If you just want to read back what you wrote to the pin, you can check whether GPIOx->BSRR is GPIO_PIN_RESET or GPIO_PIN_SET.

[waclawek.jan]

Have you actually tried this?

GPIOx_BSRR are write-only and read-as-zero.

To find out the state of output register, read, well, the output register, i.e. GPIOx_ODR.

JW

[remco2]

I wouldn't answer a 4 year old question with a mind experiment so yes, I've tried it and it works.

[Lohi]

"it doesn't have any advantage over reading the ODR register."

Well, another two years... there are times when it's useful to know what was written to a pin, which might, indeed, be different than what is "visible" at the pin...this can be useful when you have something on a pin which can "return" a different state than what was written.

I used this on an IC to do confirmation of a function that was written, as part of self-test:

Write hi to external device

Wait xx μs for it to perform it's internal function

Read pin value - if it's now low, the device returns a "good" response

OTOH, you may want to know that you've set the pin high, even if it reads low, in a case where you might be driving something like a high-gain npn transistor, or a low Vgth FET with a pull-down resistor...edge cases, but...

[Lohi]

embedded systems can sometimes be helped by knowing the true "schematic" of the I/O pins, to allow more intimate knowledge of the behaviour in "funny" applications, or for more effective self-test operations.

Just a thought, based on 46 years of embedded systems and IC development (about 2 billion ICs served ;) )