esp-rs / esp32 Goto Github PK

Peripheral access crate for the ESP32

License: Apache License 2.0

Makefile 46.33% Rust 53.67%

esp32's Introduction

esp32

A peripheral access crate the ESP32. See the svd2rust repo for more infomation on how to use this crate. Espressif do not provide an SVD for the esp32, so the svd used in this project has been generated from the C header documentation via the idf2svd tool.

Join in on the discussion: https://matrix.to/#/#esp-rs:matrix.org!

`Documentation`

Building

Required dependencies:

form
svd
svd2rust - NOTE: Currently requires a svd2rust with this PR included: rust-embedded/svd2rust#536

$ make

Submitting new patches

The base svd file created from idf2svd should not be edited. Instead the svd is manipulated through the svdtools patching tool.

See svd and stm32-rs yaml format for more infomation on the patching format

License

Licensed under either of

Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

esp32's People

Contributors

Stargazers

Watchers

Forkers

jeandudey harkonenbade arjanmels yonasj aykevl omegasystem kelnos dreistein kerryrj cloudinnovates bjoernq sulami

esp32's Issues

Importing interrupt information

Related idf2svd issue: MabezDev/idf2svd#5

Nothing here :)

There's an esp32-sys crate in the esp32 quickstart repo here:
https://github.com/lexxvir/esp32-hello

I made a fork containing just the esp32-sys crate here:
https://github.com/sapir/esp32-sys

I propose to use it, at least as the basis for any further work.

Remove duplicate peripherals

Many of the generated (in particular the indexed ones) need to be manually derived.

This is achieved in svdpatch here

When the peripherals are copied it leaves behind the base peripheral, we should remove these.

Example:

In https://docs.rs/esp32/0.2.1/esp32/#structs for example, there is I2C0, I2C1 and I2C, the latter being the base peripherals that we derive the other two from. In this instance we should remove I2C.

Bitfield stripping is broken on indexed peripherals

Seems like #14 has unfortunately & subtley broken the code gen for indexed registers.

SVD addressBlock usage

https://github.com/rust-embedded/svd2rust/runs/3799394000?check_suite_focus=true

The following predefined values can be used:

    registers
    buffer
    reserved.

https://www.keil.com/pack/doc/CMSIS/SVD/html/elem_peripherals.html#elem_addressBlock

Remove prefixes on register names

A consequence of parsing from the idf codebase is that many of the register names are uselessly prefixed by the name of the peripheral, e.g https://github.com/esp-rs/esp32/blob/master/src/i2c.rs#L5

Svdtool should be able to patch this.

Split GPIO registers into named bit fields

Would be nice to have a nicer api instead of manually bit shifting, e.g

Replace

gpio_reg_x.write(|w| unsafe { w.bits(0x1 << 0) });

With, or similar

gpio_reg_x.write(|w| w.gpio0().set_bit())

Espressif SVD question

I see that there is an SVD repo in the Espressif org.

There is currently no Esp32 SVD and I am wondering if the initial SVD is going to be auto generated and then manually maintained or is there an alternate mechanism that will be used?

I have compiled an Esp32 SVD (compatible with CMSIS SVD 1.3) using the one in this repository, Esp-IDF 4.4 header files and the latest available Espressif technical reference manual. Svd2rust does not handle all the 1.3 features. I was thinking of preferably updating this SVD, or updating the existing YAML files.

I am wondering if it worth the time and effort if the SVD in this repo is going to be superseded by one from the Espressif/SVD repo?

stm32-rs does it this way, only generating the code on releases or on ci runs.