ryankurte
commented
6 years ago I like the idea of moving components into rust-embedded (and increasing the bus factor with that org 😂).
I'd like to see a code of conduct (something line the contributor covenant and the contacts and policy to support it, as well as contribution guidelines (ie. how to pr, policy on breaking changes and versioning, adoption of projects by rust-embedded etc.) at the org level.
Also willing to pick up some of rust2svd/svd-rs(/embedded-hal) development/support/maintenance, and to update japaric/svd#37 to get it merged as a first step in the refactor if that's useful.
dylanmckay
hannobraun
docbrown
dvc94ch
Emilgardis
japaric
scowcron
kunerd
jamesmunns
rahul-thakoor
therealprof
ghost
musitdev
posborne
andre-richter
berkus
pftbest
rudihorn
korken89
A.K.A. @japaric is a bottleneck for development :-)
There are critical components of the embedded / Cortex-M ecosystem that are currently being maintained by me. Unfortunately I don't have the bandwidth to keep up with everything so issues and PRs have been piling up in some repos.
This issue is a call for maintainers (if you want to help leave a comment!) and a place to discuss how to organize maintainership duties.
First, these are the crates that should be maintained by more people:
embedded-halAbstractions for things like Serial, SPI, I2C, etc. to build generic drivers that work with AVR, ARM Cortex-M, MSP430, RISCV, etc. microcontrollers.
There's a bunch to do here as some abstractions are missing and async support is currently nonexistent. Most of the work to do here is ensuring that the established process for adding new traits is followed and that discussions move towards consensus.
Quite a few people have volunteered to help and are now collaborators so I think this one is well covered for now.
svd2rustTool used to transform CMSIS SVD files (XML files that describe the hardware registers of a device) into code for low level manipulation of hardware registers. Although the SVD spec was created by ARM
svd2rustis being used for both ARM Cortex-M and MSP430 devices. In the later case TI provides DSLite files (their version of SVD files) and those are converted to SVD files using the dslite2svd tool.It's expected that
svd2rustwill also grow AVR support -- Atmel has its own description file format: atdf -- using the atdf2svd approach. And there are XSVD (JSON version of SVD files) files for RISCV -- I don't think they are official though? -- sosvd2rustcould also grow support for RISCV via a xsvd2svd tool.Unfortunately
svd2rusthas grown into an unmaintainable mess. The test suite takes a lot of time to run (it takes longer than the CI limit) and it only checks if the generated code still compiles -- it provides no feedback about whether the generated code exposes a certain interface or not. The underlying parser lacks error handling and simply panics on errors. Also,svd2rustdoesn't give you helpful error messages when your SVD file has some problem -- this is an important feature to have when manually editing SVD files.So both
svd2rustand the underlyingsvdparser need to be refactor (read: rewritten) to make them more modular and testable. I think the approach to take here is a refactor like the one proposed in japaric/svd#37. Basically we should be able to test code generation on parts of a SVD file. For example that<enumeratedValues>..</enumeratedValues>produces thisenum Foo { .. }and this APIimpl Foo { fn is_variant(&self) -> bool { .. } }, etc. This will let us write unit tests that can replace the huge existing tests that only check for compilation errors. And while you are at it you can add error handling to the parser and nice error messages tosvd2rust.This is a huge task but it will make it easier to continue the development of
svd2rust. There a bunch of open issues related to SVD files not being supported; the refactor should make it easier to fix those issues.If you want to tackle this let me know in the comments!
Then we have core
cortex-mcrates.cortex-mThis repo provides access to Cortex-M specific features like access to registers, safe wrappers around assembly instructions and access to core peripherals.
One old issue in this repo is providing a
svd2rustgenerated API to access the core peripherals. The current API has been manually written and is not as type safe as asvd2rustone would be. Fixing this requires writing or putting together an SVD file that contains only core peripherals, runningsvd2rustover it and committing the code to thecortex-mrepo.cortex-m-rtThis crate takes care of communicating the memory layout of a program to the linker and providing implementations of language items that are required to build a
no_stdprogram.There are a few missing features in this crate: support for placing functions / interrupt handlers / the whole program in RAM, relocation of the vector table, etc. that need a design. It may be useful to coordinate with the representatives of the other embedded targets to see if we can provide a similar user interface for these features.
cortex-m-quickstartThis crate is used as a Cargo project template for writing Cortex-M applications.
Every now and then a user figures a new way to misfollow the instructions and encounters a new error message. These errors should be documented in the troubleshooting guide.
Regarding organization I think it may make sense to move these core components under the rust-embedded org and then create, say, a cortex-m team in charge of maintaining the cortex-m crates. As the AVR, MSP430 and RISCV communities grow they may also want to move core components into the rust-embedded org and create their own maintainer teams. Thoughts on this?
cc @ryankurte @Emilgardis might be interested in picking up svd2rust development cc @dylanmckay (AVR) @pftbest (MSP430) @dvc94ch (RISCV) see last paragraph, also
svd2rustsupport