maybe consider changing the copyright here

Thanks, at typical copy&paste problem. The Kconfig still had to be completely updated 😎

No copyright notices and block comments are required for Markdown files.
(Remember to remove the closing piece of the block comment below as well).

Ah ok, now where it is a Markdown file, C comments are wrong now 😎

I was already wondering why Doxygen is complaining about a wrong list item.

You can let Doxygen do the enumeration for you instead of doing it manually.

Good catch, I'm wondering why it wasn't catched by the spell checker in CI?

guaranties is the valid plural form of guaranty and boad is simply not in the library: https://github.com/codespell-project/codespell/blob/d59cf4fe68f1d606c23f21a19ecd3828dbe8725e/codespell_lib/data/dictionary.txt#L9789

Sorry, I forgot to elaborate. Our official stylekeeper @maribu establishes the indentations after the # for #defines in #if statements to make them more readable, especially for multiple #if-layers.

Therefore the suggestion.

@maribu I really like indentation for nested #ifdef ... #endif directives or a sequence of defines within a conditional compilation. But especially for a bunch simple #ifndefs directives used as macro guards with just a single define depending on whether it is already defined or not, indentation leads to more "choppy" code that makes reading harder rather than better.

#ifndef ABDCX
#define ABDCX  x
#endif

#ifndef ABDCY
#define ABDCX  y
#endif

#ifndef ABDCZ
#define ABDCZ  z
#endif

vs.

#ifndef ABDCX
#  define ABDCX  x
#endif

#ifndef ABDCX
#  define ABDCY  y
#endif

#ifndef ABDCZ
#  define ABDCZ  z
#endif

IMHO, copy & paste errors are also easier to catch with the first variant than with the second variant because of the alignment of the identifiers. Personally, I would prefer if the indentation for such conditionals were not mandatory for such a single definition.

It doesn't matter for BTN0_INT_FLANK since the board doesn't have a button 😉 This was just a leftover. I didn't take care about it because usually each ESP32x board has a BOOT-Button that can be used as button once the application is loaded from flash.

I was just joking with the "official stylekeeper", but the indentation is indeed part of the Coding Convention https://github.com/RIOT-OS/RIOT/blob/master/CODING_CONVENTIONS.md#indentation-of-preprocessor-directives

But indeed maribu is a lot more experienced with code styling than I am, so maybe he can voice his opinion.

I was just joking with the "official stylekeeper", but the indentation is indeed part of the Coding Convention https://github.com/RIOT-OS/RIOT/blob/master/CODING_CONVENTIONS.md#indentation-of-preprocessor-directives

I know, I have read it 😉 but sometimes it is worth to discuss some style rules 😎

I would favor to just unconditionally stick with two spaces of indent. Style is pretty subjective, e.g. to me the second example with the indent is actually easier to read than the one without.

I would argue that adding exceptions to the coding conventions for short code makes the coding convention more complex and makes it more difficult to the use of tools such as clang-format and uncrustify, as special exceptions are not easily configured with such tools. Exceptions also tends to cause a lot of discussion (Would two #defines within the #ifndef ... #endif still be considered as short? How about three?).

In core @kaspar030 has enforced an "run uncrustify, don't discuss style" policy, even for the few cases the output of uncrustify not super ideal. I think we ended up spending more time to discuss the content of the code and almost no time on discussing style, which I believe is a good thing.

But anyway, so far we have not strictly enforced the coding convention outside of core yet, so I would not start insisting here.

Style is pretty subjective, e.g. to me the second example with the indent is actually easier to read than the one without.

Totally agree. Maybe I should look for an editor with better syntax highlighting, where macro names in defines and guards are somehow colored 😉 gnome-textedit only uses one color for complete preprocessor directives, so that in header files that only contain preprocessor directives, there is in fact no highlighting 😟

Looks like you found a cornercase in the headerguards check 😅
I'll add a PR to cover that.

This commit is for another ESP32 board 4e3bb01 ?

The boards/esp32-wemos-d1-r32/include/periph_conf.h is still unchanged.

Did you cd into the wrong directory? 😅

I just mixed some work when I was switching between differen branches 🙈

This should probably be one struct?

The compiler throws the following errors when building examples/basic/default:

In file included from /home/cbuec/RIOTstuff/riot-gettingstarted/RIOT/drivers/saul/init_devs/auto_init_saul_gpio.c:25:
/home/cbuec/RIOTstuff/riot-gettingstarted/RIOT/boards/esp32-wemos-d1-r32/include/gpio_params.h:33:16: error: 'BTN0_PIN' undeclared here (not in a function)
   33 |         .pin = BTN0_PIN,
      |                ^~~~~~~~
/home/cbuec/RIOTstuff/riot-gettingstarted/RIOT/boards/esp32-wemos-d1-r32/include/gpio_params.h:34:17: error: 'BTN0_MODE' undeclared here (not in a function)
   34 |         .mode = BTN0_MODE,
      |                 ^~~~~~~~~
/home/cbuec/RIOTstuff/riot-gettingstarted/RIOT/boards/esp32-wemos-d1-r32/include/gpio_params.h:42:33: error: redefinition of 'saul_gpio_params'
   42 | static const saul_gpio_params_t saul_gpio_params[] =
      |                                 ^~~~~~~~~~~~~~~~
/home/cbuec/RIOTstuff/riot-gettingstarted/RIOT/boards/esp32-wemos-d1-r32/include/gpio_params.h:29:33: note: previous definition of saul_gpio_params' with type 'const saul_gpio_params_t[1]'
   29 | static const saul_gpio_params_t saul_gpio_params[] =
      |                                 ^~~~~~~~~~~~~~~~
make[3]: *** [/home/cbuec/RIOTstuff/riot-gettingstarted/RIOT/Makefile.base:157: /home/cbuec/RIOTstuff/riot-gettingstarted/RIOT/examples/basic/default/bin/esp32-wemos-d1-r32/saul_init_devs/auto_init_saul_gpio.o] Error 1
make[2]: *** [/home/cbuec/RIOTstuff/riot-gettingstarted/RIOT/Makefile.base:31: ALL--/home/cbuec/RIOTstuff/riot-gettingstarted/RIOT/drivers/saul/init_devs] Error 2

This should probably be one struct?

Yeah, of course. But how could the compilation in Murdock succeed with this error, I'm a bit confused.

Anyway, since the board has no button, I will just drop the first structure. The problem was probably caused by copying and pasting these structures from different boards, sorry.

The CI only compiles for certain boards and this board is not one of them. Therefore the error would've shown only in the full build when the tests and examples are compiled for all boards, including this one.

With the inverted flag, the LED is off when writing 1 and on when writing 0.
Furthermore, the LED is on on startup.