I was wondering recently if we could specify the initial state of the output with Saul.

I have some LEDs active low, then at init, they're on instead of off.

@vincent-d, yeah same here, on pba-d-01-kw2x the RGB LEDs are ON when cleared (or set to 0) and OFF when set. But I don't think that SAUL should care about that, it should rather go into the low-layer gpio driver - which does not support something like invert logic of certain GPIOs yet.

though I started this PR from with that in mind, I then found that (for instance for debugging) one might init and set certain GPIOs (eg. an LED) right at bootup and before SAUL is initialized, hence the GPIO state might be flawed -> thus clear output pins explicitly.

hence the GPIO state might be flawed -> thus clear output pins explicitly.

But if you set (to 1) a given pin in the board_init, it's still overwritten by saul which clear it in the auto_init phase. Back to my LED issue!

yes, but my point was that not all LEDs behave that way, most LED will be OFF when set to 0 and ON when set 1. With the PhyNode (board pba-d-01-kw2x) I have on counter example myself, where LEDs are ON when set to 0 and vice-versa.

Which means running the SAUL example on the pba-d-01-kw2x (with #7147 merged) the RGB LED is full on after auto init. My point was, that such inverted logic (for LED switching) should be handled at lower layers (i.e., periph_gpio) and not within SAUL.

OK, got your point.

But implementing a "reverse" logic in the gpio driver would mean to update every platform, where doing it in saul, would be only in one file...

In won't go against that PR anyway, so I you prefer we can continue the discussion somewhere else. Maybe @haukepetersen would like to have a word on that as well?

Yeah I also think, solving this weird LED logic on some boards would be a separate PR for sure!

But I also do think, that solving this in SAUL would fix it only for SAUL then. Fixing it in periph_gpio would solve the inverted/reversed logic for all layers above. I mean, I expect an LED to be ON when set to 1 and of OFF when set to 0 - and not the other way around. On the other hand, using the LED macros this is solved for the PhyNode, but SAUL doesn't use these macros but the gpio interface.

I do have a (strong) opinion here: dealing with inversion of GPIO levels does IMHO not belong into the peripheral GPIO driver. The peripheral drivers are designed to give unified access to MCU peripherals, with the least overhead possible, meaning no buffering, no unnecessary additional logic, and so on. So the GPIO simply just let's set/clear us GPIO pins, without any semantic meaning to the levels.

So I would certainly say, that the handling of things like low-active LEDs is something to be solved on a higher level, i.e. in SAUL. How about #7151?!

Towards a solution of the initialization state problem: I propose to solve this in two parts:

• add additional, explicit documentation to the GPIO interface, that the state of a pin is undefined after initialization as output, and that the initialization should not change a pins state if possible -> this is also helpful to prevent glitches when re-configuring pins for different uses
• add an additional configuration parameter to saul_gpio for configuring an (output) pins initial state -> see also saul/gpio: add handling of active-low signals + state initialization #7151

that the initialization should not change a pins state if possible -> this is also helpful to prevent glitches when re-configuring pins for different uses

would be good, 'cause that's not consistently implemented at the moment, for instance cc2538 clears gpio state during gpio_init.

@haukepetersen we still need to agree on a common or expected behavior by the driver, too. Currently, some drivers (eg CC2538) clear the GPIO during initialization, other don't.

However, I would (intuitively) expect that a GPIO configured as output would be cleared, to have consistent state - and not some left over from previous settings or undefined behavior depended on what the driver does. On the other hand, I don't think its necessary to make this configurable during gpio init, any application is free to set the gpio if needed explicitly.

However, I would (intuitively) expect that a GPIO configured as output would be cleared, to have consistent state

IMO the pin should be left alone, if possible. Some pull-up/pull-down on the other side of the pin might handle consistent state, and any explicit default might mess with that. I'd rather add clear documentation stating any expected default should be set explicitly.

edit should have read more before writing, this is what @haukepetersen wrote.

I'm in favor of @kaspar030 suggestion to improve documentation on that matter and clarify what to expect, what not, and how to work with that. So I'll close this one - do we agree on that?

However, how do we proceed with the low level driver implementations: as I already stated above gpio init is not handled consistently there?!

Slight drawback: this is about SAUL, IMHO SAUL should abstract from any driver/MCU specific GPIO handling or initialization, so that apps can rely on certain behavior no matter what platform they run on.

For the gpio state after init, how about #7173?

closing, as #7173 improved the doc and #7586 tackles this issue, too and provides a nice solutions with config options.