examples/leds_shell: add example for interactive LEDs/GPIO control

[krzysztof-cabaj]

Contribution description

Rationale: When I remember my first steps as RIOT newbie, I would like as soon as possible flash the program and
show that it works and could control something, for example LED. However, for RIOT newbie this is not so easy. Of course there is examples/blink - but it works automatically. Manual control is something, in my humble opinion, missing.

This simple program allows easy control of internal LEDs via RIOT CLI. Additionally, it allows initialization of any GPIO port in output mode and manually set HIGH/LOW state.

From the programming learning perspective, analysis and experiments with this program could teach:

• RIOT CLI,
• Adding own functions,
• Basic GPIO.

Any comments are welcome.

Testing procedure

Flash examples/LEDs and check if number of internal LEDs is properly detected.

I tested it with boards from 1 to 4 LEDs, respectively: nucleo-l496rg, stm32l47g-disco/native', 'nucleo-f207zg and stm32f469i-disco.

Read README.md and check if everything is clear.

Issues/PRs references

PR #20637

[mguetschow]

Nice idea, just had a brief look at it for now.

Although this is somehow opposed to your intended use-case, aren't there some default shell commands already for this kind of GPIO/LED control?

[riot-ci]

Murdock results

✔️ PASSED

9959e62 examples/leds_shell: code refactoring-one led and gpio commands

Success	Failures	Total	Runtime
18	0	19	01m:21s

Artifacts

• Documentation preview

[dylad]

Maybe we can come up with a better name ? I find it a bit disturbing to have a tests/leds and examples/LEDs.

[krzysztof-cabaj]

Maybe we can come up with a better name ? I find it a bit disturbing to have a tests/leds and examples/LEDs.

What do you think about examples/leds_cli or examples/cli_leds?

[krzysztof-cabaj]

Although this is somehow opposed to your intended use-case, aren't there some default shell commands already for this kind of GPIO/LED control?

During my few years with RIOT I did not find any such commands. From similar programs, I only knows examples/blinky and mentioned by @dylad tests/leds but they lacks interactivity.

[krzysztof-cabaj]

As @dylad suggested I change the name of application to leds_shell - I hope that current name will be clear for everybody.

The code is refactored using inline functions added by @mguetschow in the PR #20783.
The code is know simpler and looks better.

[mguetschow]

Thanks for adapting your code, looks much cleaner now! I've got comments mostly on the Makefile and README below.

[krzysztof-cabaj]

@mguetschow, @dylad thanks for detailed review.

I hope all issues are now resolved.

[mguetschow]

LGTM now, thanks again!

[krzysztof-cabaj]

@mguetschow thanks for supporting during this PR.

Can we add PR to the merge queue?

[dylad]

One last nitpick on my side, feel free to squash directly.

[krzysztof-cabaj]

Hmmm ... If I understand CI output well examples/leds_shell did not fit to atmega8 flash.

I add Makefile.ci, but I suspect that more boards with small amount of flash could rise this same error.
Is in RIOT a tool which could I use on my machine to check this automatically? Or can we set some CI flag to not stop after first error?

Update: Maybe labels CI: full build and CI: no fast fail could be used to solve this problem?

[dylad]

@krzysztof-cabaj you should find the required tools for this job locally under dist/tools/insufficient_memory

[dylad]

You may also try dist/tools/compile_and_test_for_board/compile_and_test_for_board.py for your board, but to run compile only (no test) for your board. It will try to compile your board for all available examples and tests. A list of all failed compilation should be printed at the end.

[krzysztof-cabaj]

I run dist/tools/insufficient_memory/create_makefile.ci.sh and only atmega8 did not fit to flash.

Can we add this PR once again to merge queue?