rtems stm32 init #341
No reviewers
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
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: fsfw/fsfw#341
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "mueller/rtems-update-stm32"
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?
I managed to compile the FSFW for RTEMS on the STM32 with CMake. These changes were necessary on the STM32.
I managed to set the compile time as the Clock.
Clock::setClock
was not thread-safe I think. I implemented it like it is implemented in the RTEMS BSP. Also, I think theClock.cpp
returnvalues need to be updated.Also possible bug in
ReturnValue_t Clock::getDateAndTime(TimeOfDay_t* time)
. In any case casts like that should be explained or clarified if it isnt a bug.rtems initto rtems stm32 init@ -92,3 +105,4 @@
ReturnValue_t Clock::getDateAndTime(TimeOfDay_t* time) {
// TIsn't this a bug? Are RTEMS ticks always microseconds?
rtems_time_of_day* timeRtems = reinterpret_cast<rtems_time_of_day*>(time);
You are right. There must be a tics to microseconds conversion to be sure.
Reported #344 based on this.