Task IF refactoring #636
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
3 Participants
Notifications
Due Date
No due date set.
Blocks
#643 Fix StorageAccessor move assignment
fsfw/fsfw
Reference: fsfw/fsfw#636
Loading…
Reference in New Issue
No description provided.
Delete Branch "mueller/task-if-refactoring"
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?
These changes were tested on all OSALs. The FreeRTOS and RTEMS updates wered tested in the FSFW example for the STM32H7. The Linux changes were tested in the EIVE fork.
The hosted changes were tested in the hosted FSFW example.
Also, some other general improvements/notes:
There seems to be a concensus that virtual functions should not have default arguments. See https://google.github.io/styleguide/cppguide.html#Default_Arguments
and this stack overflow post https://www.google.com/search?channel=fs&client=ubuntu&q=default+arguments+on+virtual+or+override+methods+are+prohibited .
Also,
clang-tidy
recommends adding[[nodiscard]]
to all constant getters.For me, this seems to be a reasonable action. It can prevent missed returnvalue checks and useless getter function calls. If someone decides to actively ignore a returnvalue, they can explicitely cast the function call to void to avoid the warning.
Also, it might be a good idea to compile the FreeRTOS and RTEMS OSALs in the CI/CD as well. It should be possible to create a docker container which has all necessary tools pre-installed.
Refactoring general task code
PeriodicTaskBase
andFixedTimeslotTaskBase
.clang-tidy
improvementsRefactor PeriodicTaskIF
virtual ReturnValue_t addComponent(object_id_t object)
tovirtual ReturnValue_t addComponent(object_id_t object, uint8_t opCode = 0)
, allowing to pass the operation code passed toperformOperation
. Update API taking anExecutableObjectIF
accordinglyRefactor FixedTimeslotTaskIF
addSlot
function which takes anExecutableObjectIF
pointer and its Object IDRefactor FixedSequenceSlot
CustomCheckFunc
forReturnValue_t (*customCheckFunction)(const SlotList&)
.ReturnValue_t (*customCheckFunction)(const SlotList&)
toReturnValue_t (*customCheckFunction)(const SlotList&, void*)
, allowing arbitrary user argumentsfor the custom checker
Linux OSAL
PeriodicPosixTask
and make thePosixTask
a member of the classTask IF refactoringto WIP: Task IF refactoringWIP: Task IF refactoringto Task IF refactoringTask IF refactoringto WIP: Task IF refactoringWIP: Task IF refactoringto Task IF refactoring6546be5013
toad53b48fcb
I would prefer a bitmore vocal name for
dlmFunc_
.As you can see from me nitpicking naming conventions, no bigger issues from my side ;)
@ -52,3 +47,1 @@
uint32_t getPeriodMs() const override;
ReturnValue_t checkSequence() const override;
static uint32_t MISSED_DEADLINE_COUNT;
what is the reasoning to make the static variable namw CAPS? For me CAPS is used for
static constexpr
constants, which do not change during runtime, while the static member does change.Also, is it useful to move this into the base class?
dlmFunc_
is ok in my opinion, the purpose in encoded inside the very long typenameTaskDeadlineMissedFunction
Removed the statics in all OSAL. The way they are used does not make a lot of sense and the usage of the static is not thread-safe either.
LGTM
Does not build on Linux. Will be fixed asap
Linux OSAL builds now.
LGTMT