Unmappable memory generator #17
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
|
Maybe not complete or full proof yet, but the idea and code seems to be working out for me. |
Moves the existing codegen into a mmio and makes it the default. The existing mmio generator is for mappable register maps where a simple pointer with offsets and infallible access is expected. Adds a new iface based generator for non-memory mappable register maps where access is expected to be fallible and require a simple read/write interface. The read/write register interface then provides all of the same kinds of functions that a typical regmap block generated by chiptool would have, with all functions being fallible. This enables generating regmaps from yaml files for peripheral chips on buses such as i2c or spi. No builtin notion of *how* th register map is accessible other than a simple read function given a register address and write function given an address and value are implementable by a driver. A driver using this for the WM8960 codec which requires some peculiar attributes was used to ensure the generated code was usable. This device in particular has some interesting quirks. The address size is 7 bits, the value size is 9 bits, and no reads are available over i2c for the device. Everything works as expected and the value/address container sizes are u8 and u16 as might be expected. Initial code was derived from the i2c branch Dario Nieuwenhuis had created for chiptool likely for the same goal. Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
SpinFast
force-pushed
the
unmappable_gen
branch
from
f1f8689
to
3a644f6
Compare
|
@Dirbaio I'm waiting on this to publish my wm8960 crate, it would be great if this could be added and rolled into a new released version of chiptool wm8960-rs is working well for me |
|
I've done almost the same experiments like this. https://github.com/embedded-drivers/yaml2pac https://github.com/embedded-drivers/edrv-uart/blob/main/uart_dw_apb.yaml I was thinking something like: IMHO, it is better to keep chiptool as it is for generating MCU register blocks.(introducing unused field is no meaning to metapac crates). |
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.
Adds a custom generator for interface based (unmappable memory) register manipulation.
Based on the i2c branch adds a interface based regblock where the interface is expected to provide a simple single register read/write fallible function pair.
Every register then can be written, read, modified similarly to how chiptool does things for mappable memory regions.
I'm testing this out in conjunction with a driver for the WM8960 on many imxrt boards
https://github.com/spinfast/wm8960-rs