Browse Source

Merge branch 'cleanup'

master v0.4
Nicolas Clauvelin 3 years ago
parent
commit
6433346d01
  1. 41
      .gitlab/issue_templates/bug.md
  2. 27
      .gitlab/issue_templates/configuration.md
  3. 19
      .gitlab/issue_templates/documentation.md
  4. 21
      .gitlab/issue_templates/feature_request.md
  5. 21
      .gitlab/issue_templates/improvement.md
  6. 17
      .gitlab/issue_templates/question.md
  7. 21
      .gitlab/issue_templates/requirement.md
  8. 23
      .gitlab/merge_request_templates/default.md
  9. 39
      API.md
  10. BIN
      Assembly_Comparison.png
  11. 26
      CMakeLists.txt
  12. 46
      CODE_OF_CONDUCT.md
  13. 2
      LICENSE
  14. 10
      Performance.md
  15. 9
      QuickStart.md
  16. 20
      README.md
  17. 6
      cppreg.h
  18. 67
      cppreg_Defines.h
  19. 4
      cppreg_Includes.h
  20. 586
      policies/AccessPolicy.h
  21. 404
      register/Field.h
  22. 107
      register/Internals.h
  23. 60
      register/Mask.h
  24. 106
      register/Memory.h
  25. 389
      register/MergeWrite.h
  26. 212
      register/Register.h
  27. 320
      register/RegisterPack.h
  28. 50
      register/ShadowValue.h
  29. 92
      register/Traits.h
  30. 1093
      single/cppreg-all.h

41
.gitlab/issue_templates/bug.md

@ -0,0 +1,41 @@
### Summary
*(Summarize the bug or unexpected behavior encountered concisely)*
### Version and platform information
*(Give the commit/branch or version information of the project for which the bug was observed)*
*(If the bug was observed on a specific platform give the details here)*
### Customer information
*(If the bug was reported by a customer give the relevant details here)*
### Steps to reproduce
*(How can the bug be reproduced - be as accurate as possible)*
### What is the current *bug* behavior?
*(What actually happens: e.g. crash, wrong results, ...)*
### What is the expected *correct* behavior?
*(What you should be happening instead)*
### Relevant logs, screenshots, or inputs
*(Paste using code block (```) or attach any piece of information)*
*(If specific inputs are needed to observe the bug paste them or attach them)*
### Possible causes or fixes
*(If you have identified the cause of the bug or have a potential fix please link the line(s) of code and comment appropriately)*
*Final check: set origin label, set priority/severity if applicable*
*Clean up: remove any comment from the template if not applicable*
/label ~"kind:bug"

27
.gitlab/issue_templates/configuration.md

@ -0,0 +1,27 @@
### Questionnaire
* [ ] Issue related to GitLab project configuration?
* [ ] Issue related to project build process (e.g. toolchain)?
* [ ] Issue related to Git configuration (e.g. gitignore file)?
### Version information
*(Give the commit/branch or version information of the project for which this configuration issue needs to be considered)*
### Policy or guidelines reference
*(Refer here to the policy or guideline that relates to this issue and indicate if a violation or deviation should be addressed)*
### Details
*(Explain here or attach what should be done to fix this issue)*
### Attachments
*(Paste using code block (```) or attach any piece of information illustrating the issue)*
*Final check: set origin label, set priority/severity if applicable*
*Clean up: remove any comment from the template if not applicable*
/label ~"kind:configuration"

19
.gitlab/issue_templates/documentation.md

@ -0,0 +1,19 @@
### Questionnaire
* [ ] New or additional documentation needed?
* [ ] Current documentation is out of date or erroneous?
* [ ] Documentation needs review?
### Version information
*(Give the commit/branch or version information of the project for which this documentation issue needs to be considered)*
### Details
*(Explain here or attach what should be done to fix this issue)*
*Final check: set origin label, set priority/severity if applicable*
*Clean up: remove any comment from the template if not applicable*
/label ~"kind:documentation"

21
.gitlab/issue_templates/feature_request.md

@ -0,0 +1,21 @@
### Problem to solve
*(What is the new feature trying to solve or provide?)*
### Customer information
*(If the feature was suggested by a customer give the relevant details here)*
### Proposal
*(Explain what this feature will bring in terms of benefits and how it fits in the project scope)*
### Links and references
*(Add links or references if applicable)*
*Final check: set origin label, set priority/severity if applicable*
*Clean up: remove any comment from the template if not applicable*
/label ~"kind:feature request"

21
.gitlab/issue_templates/improvement.md

@ -0,0 +1,21 @@
### Functionality to improve and goal
*(Explain what exactly needs to be improved and what is the goal)*
### Customer information
*(If the improvement was suggested by a customer give the relevant details here)*
### Proposal
*(Explain how the functionality could be improved and the various things to consider to achieve this goal)*
### Links and references
*(Add links or references if applicable)*
*Final check: set origin label, set priority/severity if applicable*
*Clean up: remove any comment from the template if not applicable*
/label ~"kind:improvement"

17
.gitlab/issue_templates/question.md

@ -0,0 +1,17 @@
### Question
*(Write the question as explicit as you can)*
### Customer information
*(If the question was submitted by a customer give the relevant details here)*
### Additional information
*(Add links, references, or any other piece of information)*
*Final check: set origin label, set priority/severity if applicable*
*Clean up: remove any comment from the template if not applicable*
/label ~"kind:question"

21
.gitlab/issue_templates/requirement.md

@ -0,0 +1,21 @@
### Requirement specifications
*(Give the details about the requirement that needs to be implemented)*
### Project information
*(If this issue relates to a requirement defined in a project specification existing somewhere give all references and information here)*
### Customer information
*(If the requirement was defined by a customer give the relevant details here)*
### Testing
*(Explain how the requirement implementation should be tested or how it fit in the current testing plan of the project)*
*Final check: set origin label, set priority/severity if applicable*
*Clean up: remove any comment from the template if not applicable*
/label ~"kind:requirement"

23
.gitlab/merge_request_templates/default.md

@ -0,0 +1,23 @@
### Summary of the MR
*(Explain what modifications are part of this MR; refer to issues or milestones if needed)*
### List of issues addressed by this MR
*(Edit the list of issues)*
* Closes #xxx
* Closes #xxx
* ...
### Additional information
* [ ] Does the MR update any submodule?
* [ ] Does the MR break any functionality or alter performance ?
* [ ] Does the MR require issues to be created to deal with side effects?
*(Give more details if needed)*
*Clean up: remove any comment from the template if not applicable*
/label ~"merge:review"

39
API.md

@ -1,5 +1,5 @@
# cppreg: API #
Copyright Sendyne Corp., 2010-2018. All rights reserved ([LICENSE](LICENSE)).
Copyright Sendyne Corp., 2010-2019. All rights reserved ([LICENSE](LICENSE)).
## Introduction ##
@ -17,15 +17,15 @@ The entire implementation is encapsulated in the `cppreg::` namespace. All the c
The API was designed such that `cppreg`-based code is safer and more expressive than traditional low-level code while providing the same level of performance.
As explained below, when using `cppreg`, registers and fields are defined as C++ types specializing pre-defined template types. This can be done by explicitly deriving from the specialized template type or by using the `using` keyword (both approaches are strictly equivalent). With the exception of the merged write mechanism discussed below, all methods provided by the `cppreg` types are static methods.
As explained below, when using `cppreg`, registers and fields are defined as C++ types specializing pre-defined template types. This can be done by explicitly deriving from the specialized template type or by using the `using` keyword (both approaches are strictly equivalent). With the exception of the merged write mechanism discussed below, all methods provided by the `cppreg` types are static methods.
## Data types ##
`cppreg` introduces type aliases in order to parameterize the set of data types used in the implementation. By default the following types are defined (see [cppreg_Defines.h](cppreg_Defines.h) for more details):
* `Address_t` is the data type used to hold addresses of registers and fields; it is equivalent to `std::uintptr_t`,
* `Address` is the data type used to hold addresses of registers and fields; it is equivalent to `std::uintptr_t`,
* register sizes are represented by the enumeration type `RegBitSize`,
* `FieldWidth_t` and `FieldOffset_t` are the data types to represent field sizes and offsets; both are equivalent to `std::uint8_t`.
* `FieldWidth` and `FieldOffset` are the data types to represent field sizes and offsets; both are equivalent to `std::uint8_t`.
### Register size ###
The `RegBitSize` enumeration type represents the register sizes supported in `cppreg` and the values are:
@ -46,7 +46,7 @@ In `cppreg`, registers are represented as memory locations that contain fields,
Most of the times registers are part of groups related to peripherals or specific functionalities within a MCU. It is therefore recommended to use the register pack implementation rather than the standalone one. This ensures that the assembly generated from `cppreg`-based code will be optimal. In other words, the difference between packed registers and standalone registers is only a matter of performance in the generated assembly: the packed register interface relies on mapping an array on the pack memory region, which provides to the compiler the ability to use offset between the various registers versus reloading their absolute addresses.
Moreover, the same level of functionality is provided by both implementations (`RegisterPack` is simply deriving from `Register` and redefining accessor and modifier methods). That is, a packed register type can be replaced by a standalone register type (and *vice versa*).
Moreover, the same level of functionality is provided by both implementations (`RegisterPack` is simply deriving from `Register`). That is, a packed register type can be replaced by a standalone register type (and *vice versa*).
### Register pack interface ###
To define a pack of registers:
@ -73,7 +73,7 @@ The interface is (see [RegisterPack.h](register/RegisterPack.h)):
| `reset_value` | register reset value (defaulted to zero) |
| `use_shadow_value` | enable shadow value if `true` (see below) |
Note that, the reset value is only useful when a shadow value is used.
Note that, the reset value is only used when shadow value support is enabled.
The following example defines a 4 bytes register pack starting at address 0xA4000000 and containing: two 8-bit register and a 16-bit register. The `cppreg` implementation is:
@ -106,7 +106,7 @@ struct SomePeripheral {
}
```
There are a few requirements for when defining packed registers:
There are a few requirements when defining packed registers:
* for a register of size N bits, the pack base address has to be aligned on a N bits boundary,
* for a register of size N bits, the pack base address plus the offset has to be aligned on a N bits boundary,
@ -126,7 +126,7 @@ The interface for standalone register is (see [Register.h](register/Register.h))
| `reset_value` | register reset value (defaulted to zero) |
| `use_shadow_value` | enable shadow value if `true` (see below) |
Note that, the reset value is only useful when a shadow value is used.
Note that, the reset value is only used when shadow value support is enabled.
For example, consider a 32-bit register `SomeRegister` mapped at `0x40004242`. The `Register` type is created using:
@ -226,7 +226,7 @@ static std::array<std::uint8_t, Channels::n_elems> some_buffer = {};
// Iterate over the pack and use a lambda.
// Note the "auto index" ... this is required because the loop will
// use std::integral_constant to pass the index while iterating.
pack_loop<Channels>::apply<ChannelsCollector>([](auto index) {
pack_loop<Channels>::apply([](auto index) {
some_buffer[index] = Channels::elem<index>::read();
Channels::elem<index>::template write<index>();
});
@ -305,12 +305,12 @@ SomeField::write<0xAB>(); // Template version for constant value write.
SomeField::write(0xAB); // Function argument version.
```
The advantages of using the constant value version are:
The advantages of using the constant value form are:
* `cppreg` will most of the time use a faster implementation for the write operation (this is particularly true if the field spans an entire register),
* a compile-time error will occur if the value overflow the field.
Note that, even when using the non-constant value version overflow will not occur: only the bits part of the `Field`-type will be written and any data that does not fit the region of the memory assigned to the `Field`-type will not be modified. For example:
Note that, even when using the non-constant value form overflow will not occur: only the bits fitting in the `Field`-type will be written and any data that does not fit the region of the memory assigned to the `Field`-type will not be modified. For example:
```c++
// Register definition with nested fields definitions.
@ -332,7 +332,7 @@ SomeRegister::Frequency::write<0x111>();
## Shadow value: a workaround for write-only fields ##
Write-only fields are somewhat special as extra-care has to be taken when manipulating them. The main difficulty resides in the fact that write-only field can be read but the value obtained by reading it is fixed (*e.g.*, it always reads as zero). `cppreg` assumes that write-only fields can actually be read from; if such an access on some given architecture would trigger an error (*à la FPGA*) then `cppreg` is not a good choice to deal with write-only fields on this particular architecture.
Write-only fields are somewhat special and extra-care has to be taken when manipulating them. The main difficulty resides in the fact that write-only field can be read but the value obtained by reading it is fixed (*e.g.* it always reads as zero). `cppreg` assumes that write-only fields can actually be read from; if such an access on some architecture would trigger an error (*à la FPGA*) then `cppreg` is not a good choice to deal with write-only fields on this particular architecture.
Consider the following situation:
@ -364,7 +364,7 @@ As a workaround, `cppreg` offers a shadow value implementation which mitigates t
struct Reg : Register<
0x40004242, // Register address
RegBitSize::b32, // Register size
0x42u // Register reset value
0x42u, // Register reset value
true // Enable shadow value for the register
>
{
@ -373,7 +373,7 @@ struct Reg : Register<
};
```
The shadow value implementation for a write-only field works as follow:
The shadow value implementation for a write-only field works as follows:
* at static initialization time, the reset value of the register owning the field is used to initialize the shadow value (the shadow value is used for the entire register content),
* at each write access to any of the register fields, the shadow value will be updated and written to the entire register memory.
@ -388,9 +388,9 @@ A few safety guidelines:
## MergeWrite: writing to multiple fields at once ##
It is sometimes the case that multiple fields within a register needs to be written at the same time. For example, when setting the clock dividers in a MCU it is often recommended to write all their values to the corresponding register at the same time (to avoid overclocking part of the MCU).
It is sometimes the case that multiple fields within a register needs to be written at the same time. For example, when setting the clock dividers in a MCU it is often recommended to write all their values to the corresponding register at the same time (to avoid mis-clocking part of the MCU).
Consider the following setup (not so artifical; it is inspired by a real flash memory controller peripheral):
Consider the following setup (not so artificial; it is inspired by a real flash memory controller peripheral):
```c++
struct FlashCtrl : Register<0xF0008282, RegBitSize::b8> {
@ -414,14 +414,14 @@ struct FlashCtrl : Register<0xF0008282, RegBitSize::b8> {
Now let's assume the following scenario:
1. The previous flash command failed because it attempted to write or erase in a protected section, at that point the content of the `FlashCtrl` register is `1001 XXXX` where `XXXX` is whatver value associated with the command that failed.
1. The previous flash command failed because it attempted to write or erase in a protected section, at that point the content of the `FlashCtrl` register is `1001 XXXX` where `XXXX` is whatever value associated with the command that failed.
2. Before we can perform a new flash command we need to clear the `ProtectionError` by writing 1 to it (otherwise the new command will not be started); so one could think about doing:
```c++
FlashCtrl::ProtectionError::set(); // Write to ProtectionError to clear it.
```
however this write at `1000 XXXX | 0001 0000 = 1001 XXXX` at the register level and thus start the command that previously failed.
however this write `1000 XXXX | 0001 0000 = 1001 XXXX` at the register level and thus start the command that previously failed.
3. At this point one could try to set the value for the new command but that will fail as well (because `ProtectionError` was not cleared and it is required to be).
4. A possible alternative would be to fully zero out the `FlashCtrl` register but that would somewhat defeat the purpose of `cppreg`.
@ -434,7 +434,7 @@ FlashCtrl::merge_write<FlashCtrl::ProtectionError, 0x1>().with<FlashCtrl::Comman
// This will correspond to write with a mask set to 1001 0000,
// which boils down to write (at the register level):
// 0000 XXXX | 0001 0000 = 0001 XXXX ... CommandComplete is not set to 1 !
// 0000 XXXX | 0001 0000 = 0001 XXXX ... CommandComplete is not set to 1!
```
The `merge_write` method is only available in register type (`PackedRegister` or `Register`) that do not enable the shadow value mechanism. The `Field`-based types used in the chained call are required to *be from* the register type used to call `merge_write`. In addition, the `Field`-types are also required to be writable. By design, the successive write operations have to be chained, that is, it is not possible to capture a `merge_write` context and add other write operations to it; it always has to be of the form: `register::merge_write<field1, xxx>().with<field2, xxx>(). ... .done()`.
@ -442,4 +442,3 @@ The `merge_write` method is only available in register type (`PackedRegister` or
**Warning:** if`done()` is not called at the end of the successive write operations no write at all will be performed.
Similarly to regular write operations it is recommended to use the template version (as shown in the example) if possible: this will enable overflow checking and possibly use faster write implementations. If not possible the values to be written are passed as arguments to the various calls.

BIN
Assembly_Comparison.png

Before

Width: 622  |  Height: 808  |  Size: 162 KiB

After

Width: 849  |  Height: 921  |  Size: 96 KiB

26
CMakeLists.txt

@ -7,48 +7,50 @@
# -------------------------------------------------------------------------- #
# --- cppreg library files ---
# --- cppreg library ---
# Header directories.
set(CPPREG_HEADERS_DIRS
set(cppreg_headers_dirs
.
policies/
register/)
# List of API headers.
set(CPPREG_API_HEADERS
set(cppreg_headers
cppreg.h
cppreg_Defines.h
cppreg_Includes.h
policies/AccessPolicy.h
register/Field.h
register/Internals.h
register/Mask.h
register/Overflow.h
register/Memory.h
register/MergeWrite.h
register/Register.h
register/RegisterPack.h
register/ShadowValue.h
register/Traits.h)
# Refactor headers directories.
set(BUILD_HEADERS_DIRS "")
foreach(dir IN ITEMS ${CPPREG_HEADERS_DIRS})
list(APPEND BUILD_HEADERS_DIRS "${CMAKE_CURRENT_SOURCE_DIR}/${dir}")
set(build_cppreg_headers_dirs "")
foreach(dir IN ITEMS ${cppreg_headers_dirs})
list(APPEND build_cppreg_headers_dirs "${CMAKE_CURRENT_SOURCE_DIR}/${dir}")
endforeach()
# Header-only library.
add_library(cppreg INTERFACE)
target_include_directories(cppreg INTERFACE . register/ policies/)
target_include_directories(cppreg INTERFACE ${cppreg_headers_dirs})
# Include directories interfaces.
# This properly setup the API headers for the build and install phase.
set_property(TARGET cppreg
PROPERTY INTERFACE_INCLUDE_DIRECTORIES
$<BUILD_INTERFACE:${BUILD_HEADERS_DIRS}>
$<BUILD_INTERFACE:${build_cppreg_headers_dirs}>
$<INSTALL_INTERFACE:include/cppreg>)
# --- Install directives ---
install(FILES ${CPPREG_API_HEADERS} DESTINATION include/cppreg)
install(TARGETS cppreg DESTINATION lib EXPORT cppreg-libs)
install(EXPORT cppreg-libs DESTINATION include/cppreg)
install(FILES ${cppreg_headers} DESTINATION include/cppreg)
install(TARGETS cppreg DESTINATION lib EXPORT cppreg-target)
install(EXPORT cppreg-target DESTINATION include/cppreg)

46
CODE_OF_CONDUCT.md

@ -1,46 +0,0 @@
# Contributor Covenant Code of Conduct
## Our Pledge
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at nclauvelin+github@sendyne.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
[homepage]: http://contributor-covenant.org
[version]: http://contributor-covenant.org/version/1/4/

2
LICENSE

@ -5,7 +5,7 @@
/____/\___/_/ /_/\__,_/\__, /_/ /_/\___/ \___/\____/_/ / .___(_).
/____/ /_/
Copyright 2010-2018 Sendyne Corporation.
Copyright 2010-2019 Sendyne Corporation.
All rights reserved.
Sendyne Corp., 250 West Broadway, New York, NY 10013, USA.

10
Performance.md
File diff suppressed because it is too large
View File

9
QuickStart.md

@ -1,5 +1,5 @@
# cppreg: quick start #
Copyright Sendyne Corp., 2010-2018. All rights reserved ([LICENSE](LICENSE)).
Copyright Sendyne Corp., 2010-2019. All rights reserved ([LICENSE](LICENSE)).
This document is a brief introduction to `cppreg` and how to use it. For more details about the implementation refers to the [API documentation](API.md).
@ -14,7 +14,8 @@ There are two recommended ways to use `cppreg` in a project:
# Include cppreg library.
# The second argument is not necessarily required depending on the project setup.
# This will import the cppreg target.
# Because cppreg is a header-only library the cppreg target is actually an INTERFACE library target.
# Because cppreg is a header-only library the cppreg target is actually an
# INTERFACE library target.
add_subdirectory(/path/to/cppreg ${PROJECT_BINARY_DIR)/cppreg)
...
@ -59,7 +60,7 @@ The RX and TX data registers both contain a single DATA field occupying the whol
The goal of `cppreg` is to facilitate the manipulation of such a peripheral. This can be done as follow:
```c++
#include <cppreg.h> // use cppreg-all.h instead if you are using the single header.
#include <cppreg.h> // use cppreg-all.h if you are using the single header.
using namespace cppreg;
// Peripheral structure.
@ -150,7 +151,7 @@ while (true) {
A few remarks:
* the `write` calls for the `Setup` register pass the data as template arguments, while the write call for the `TX` register pass it as a function argument: if the value to be written is known at compile time it is recommended to use the template form; the template form will detect overflow (see below) and will also make it possible to use a faster write implementation in some cases,
* the `write` calls for the `Setup` register pass the data as template arguments, while the write call for the `TX` register pass it as a function argument: if the value to be written is known at compile time it is recommended to use the template form; the template form will detect overflow (see below) and will also make it possible to use a more efficient write implementation in some cases,
* `Field`-based types have `is_set` and `is_clear` defined to conveniently query their states.
In this example, we can already see how `cppreg` limits the possibility of errors (see the [API documentation](API.md) for more details):

20
README.md

@ -1,24 +1,24 @@
# cppreg #
Copyright Sendyne Corp., 2010-2018. All rights reserved ([LICENSE](LICENSE)).
Copyright Sendyne Corp., 2010-2019. All rights reserved ([LICENSE](LICENSE)).
## Description ##
`cppreg`is a header-only C++11 library to facilitate the manipulation of MMIO registers (*i.e.*, memory-mapped I/O registers) in embedded devices. The idea is to make it possible to write expressive code and minimize the likelihood of ill-defined expressions when dealing with hardware registers on a MCU. The current features are:
`cppreg` is a header-only C++11 library to facilitate the manipulation of MMIO registers (*i.e.*, memory-mapped I/O registers) in embedded devices. The idea is to provide a way to write expressive code and minimize the likelihood of ill-defined expressions when dealing with hardware registers on a MCU. The current features are:
* expressive syntax which shows the intent of the code when dealing with registers and fields,
* efficiency and performance on par with traditional C implementations (*e.g.*, CMSIS C code) when *at least some compiler optimizations* are enabled,
* [huge emphasis](Performance.md) on ensuring the assembly is the same if not better than CMSIS versions,
* field access policies (*e.g.*, read-only vs read-write) detect ill-defined access at compile-time,
* efficiency and performance on par with traditional C implementations (*e.g.* CMSIS C code) when *at least some compiler optimizations* are enabled,
* [emphasis](Performance.md) on ensuring the assembly is the same if not better than CMSIS versions,
* field access policies (*e.g.* read-only vs read-write) detect ill-defined access at compile-time,
* compile-time detection of overflow,
* easily extendable to support, for example, mock-up.
* register memory can easily be mocked up so that testing is possible.
For a short introduction and how-to see the [quick start guide](QuickStart.md). A more complete and detailed documentation is available [here](API.md).
The features provided by `cppreg` come with no overhead or performance penalty compared to traditional low-level C approaches. We give [here](Performance.md) an example comparing the assembly generated by a CMSIS-like implementation versus a `cppreg` one.
The features provided by `cppreg` come with no overhead or performance penalty compared to traditional low-level C approaches. We give [here](Performance.md) an example comparing the assembly generated by a CMSIS-like implementation versus a `cppreg`-based one.
## Requirements ##
`cppreg` is designed to be usable on virtually any hardware that statisfies the following requirements:
`cppreg` is designed to be usable on virtually any hardware that satisfies the following requirements:
* MMIO register sizes are integral numbers of bytes (*e.g.*, 8 bits, 16 bits, ...),
* registers are properly aligned: a N-bit register is aligned on a N-bit boundary,
@ -41,11 +41,11 @@ while ((MCG->S & MCG_S_PLLST_MASK) == 0)
This piece of code is part of the clock setup on a flavor of the K64F MCU. `MCG` is a peripheral and `MCG->C6` and `MCG->S` are registers containing some fields which are required to be set to specific values to properly clock the MCU. Some of the issues with such code are:
* the intent of the code is poorly expressed, and it requires at least the MCU data sheet or reference manual to be somewhat deciphered/understood,
* since the offsets and masks are known at compile time, it is error prone and somewhat tedious that the code has to manually implement shifting and masking operations,
* since the offsets and masks are known at compile time, it is error prone and somewhat tedious that the code has to re-implement shifting and masking operations,
* the code syntax itself is extremely error prone; for example, forget the `|` in `|=` and you are most likely going to spend some time debugging the code,
* there is no safety at all, that is, you might overflow the field, or you might try to write to a read-only field and no one will tell you (not the compiler, not the linker, and at runtime this could fail in various ways with little, if any, indication of where is the error coming from).
This does not have to be this way, and C++11 brings a lot of features and concepts that make it possible to achieve the same goal while clearly expressing the intent and being aware of any ill-formed instructions. Some will argue this will come at the cost of a massive performance hit, but this is actually not always the case (and more often than not, a C++ implementation can be very efficient; see [Ken Smith paper] and the example below).
This does not have to be this way, and C++11 brings a lot of features and concepts that make it possible to achieve the same goal while clearly expressing the intent and being aware of any ill-formed instructions. Some will argue this will come at the cost of a massive performance hit, but this is actually not always the case (and more often than not, a C++ implementation can be very efficient; see [Ken Smith] paper and the example below).
This project has been inspired by the following previous works:

6
cppreg.h

@ -2,7 +2,7 @@
/**
* @file cppreg.h
* @author Nicolas Clauvelin (nclauvelin@sendyne.com)
* @copyright Copyright 2010-2018 Sendyne Corp. All rights reserved.
* @copyright Copyright 2010-2019 Sendyne Corp. All rights reserved.
*/
@ -10,11 +10,11 @@
#define CPPREG_CPPREG_H
#include "Field.h"
#include "Internals.h"
#include "MergeWrite.h"
#include "Register.h"
#include "RegisterPack.h"
#include "Field.h"
#endif // CPPREG_CPPREG_H
#endif // CPPREG_CPPREG_H

67
cppreg_Defines.h

@ -2,7 +2,7 @@
/**
* @file cppreg_Defines.h
* @author Nicolas Clauvelin (nclauvelin@sendyne.com)
* @copyright Copyright 2010-2018 Sendyne Corp. All rights reserved.
* @copyright Copyright 2010-2019 Sendyne Corp. All rights reserved.
*
* This header mostly defines data types used across the project. These data
* types have been defined with 32-bits address space hardware in mind. It
@ -17,50 +17,49 @@
#include "cppreg_Includes.h"
//! cppreg namespace.
namespace cppreg {
//! Type alias for register and field addresses.
/**
* By design this type ensures that any address can be stored.
*/
using Address_t = std::uintptr_t;
//! Type alias for register and field addresses.
/**
* By design this type ensures that any address can be stored.
*/
using Address = std::uintptr_t;
//! Enumeration type for register size in bits.
/**
* This is used to enforce the supported register sizes.
*/
enum class RegBitSize {
b8, //!< 8-bit register.
b16, //!< 16-bit register.
b32, //!< 32-bit register.
b64 //!< 64-bit register.
};
//! Enumeration type for register size in bits.
/**
* This is used to enforce the supported register sizes.
*/
enum class RegBitSize : std::uint8_t {
b8, //!< 8-bit register.
b16, //!< 16-bit register.
b32, //!< 32-bit register.
b64 //!< 64-bit register.
};
//! Type alias field width.
using FieldWidth_t = std::uint8_t;
//! Type alias field width.
using FieldWidth = std::uint8_t;
//! Type alias for field offset.
using FieldOffset_t = std::uint8_t;
//! Type alias for field offset.
using FieldOffset = std::uint8_t;
//! Shorthand for max value as a mask.
/**
* @tparam T Data type.
*
* This is used to define register masks.
*/
template <typename T>
struct type_mask {
constexpr static const T value = std::numeric_limits<T>::max();
};
//! Shorthand for max value as a mask.
/**
* @tparam T Data type.
*
* This is used to define register masks.
*/
template <typename T>
struct type_mask {
constexpr static const T value = std::numeric_limits<T>::max();
};
}
} // namespace cppreg
#endif // CPPREG_CPPREG_DEFINES_H
#endif // CPPREG_CPPREG_DEFINES_H

4
cppreg_Includes.h

@ -2,7 +2,7 @@
/**
* @file cppreg_Defines.h
* @author Nicolas Clauvelin (nclauvelin@sendyne.com)
* @copyright Copyright 2010-2018 Sendyne Corp. All rights reserved.
* @copyright Copyright 2010-2019 Sendyne Corp. All rights reserved.
*/
@ -15,4 +15,4 @@
#include <tuple>
#endif // CPPREG_CPPREG_INCLUDES_H
#endif // CPPREG_CPPREG_INCLUDES_H

586
policies/AccessPolicy.h

@ -2,7 +2,7 @@
/**
* @file AccessPolicy.h
* @author Nicolas Clauvelin (nclauvelin@sendyne.com)
* @copyright Copyright 2010-2018 Sendyne Corp. All rights reserved.
* @copyright Copyright 2010-2019 Sendyne Corp. All rights reserved.
*
* Access policies are used to describe if register fields are read-write,
* read-only or write-only.
@ -14,7 +14,7 @@
* the register proper masking and shifting is required. The switch between
* trivial and non-trivial implementations is done automatically.
* - The write implementation also distinguishes between writing constant
* values (i.e., known at compile time) and non-constant value. This was
* values (i.e., known at compile time) and non-constant value. This is
* intended to make it possible to simplify operations at compile time and
* minimize overhead.
*/
@ -27,318 +27,288 @@
#include "cppreg_Defines.h"
//! cppreg namespace.
namespace cppreg {
//! Register read implementation.
//!@{ Trivial register read/write detector.
//! Boolean flag to detect trivial read/write.
/**
* @tparam T Register data type.
* @tparam mask Mask for the read operation.
* @tparam offset Offset for the read operation.
*/
template <typename T, T mask, FieldOffset offset>
struct is_trivial_rw
: std::integral_constant<bool,
(mask == type_mask<T>::value)
&& (offset == FieldOffset{0})> {};
//! Trivial read/write enable_if helper.
/**
* @tparam T Register data type.
* @tparam mask Mask for the read operation.
* @tparam offset Offset for the read operation.
* @tparam U Enabled type if trivial.
*/
template <typename T, T mask, FieldOffset offset, typename U>
using is_trivial =
typename std::enable_if<is_trivial_rw<T, mask, offset>::value, U>::type;
//! Non-trivial read/write enable_if helper.
/**
* @tparam T Register data type.
* @tparam mask Mask for the read operation.
* @tparam offset Offset for the read operation.
* @tparam U Enabled type if non-trivial.
*/
template <typename T, T mask, FieldOffset offset, typename U>
using is_not_trivial =
typename std::enable_if<!is_trivial_rw<T, mask, offset>::value, U>::type;
//!@}
//! Register read implementation.
/**
* @tparam MMIO Memory device type.
* @tparam T Register data type.
* @tparam mask Mask for the read operation.
* @tparam offset Offset for the read operation.
*/
template <typename MMIO, typename T, T mask, FieldOffset offset>
struct RegisterRead {
//! Non-trivial read implementation.
/**
* @param mmio_device Pointer to the register memory device.
* @return The content of the register field.
*/
template <typename U = void>
static T read(const MMIO& mmio_device,
is_not_trivial<T, mask, offset, U>* = nullptr) noexcept {
return static_cast<T>((mmio_device & mask) >> offset);
}
//! Trivial read implementation.
/**
* @tparam MMIO_t Memory device type.
* @tparam T Register data type.
* @tparam mask Mask for the read operation.
* @tparam offset Offset for the read operation.
*
* The mask and offset are used to define a specific field within the
* register.
* @param mmio_device Pointer to the register memory device.
* @return The content of the register field.
*/
template <typename MMIO_t, typename T, T mask, FieldOffset_t offset>
struct RegisterRead {
//! Boolean flag for trivial implementation.
/**
* The trivial corresponds to reading the whole register, that is,
* the mask is identity and the offset is zero.
*/
constexpr static const bool is_trivial =
(mask == type_mask<T>::value) && (offset == 0u);
//! Non-trivial read implementation.
/**
* @param mmio_device Pointer to the register memory device.
* @return The content of the register field.
*/
template <typename U = void>
static T read(
const MMIO_t& mmio_device,
typename std::enable_if<!is_trivial, U*>::type = nullptr
) noexcept {
return static_cast<T>((mmio_device & mask) >> offset);
};
//! Trivial read implementation.
/**
* @param mmio_device Pointer to the register memory device.
* @return The content of the register field.
*/
template <typename U = void>
static T read(
const MMIO_t& mmio_device,
typename std::enable_if<is_trivial, U*>::type = nullptr
) noexcept {
return static_cast<T>(mmio_device);
};
};
//! Register write implementation.
template <typename U = void>
static T read(const MMIO& mmio_device,
is_trivial<T, mask, offset, U>* = nullptr) noexcept {
return static_cast<T>(mmio_device);
}
};
//! Register write implementation.
/**
* @tparam MMIO Memory device type.
* @tparam T Register data type.
* @tparam mask Mask for the read operation.
* @tparam offset Offset for the read operation.
*/
template <typename MMIO, typename T, T mask, FieldOffset offset>
struct RegisterWrite {
//! Non-trivial write implementation.
/**
* @tparam MMIO_t Memory device type.
* @tparam T Register data type.
* @tparam mask Mask for the read operation.
* @tparam offset Offset for the read operation.
*
* The mask and offset are used to define a specific field within the
* register.
*
* This write implementation is used only when the value to be written is
* not a constant expression.
* @param mmio_device Pointer to the register memory device.
* @param value Value to be written to the register field.
*/
template <typename MMIO_t, typename T, T mask, FieldOffset_t offset>
struct RegisterWrite {
//! Boolean flag for trivial implementation.
/**
* The trivial corresponds to writing to the whole register, that is,
* the mask is identity and the offset is zero.
*/
constexpr static const bool is_trivial =
(mask == type_mask<T>::value) && (offset == 0u);
//! Non-trivial write implementation.
/**
* @param mmio_device Pointer to the register memory device.
* @param value Value to be written to the register field.
*/
template <typename U = void>
static void write(
MMIO_t& mmio_device,
T value,
typename std::enable_if<!is_trivial, U*>::type = nullptr
) noexcept {
mmio_device = static_cast<T>(
(mmio_device & ~mask) | ((value << offset) & mask)
);
};
//! Trivial write implementation.
/**
* @param mmio_device Pointer to the register memory device.
* @param value Value to be written to the register field.
*/
template <typename U = void>
static void write(
MMIO_t& mmio_device,
T value,
typename std::enable_if<is_trivial, U*>::type = nullptr
) noexcept {
mmio_device = value;
};
};
//! Register write constant implementation.
template <typename U = void>
static void write(MMIO& mmio_device,
T value,
is_not_trivial<T, mask, offset, U>* = nullptr) noexcept {
mmio_device =
static_cast<T>((mmio_device & ~mask) | ((value << offset) & mask));
}
//! Trivial write implementation.
/**
* @tparam MMIO_t Memory device type.
* @tparam T Register data type.
* @tparam mask Mask for the read operation.
* @tparam offset Offset for the read operation.
* @tparam value Value to be written to the register field.
*
* The mask and offset are used to define a specific field within the
* register.
*
* This write implementation is used only when the value to be written is
* a constant expression.
* @param mmio_device Pointer to the register memory device.
* @param value Value to be written to the register field.
*/
template <
typename MMIO_t, typename T, T mask, FieldOffset_t offset, T value
>
struct RegisterWriteConstant {
//! Boolean flag for trivial implementation.
/**
* The trivial corresponds to writing to the whole register, that is,
* the mask is identity and the offset is zero.
*/
constexpr static const bool is_trivial =
(mask == type_mask<T>::value) && (offset == 0u);
//! Non-trivial write implementation.
/**
* @param mmio_device Pointer to the register memory device.
*/
template <typename U = void>
static void write(
MMIO_t& mmio_device,
typename std::enable_if<!is_trivial, U*>::type = nullptr
) noexcept {
mmio_device = static_cast<T>(
(mmio_device & ~mask) | ((value << offset) & mask)
);
};
//! Trivial write implementation.
/**
* @param mmio_device Pointer to the register memory device.
*/
template <typename U = void>
static void write(
MMIO_t& mmio_device,
typename std::enable_if<is_trivial, U*>::type = nullptr
) noexcept {
mmio_device = value;
};
};
//! Read-only access policy.
struct read_only {
//! Read access implementation.
/**
* @tparam MMIO_t Register memory device type.
* @tparam T Field data type.
* @tparam mask Field mask.
* @tparam offset Field offset.
* @param mmio_device Pointer to register mapped memory.
* @return The value at the field location.
*/
template <typename MMIO_t, typename T, T mask, FieldOffset_t offset>
static T read(const MMIO_t& mmio_device) noexcept {
return RegisterRead<MMIO_t, T, mask, offset>::read(mmio_device);
};
};
//! Read-write access policy.
struct read_write : read_only {
//! Write access implementation.
/**
* @tparam MMIO_t Register memory device type.
* @tparam T Field data type.
* @tparam mask Field mask.
* @tparam offset Field offset.
* @param mmio_device Pointer to register mapped memory.
* @param value Value to be written at the field location.
*/
template <typename MMIO_t, typename T, T mask, FieldOffset_t offset>
static void write(MMIO_t& mmio_device,
const T value) noexcept {
RegisterWrite<MMIO_t, T, mask, offset>::write(mmio_device, value);
};
//! Write access implementation for constant value.
/**
* @tparam MMIO_t Register memory device type.
* @tparam T Field data type.
* @tparam mask Field mask.
* @tparam offset Field offset.
* @tparam value Value to be written at the field location.
* @param mmio_device Pointer to register mapped memory.
*/
template <
typename MMIO_t, typename T, T mask, FieldOffset_t offset, T value
>
static void write(MMIO_t& mmio_device) noexcept {
RegisterWriteConstant<MMIO_t, T, mask, offset, value>
::write(mmio_device);
};
//! Set field implementation.
/**
* @tparam T Field data type.
* @tparam mask Field mask.
* @param mmio_device Pointer to register mapped memory.
*/
template <typename MMIO_t, typename T, T mask>
static void set(MMIO_t& mmio_device)
noexcept {
RegisterWriteConstant<MMIO_t, T, mask, 0u, mask>
::write(mmio_device);
};
//! Clear field implementation.
/**
* @tparam MMIO_t Register memory device type.
* @tparam T Field data type.
* @tparam mask Field mask.
* @param mmio_device Pointer to register mapped memory.
*/
template <typename MMIO_t, typename T, T mask>
static void clear(MMIO_t& mmio_device)
noexcept {
RegisterWriteConstant<MMIO_t, T, mask, 0u, ~mask>
::write(mmio_device);
};
//! Toggle field implementation.
/**
* @tparam MMIO_t Register memory device type.
* @tparam T Field data type.
* @tparam mask Field mask.
* @param mmio_device Pointer to register mapped memory.
*/
template <typename MMIO_t, typename T, T mask>
static void toggle(MMIO_t& mmio_device)
noexcept {
mmio_device = static_cast<T>((mmio_device) ^ mask);
};
};
//! Write-only access policy.
struct write_only {
//! Write access implementation.
/**
* @tparam MMIO_t Register memory device type.
* @tparam T Field data type.
* @tparam mask Field mask.
* @tparam offset Field offset
* @param mmio_device Pointer to register mapped memory.
* @param value Value to be written at the field location.
*/
template <typename MMIO_t, typename T, T mask, FieldOffset_t offset>
static void write(MMIO_t& mmio_device, const T value) noexcept {
// For write-only fields we can only write to the whole register.
RegisterWrite<MMIO_t, T, type_mask<T>::value, 0u>::write(
mmio_device, ((value << offset) & mask)
);
};
//! Write access implementation for constant value.
/**
* @tparam MMIO_t Register memory device type.
* @tparam T Field data type.
* @tparam mask Field mask.
* @tparam offset Field offset
* @tparam value Value to be written at the field location.
* @param mmio_device Pointer to register mapped memory.
*/
template <
typename MMIO_t, typename T, T mask, FieldOffset_t offset, T value
>
static void write(MMIO_t& mmio_device) noexcept {
// For write-only fields we can only write to the whole register.
RegisterWriteConstant<
MMIO_t, T, type_mask<T>::value, 0u, ((value << offset) & mask)
>
::write(mmio_device);
};
};
}
#endif // CPPREG_ACCESSPOLICY_H
template <typename U = void>
static void write(MMIO& mmio_device,
T value,
is_trivial<T, mask, offset, U>* = nullptr) noexcept {
mmio_device = value;
}
};
//! Register write constant implementation.
/**
* @tparam MMIO Memory device type.
* @tparam T Register data type.
* @tparam mask Mask for the read operation.
* @tparam offset Offset for the read operation.
* @tparam value Value to be written to the register field.
*/
template <typename MMIO, typename T, T mask, FieldOffset offset, T value>
struct RegisterWriteConstant {
//! Non-trivial write implementation.
/**
* @param mmio_device Pointer to the register memory device.
*/
template <typename U = void>
static void write(MMIO& mmio_device,
is_not_trivial<T, mask, offset, U>* = nullptr) noexcept {
mmio_device =
static_cast<T>((mmio_device & ~mask) | ((value << offset) & mask));
}
//! Trivial write implementation.
/**
* @param mmio_device Pointer to the register memory device.
*/
template <typename U = void>
static void write(MMIO& mmio_device,
is_trivial<T, mask, offset, U>* = nullptr) noexcept {
mmio_device = value;
}
};
//! Read-only access policy.
struct read_only {
//! Read access implementation.
/**
* @tparam MMIO Register memory device type.
* @tparam T Field data type.
* @tparam mask Field mask.
* @tparam offset Field offset.
* @param mmio_device Pointer to register mapped memory.
* @return The value at the field location.
*/
template <typename MMIO, typename T, T mask, FieldOffset offset>
static T read(const MMIO& mmio_device) noexcept {
return RegisterRead<MMIO, T, mask, offset>::read(mmio_device);
}
};
//! Read-write access policy.
struct read_write : read_only {
//! Write access implementation.
/**
* @tparam MMIO Register memory device type.
* @tparam T Field data type.
* @tparam mask Field mask.
* @tparam offset Field offset.
* @param mmio_device Pointer to register mapped memory.
* @param value Value to be written at the field location.
*/
template <typename MMIO, typename T, T mask, FieldOffset offset>
static void write(MMIO& mmio_device, const T value) noexcept {
RegisterWrite<MMIO, T, mask, offset>::write(mmio_device, value);
}
//! Write access implementation for constant value.
/**
* @tparam MMIO Register memory device type.
* @tparam T Field data type.
* @tparam mask Field mask.
* @tparam offset Field offset.
* @tparam value Value to be written at the field location.
* @param mmio_device Pointer to register mapped memory.
*/
template <typename MMIO, typename T, T mask, FieldOffset offset, T value>
static void write(MMIO& mmio_device) noexcept {
RegisterWriteConstant<MMIO, T, mask, offset, value>::write(mmio_device);
}
//! Set field implementation.
/**
* @tparam T Field data type.
* @tparam mask Field mask.
* @param mmio_device Pointer to register mapped memory.
*/
template <typename MMIO, typename T, T mask>
static void set(MMIO& mmio_device) noexcept {
RegisterWriteConstant<MMIO, T, mask, FieldOffset{0}, mask>::write(
mmio_device);
}
//! Clear field implementation.
/**
* @tparam MMIO Register memory device type.
* @tparam T Field data type.
* @tparam mask Field mask.
* @param mmio_device Pointer to register mapped memory.
*/
template <typename MMIO, typename T, T mask>
static void clear(MMIO& mmio_device) noexcept {
RegisterWriteConstant<MMIO,
T,
mask,
FieldOffset{0},
static_cast<T>(~mask)>::write(mmio_device);
}
//! Toggle field implementation.
/**
* @tparam MMIO Register memory device type.
* @tparam T Field data type.
* @tparam mask Field mask.
* @param mmio_device Pointer to register mapped memory.
*/
template <typename MMIO, typename T, T mask>
static void toggle(MMIO& mmio_device) noexcept {
mmio_device = static_cast<T>((mmio_device) ^ mask);
}
};
//! Write-only access policy.
struct write_only {
//! Write access implementation.
/**
* @tparam MMIO Register memory device type.
* @tparam T Field data type.
* @tparam mask Field mask.
* @tparam offset Field offset
* @param mmio_device Pointer to register mapped memory.
* @param value Value to be written at the field location.
*/
template <typename MMIO, typename T, T mask, FieldOffset offset>
static void write(MMIO& mmio_device, const T value) noexcept {
// For write-only fields we can only write to the whole register.
RegisterWrite<MMIO, T, type_mask<T>::value, FieldOffset{0}>::write(
mmio_device, ((value << offset) & mask));
}
//! Write access implementation for constant value.
/**
* @tparam MMIO Register memory device type.
* @tparam T Field data type.
* @tparam mask Field mask.
* @tparam offset Field offset
* @tparam value Value to be written at the field location.
* @param mmio_device Pointer to register mapped memory.
*/
template <typename MMIO, typename T, T mask, FieldOffset offset, T value>
static void write(MMIO& mmio_device) noexcept {
// For write-only fields we can only write to the whole register.
RegisterWriteConstant<MMIO,
T,
type_mask<T>::value,
FieldOffset{0},
((value << offset) & mask)>::write(mmio_device);
}
};
} // namespace cppreg
#endif // CPPREG_ACCESSPOLICY_H

404
register/Field.h

@ -2,11 +2,11 @@
/**
* @file Field.h
* @author Nicolas Clauvelin (nclauvelin@sendyne.com)
* @copyright Copyright 2010-2018 Sendyne Corp. All rights reserved.
* @copyright Copyright 2010-2019 Sendyne Corp. All rights reserved.
*
* This header provides the definitions related to register field
* implementation.
* Strictly speaking a field is defined as a region of a register.
* implementation. Strictly speaking a field is defined as a region of a
* register.
*/
@ -14,225 +14,195 @@
#define CPPREG_REGISTERFIELD_H
#include "Register.h"
#include "Mask.h"
#include "AccessPolicy.h"
#include "ShadowValue.h"
#include "Internals.h"
#include "Mask.h"
//! cppreg namespace.
namespace cppreg {
//! Register field implementation.
//! Register field implementation.
/**
* @tparam BaseRegister Parent register.
* @tparam width Field width.
* @tparam offset Field offset.
* @tparam P Access policy type.
*
* This data structure provides static methods to deal with field access
* (read, write, set, clear, and toggle). These methods availability depends
* on the access policy (e.g., a read-only field does not implement a
* write method).
* In practice, fields are implemented by deriving from this class to
* create custom types.
*/
template <typename BaseRegister,
FieldWidth field_width,
FieldOffset field_offset,
typename AccessPolicy>
struct Field {
//! Parent register for the field.
using parent_register = BaseRegister;
//! Field data type derived from register data type.
using type = typename parent_register::type;
//! MMIO type.
using MMIO = typename parent_register::MMIO;
//! Field policy.
using policy = AccessPolicy;
//! Field width.
constexpr static auto width = field_width;
//! Field offset.
constexpr static auto offset = field_offset;
//! Field mask.
constexpr static auto mask = make_shifted_mask<type>(width, offset);
//!@{ Helpers for write method selection based on shadow value.
template <type value, typename T>
using if_no_shadow =
typename std::enable_if<!parent_register::shadow::value, T>::type;
template <type value, typename T>
using if_shadow =
typename std::enable_if<parent_register::shadow::value, T>::type;
//!@}
//!@ Field read method.
/**
* @tparam BaseRegister Parent register.
* @tparam width Field width.
* @tparam offset Field offset.
* @tparam P Access policy type.
*
* This data structure provides static methods to deal with field access
* (read, write, set, clear, and toggle). These methods availability depends
* on the access policy (e.g., a read-only field does not implement a
* write method).
* In practice, fields are implemented by deriving from this class to
* create custom types.
* @return Field value.
*/
template <
typename BaseRegister,
FieldWidth_t field_width,
FieldOffset_t field_offset,
typename AccessPolicy
>
struct Field {
//! Parent register for the field.
using parent_register = BaseRegister;
//! Field data type derived from register data type.
using type = typename parent_register::type;
//! MMIO type.
using MMIO_t = typename parent_register::MMIO_t;
//! Field policy.
using policy = AccessPolicy;
//! Field width.
constexpr static const FieldWidth_t width = field_width;
//! Field offset.
constexpr static const FieldOffset_t offset = field_offset;
//! Field mask.
constexpr static const type mask = make_shifted_mask<type>(width,
offset);
//! Boolean flag indicating if a shadow value is used.
constexpr static const bool has_shadow =
parent_register::shadow::value;
//! Customized overflow check implementation for Field types.
/**
* @tparam value Value to be checked for overflow.
* @return `true` if no overflow, `false` otherwise.
*
* This is only used for the template form of the write method.
*/
template <type value>
struct check_overflow : internals::check_overflow<
type,
value,
(mask >> offset)
> {};
//!@ Field read method.
/**
* @return Field value.
*/
static type read() noexcept {
return policy::template read<MMIO_t, type, mask, offset>(
parent_register::ro_mem_device()
);
};
//! Field write method (no shadow value).
/**
* @param value Value to be written to the field.
*/
template <typename T = type>
static void
write(const typename std::enable_if<!has_shadow, T>::type value)
noexcept {
policy::template write<MMIO_t, type, mask, offset>(
parent_register::rw_mem_device(),
value
);
};
//! Field write method (w/ shadow value).
/**
* @param value Value to be written to the field.
*/