Look at the {fmt} library as a printer alternative #608

Closed
opened 2022-04-29 10:48:19 +02:00 by muellerr · 0 comments
Owner

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

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}`](https://github.com/fmtlib/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
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: fsfw/fsfw#608
No description provided.