Add central memory layout for FRAM #304
Conversation
|
The defined constants still need to be put into some files which define these constants themselves. This will probably lead to a chicken-and-egg problem in files which are needed by FramLayout for size information but need FramLayout themselves for address and capacity information (e.g. Edu/ProgramStatusHistory.hpp). |
PatrickKa
force-pushed
the
fram-layout-293
branch
from
ff7160b to
ae785e0
Compare
The reason for this is that totalSerialSize<> ensures that the serial size of its arguments is not 0.
For some reason codespell wants to rename FramLayout.hpp to framelayout.hpp. Since this is a filename I cannot add code comment or something to tell codespell to ignore it. Therefore, I put framlayout on the ignore list.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #304 +/- ##
==========================================
- Coverage 88.34% 87.58% -0.76%
==========================================
Files 27 28 +1
Lines 695 701 +6
Branches 8 8
==========================================
Hits 614 614
- Misses 81 87 +6 ☔ View full report in Codecov by Sentry. |
Section<> only has static members. Accessing them through the instances defined in FramLayout.hpp would yield clang-tidy warnings. Therefore, I provided type aliases for convenience.
The type alias is added in preparation for turning Address and Size into strong types.
LfsStorageDevice.hpp is not yet renamed to prevent merge conflicts with the lfs wrapper branch.
|
The chicken-and-egg problem will be solved by defining the sections sizes independent of the things they hold. That means that ProgramQueue.hpp and ProgramStatusHistory.hpp depend on the FRAM layout, but not vice versa. Of course, we can, and do, statically assert that the queue and the status history fit in their respective sections. I think this is a simple, easy, and sound solution. |
Fixes #293