sys/stdio: add stdio_none

[haukepetersen]

Contribution description

Right now, almost every platform is build using either stdio_uart or stdio_rtt as backend for outputting STDIO, even applications like tests/minimal that don't even use any STDIO. As this might be ok for code size reasons, this behavior is quite bad in terms of power consumption. In the case of stdio_uart, the configured UART device is always initialized and activated and thereby consuming significant power - if when not used...

This PR provides a very simple way for disabling the STDIO in/output by simply doing nothing on calls to stdio_init/read/write(), and hence it will prevent the system from initialization unused/unwanted hardware peripherals ans such.

Caveat: all platforms that manually specify a stdio_x module at the moment will not compile if USEMODULE += stdio_none is specified manually, as those preconfigured modules will collide with stdio_none. I haven't figured out a good way to handle that, yet.

Testing procedure

Compile any application (e.g. hello-world) for any board that is using stdio_uart as default. Using make info-modules you can verify, that with stdio_none no uart dependencies will be pulled.

Issues/PRs references

none

[kaspar030]

Duplicate of #10741?

[haukepetersen]

Yes - did I mention that I hate the stale bot?!

Anyhow, seems its the good old 'better not merge the quick fix but wait another 1-1000 years for the superb generic solution' problem. In #10741 two people talked about something greater and better, but appearently nothing happended, right?

[kaspar030]

Anyhow, seems its the good old 'better not merge the quick fix but wait another 1-1000 years for the superb generic solution' problem. In #10741 two people talked about something greater and better, but appearently nothing happended, right?

Yeah, better is the enemy of good enough...

Anyhow, the other PR is almost identical, with an added warning when develhelp is enabled (nice to have), and a probably needed fix for VFS. So I suggest going with that, also in light of the current discussion about ignoring previous work. @haukepetersen ok with you?

[haukepetersen]

of course! All I am interested in is a fix to my problem at hand, don't care who fixes it :-)

[aabadie]

#10741 is merged and provides the same thing. So closing this one.