SAUL: Reduce RAM requirements

[maribu]

Contribution description

• Use fmt instead of printf/stdio for output in phydat and SAUL
  • This reduces RAM requirements a bit at the cost of slightly increased ROM

Testing procedure

examples/saul should still work as expected on you favorite board.

Issues/PRs references

None

---

Update: Changed description, as the third commit is split off into a separate PR

[smlng]

I agree with the usage (and changes) of fmt the other changes I find a bit controversial. Mainly that adding a new sensor now requires to change 2 enums instead of one, however I like the general idea of having a class and start numbering from there.

TL;DR: please split this in 2 PRs one for fmt (which I would merge directly) and one for the other change which (to me) need some discussion, for instance @leandrolanzieri might have an opinion on this too.

[smlng]

see comment above, I suggest to split this PR

[maribu]

I suggest to split this PR

Done, see #11394 for the stringification

[smlng]

I cannot see the RAM improvement, though I see an increase in ROM size. I compared this PR against master with board samr21-xpro using examples/saul and tests/saul in all cases I only saw increased text size compared to master

[maribu]

With gcc-avr in version 8.3.0 I get

   text	   data	    bss	    dec	    hex	filename
  10332	   2400	    971	  13703	   3587	with_pr.elf
  10066	   2474	    971	  13511	   34c7	wo_pr.elf

for the Arduino-Mega2560.

Basically, it depends on the application and toolchain if and how much memory is saved, as it will can only save RAM if printf does not get linked in.

Keeping in mind that e.g. GCC does not use printf() in a lot of cases (e.g. printf("%s\n", foo) will be replaced by puts(foo)), this can happen more often than one would guess when just looking at the source code. This is also why it does save RAM on the AVR. But that obviously is not the case on ARM :-/

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

comments addressed

[smlng]

I tested and can confirm that the output stays the same, the problem is I also see a size increase of > 200B for board pba-d-01-kw2x.

Also the code is not that readable anymore, with all these separate calls to fmt print* functions.

So I'd like to get comments from others on this: @kaspar030, @haukepetersen and @leandrolanzieri ?

[maribu]

I think the issue is that with other RIOT internal modules using stdio, this will basically result in to implementations for output being used. It would make most sense to me to decide on which one we would use throughout RIOTs internals, and then potentially update each module as a separate PR.

We could put the merging on a hold until everything has been converted to see how big the improvements will end up when it is completed.

Some arguments for moving away from stdio:

• Reduced RAM requirements
• Link time garbage collection becomes possible with fmt_*() and print_*()
  • E.g. with stdio float support has to be explicitly turned on via a module, but when it is not added but used no errors appear during compilation. So hard to debug run time issues occur, that will confuse users unaware of the pseudo module to enable float support
• The use ofstdio in production code is not MISRA compliant
  • Some companies care a lot about MISRA compliance, so this by itself has some merit
  • The arguments presented by MISRA to disallow use of stdio in production code do still apply, even if one generally does not care about MISRA
• stdio has been a constant source of bugs
  • Due to its complexity in the implementation of stdio itself
  • Due to its poor API in code using it. But that has been mostly mitigated by compilers parsing the format strings and checking if the arguments match in type and number

[benpicco]

#12305 might offer a more general solution.

[maribu]

#12305 might offer a more general solution.

For those architectures using newlib this is definitely a nice thing. But not every architecture is using newlib. Also, the memory requirements of stdio (and the missing possibility of link time garbage collection for implementations of format specifiers) are not the only reason to get rid of it.

[maribu]

I close this for now. A proper discussion on whether the move away from printf() will not be possible based on this PR. When #12305 is in and I have a demo branch to compare how not using stdio at all would compare to this (in terms of lines of code, ROM size, RAM size, ...), an inform decision on this suggestion can be made.