boards/common/native: expose mock saul GPIO pins

[basilfx]

Contribution description

When periph_gpio_mock is included, expose two LEDs via saul_gpio for testing purposes. It is not enabled by default, so its use is limited. However, I do have a use-case that is only useful if there is something exposed via SAUL.

This does not work with periph_gpio_linux because the hard-coded pins are more dynamic for the native board.

Native defines macros for LED0 and LED1, and has the native_drivers module for providing some console feedback. This change completely ignores that, just like periph_gpio_mock already does.

Testing procedure

Compile using USEMODULE=periph_gpio_mock BOARD=native make -C examples/basic/default.

The run the example, and use the saul command:

RIOT native interrupts/signals initialized.
Native RTC initialized.
TZ not set, setting UTC
RIOT native64 board initialized.
RIOT native hardware initialization complete.

main(): This is RIOT! (Version: 2026.07-devel-121-ge4b21-feature/native_saul_gpio_mock)
Welcome to RIOT!

> saul
saul
ID      Class           Name
#0      ACT_SWITCH      LED 0 (mock)
#1      ACT_SWITCH      LED 1 (mock)

> saul write 0 1
saul write 0 1
Writing to device #0 - LED 0 (mock)
Data:                 1
data successfully written to device #0

> saul read 0
saul read 0
Reading from #0 (LED 0 (mock)|ACT_SWITCH)
Data:                 1

Issues/PRs references

None

Declaration of AI-Tools / LLMs usage:

None

[riot-ci]

Murdock results

✔️ PASSED

b76fa82 boards/common/native: expose mock saul GPIO pins

Success	Failures	Total	Runtime
11107	0	11108	15m:33s

Artifacts

• Documentation preview

[crasbe]

This does not work with periph_gpio_linux because the hard-coded pins are more dynamic for the native board.

Would it make sense to add a check/warning to a Makefile for that case?

---

The new Pseudomodule has to be added to the makefiles/pseudomodules.inc.mk file too, which would be a good place to add some documentation about it.

Also I wonder if it has to be added here as well?

RIOT/makefiles/features_modules.inc.mk

Lines 128 to 134 in fdb532a

	# always register a peripheral driver as a required feature when the corresponding
	# module is requested
	PERIPH_IGNORE_MODULES += periph_usbdev_clk periph_gpio_mock periph_gpio_linux periph_i2c_mock periph_spidev_linux
	ifneq (,$(filter periph_%,$(DEFAULT_MODULE)))
	FEATURES_REQUIRED += $(filter-out $(PERIPH_IGNORE_MODULES),$(filter periph_%,$(USEMODULE)))
	endif

[basilfx]

Would it make sense to add a check/warning to a Makefile for that case?

Not sure. It will work, but the pin mapping will be incorrect, which leads to segfaults (I noticed). This simply enables a feature if "the stars align".

The new Pseudomodule has to be added to the makefiles/pseudomodules.inc.mk file too, which would be a good place to add some documentation about it.

This is not a new pseudomodule, so then it is not necessary, right?

[crasbe]

Would it make sense to add a check/warning to a Makefile for that case?

Not sure. It will work, but the pin mapping will be incorrect, which leads to segfaults (I noticed). This simply enables a feature if "the stars align".

I meant something like "Warning: you're using periph_gpio_linux together with periph_gpio_mock, which can lead to unforseen side effects!" while compiling.

The new Pseudomodule has to be added to the makefiles/pseudomodules.inc.mk file too, which would be a good place to add some documentation about it.

This is not a new pseudomodule, so then it is not necessary, right?

You are right, I did not realize that this is already present.

[basilfx]

I meant something like "Warning: you're using periph_gpio_linux together with periph_gpio_mock, which can lead to unforseen side effects!" while compiling.

I'll check that. I believe there is a way to define conflicting features, and I presume it will not even compile, since both implement periph_gpio.