Look at the {fmt} library as a printer alternative #608
Labels
No Label
API Change
Breaking API Change
bug
build
cosmetics
Documentation
duplicate
feature
help wanted
hotfix
invalid
question
Refactor
Tests
wontfix
No Milestone
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: fsfw/fsfw#608
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Right now, the FSFW has to support two different printout formats.
One is using the
ostream
C++ API. This is an API which is safe but very verbose.The other API is the regular C API using
printf
.Unfortunately, there is no way to develop a uniform API because those two differ too much.
C++20 brings the the
std::format
library which makes text formatting as easy as in Python.It is strongly based on the
{fmt}
library. I think it might be a good idea to look into this formatting library to replace the dual printout support in the FSFW.I think the
{fmt}
library has smaller code size than C++osstream
and thus is also applicable for embedded targets. One first step would be to make it a dependency of the framework and also introduce it for the hosted OSAL.If it proves to be a better solution that the dual support being used right now, the next step would be to look how it changes the binary size for the
FreeRTOS
target. If the difference is in an acceptable range, all printouts in the framework could be replaced with