WIP: Refactor logging system with {fmt} #620
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#620
Loading…
Reference in New Issue
No description provided.
Delete Branch "mueller/refactor-logging-with-fmt"
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?
Related issue: #609
.at()
API). Some of them are really useful and they were never explicitely disabled anyway.{fmt}
also supports writing to a filefmt
. This makes the feature also future-proofTODO
{fmt}
probably has helper functions for thisEventManager
debug printout fixExample code
Some test code in the hosted example, which displays
different ways to use the
fsfw
loggersMigration information
Code Size Benchmarks
Tests done on Hosted Example Repo tag
466b088dcea7
and compilergcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0
. There will be some more tests. Speed benchmarks should not be necessary. Those were covered by the author himself.Using {fmt}, linked statically
Debug builds
LTO Enabled
LTO Disabled
Release builds
LTO Enabled
LTO Disabled
Size builds
LTO Enabled
LTO Disabled
Using {fmt}, shared library
Debug builds
LTO Enabled
LTO Disabled
Release builds
LTO Enabled
LTO Disabled
Size builds
LTO Enabled
LTO Disabled
Using iostream
tag
21b3e46a72
Debug builds
LTO Enabled
LTO Disabled
Release builds
LTO Enabled
LTO Disabled
Size builds
LTO Enabled
LTO Disabled
Refactor logging system with {fmt}to WIP: Refactor logging system with {fmt}I checked the code size when compiling the OBSW for FreeRTOS. It is significantly larger than the
printf
variant, at around 840kB when compiled with size optimization. It was planned to keep the OBSW image size below 840kB to allow booting from the NOR-Flash which would not be possible like this because the OBSW will grow.I am not sure if it's really feasable to pull in big dependencies like this, especially when small bare metal code want to only use parts of the FSFW. The best solution might be to still keep supporting the traditional
printf
API by renamingFSFW_CPP_OSTREAM_ENABLED
toFSFW_USE_FMT_LOG
. Systems with a runtime like Embedded Linux or bare metal systems with flash sizes over 1MB can then use the FMT logger while smaller systems can use theprintf
API. One advantage of that would be that the API is really similar. Some suggestions/initial ideas on how to name the new API:printf API
Without timestamp
INFO:
sif::pinfo(...)
DEBUG:
sif::pdebug(...)
WARNING:
sif::pwarning(...)
ERROR:
sif::perror(...)
With timestamp
Append
_(s)t
to the API calls shown aboveWith source file location
Append
_s(t)
to the API calls shown abovefmt API
Without timestamp
INFO:
sif::finfo(...)
DEBUG:
sif::fdebug(...)
WARNING:
sif::fwarning(...)
ERROR:
sif::ferror(...)
With timestamp
Append
_t
to the API calls shown aboveMacro API
The macros will forwards all their arguments to either the
printf
API or to thefmt
API. Thanks to the similar API this is possible.Without timestamp
INFO:
FSFW_LOGI(...)
DEBUG:
FSFW_LOGD(...)
WARNING:
FSFW_LOGW(...)
ERROR:
FSFW_LOGE(...)
With timestamp
Append
T
to the macro calls aboveWith source file location
Harcoded, enabled by default for DEBUG, WARNING and ERROR
Additional information
Coloring of the logs is optional.
Step 1:
From your project repository, check out a new branch and test the changes.Step 2:
Merge the changes and update on Gitea.