Task IF refactoring #636
3 Participants
Notifications
Due Date
No due date set.
Blocks
#643 Fix StorageAccessor move assignment
fsfw/fsfw
Reference: fsfw/fsfw#636
Reference in New Issue
Block a user
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-tidyrecommends 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
PeriodicTaskBaseandFixedTimeslotTaskBase.clang-tidyimprovementsRefactor 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 anExecutableObjectIFaccordinglyRefactor FixedTimeslotTaskIF
addSlotfunction which takes anExecutableObjectIFpointer and its Object IDRefactor FixedSequenceSlot
CustomCheckFuncforReturnValue_t (*customCheckFunction)(const SlotList&).ReturnValue_t (*customCheckFunction)(const SlotList&)toReturnValue_t (*customCheckFunction)(const SlotList&, void*), allowing arbitrary user argumentsfor the custom checker
Linux OSAL
PeriodicPosixTaskand make thePosixTaska member of the class6546be5013toad53b48fcbI 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 constexprconstants, 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 typenameTaskDeadlineMissedFunctionRemoved 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