Device Tree Support #15
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Draft
d3zd3z
force-pushed
the
dt
branch
2 times, most recently
from
d4754e1
to
c15b549
Compare
d3zd3z
force-pushed
the
kobj
branch
4 times, most recently
from
aa1e082
to
d78650f
Compare
d3zd3z
force-pushed
the
dt
branch
2 times, most recently
from
9fb4c7b
to
9f25f08
Compare
Fix a few warnings that have crept into the code when building without allocation. Signed-off-by: David Brown <[email protected]>
Allow clients to use the Rust `log` crate for logging, and provide a `zephyr::set_logger()` that will send those message to printk. This is used when Zephyr's logging is either disable, or enabled, and configured to use minimal logging. Signed-off-by: David Brown <[email protected]>
Change the hello world sample to use Rust's logging mechanism. This is configured to not enable logging in Zephyr, so the output will go to the same printk mechanism it went to before. Signed-off-by: David Brown <[email protected]>
Implement a simplistic mechanism that is able to log through Zephyr's logging mechanism. This change does not attempt to demangle the #define nightmare that is Zephyr's logging, but just formats to a string, and sends that directly through a C helper function. As such, this performs at least one allocation/free, possibly with some reallocs, depending on how accurate the allocation estimate is, and whether adding a null terminator requires an additional allocation. Logs are also all recorded under a single registered log, in the rust main file. Signed-off-by: David Brown <[email protected]>
Change this app to use full logging in Zephyr. This requires a larger stack, and at least for now, we disable the RTT logging, as the logging seems to get confused if more than one back end is present. Signed-off-by: David Brown <[email protected]>
Match the conditionals of the Rust code needing the log wrappers in C code, so that this is not brought in if there is no logging support enabled in Zephyr. Signed-off-by: David Brown <[email protected]>
This code parses the DTS file generated by the Zephyr build, along with a few entries from the generated header file, to build a representation of the device tree. There is a notion of "augments" that add various methods. This is currently just hard-coded. Signed-off-by: David Brown <[email protected]>
Blinky is a rust port of the samples/blinky application from the main zephyr repo. It performs the same function, but using the DT and GPIO abstractions provided in the zephyr::sys module. Signed-off-by: David Brown <[email protected]>
Create two modules with wrappers for Zephyr gpio and flash devices. These have no methods, but allow the DT generated code to compile, with `get_instance` methods that return these values. Signed-off-by: David Brown <[email protected]>
The is_ready method on both `Gpio` and `GpioPin` will ultimately call the underlying `device_is_ready` entry. Signed-off-by: David Brown <[email protected]>
Create wrappers for config and pin toggle on the gpios. This is enough to allow the blink app to work. Signed-off-by: David Brown <[email protected]>
Move the module declaration for the device tree up into `lib.rs` to allow insertion of allow directives to eliminate documentation warnings on the generated devicetree. Signed-off-by: David Brown <[email protected]>
Fix doc build errors by filling in missing documentation comments. Signed-off-by: David Brown <[email protected]>
Instead of hardcoding all of the augments in the code, put these augments into a data structure. Load the actual rules from a yaml file (with a future ability to extend this with per-app or per-module defined augments. Convert all of the existing hardcoded augment rules into the initial augment file.
Add constructors to the individual device types. These are unsafe, and are all referenced from the generated devicetree code.
Move all of the device implementations into a `zephyr::device` module. In this module, add a `Unique` type that supports the constructors on the device requiring a unique instance. The device tree augmentation code adds a declaration for these uniqueness markers for each instance, passing it into the constructor. Signed-off-by: David Brown <[email protected]>
Gpios in Zephyr are inherently unsafe. There is a shared controller that is not just used by the pins defined here, but extensively across various drivers. As such, make all of the gpio pin operations themselves unsafe. We can help, a little bit, to at least enforce uniqueness with the Rust drivers that use gpios by requiring them to take a mutable instance of `GpioToken`, which has a singleton getter. Signed-off-by: David Brown <[email protected]>
Signed-off-by: David Brown <[email protected]>
The hard-coded augments in augment.rs are no long used, so remove them all, and move the config version into this file to avoid needing a separate module, just for the trait. Signed-off-by: David Brown <[email protected]>
Generate a full list of nodes that are present in the given device tree,
and provide a tool that build.rs in the app can use to make these
active. This will allow conditionals like:
#[cfg(dt = "aliases::led")]
to be used, which will make it possible to handle nodes being present or
not in the DTS.
See a subsequent patch to the blinky sample for an example of usage.
Signed-off-by: David Brown <[email protected]>
Show how an application can be conditional based on the presence of a node in the devicetree. Signed-off-by: David Brown <[email protected]>
Move this code out of the device.rs file, and into separate files for each module. Signed-off-by: David Brown <[email protected]>
The gpio device tree entries for the mps2 are defined with a `#gpio-cells` value of 1, despite these values not being interpreted by the driver, but by the devicetree code. I'm not sure if these actually work with any of the demos, as it is unclear what the macros would do with this. It doesn't give us a value to use for dt_flags. If someone wants to put in some effort to fix this, feel free. But I don't think the problem is on the Rust side. Signed-off-by: David Brown <[email protected]>
Prevents a warning on boards where there are no gpios or flash controllers are defined. Signed-off-by: David Brown <[email protected]>
This allows a build on the nrf51, preventing an error when the partitions are detected, but the controller wasn't. Signed-off-by: David Brown <[email protected]>
This fixes a weird issue with bindgen missing the `__device_dts_ord_nn` declarations in some circumstances. It is unclear when this was occuring, and hopefully it doesn't return at some point. Signed-off-by: David Brown <[email protected]>
Instead of trying to hand off data through a file between the build of different crates, which was causing build failures in applications that need to use cfgs based on the presence of DT nodes, instead, just parse the DT again, and recalculate the node tree from it. This should fix build issues with the all nodes txt file missing. Signed-off-by: David Brown <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Built on top of #5, this adds support for the devicetree.
This is definitely a WIP (hence draft), but shows the basics of generating the devicetree.