985: Create Sx126X LORA driver r=lulf a=ceekdee
Implementation features:
- update embassy-lora to support Semtech SX126X chips, specifically the RAK4631 chip (nrf52480 and sx1262).
- support additional SX126X packages by adding a feature (reference feature rak4631) and updating the board specific Rust file. To enable feature rak4631, settings.json must currently enable "rust-analyzer.linkedProjects" for "examples/nrf/Cargo.toml".
- provide tx/rx examples in examples/nrf to show compatibility with the interface provided by the SX127X LORA implementation.
Only LORA P2P communication has been tested. Implementation lines marked with ??? indicate areas for further investigation. Furthermore, I question whether the DIO1 handler is adequate for catching all interrupt sequences.
This implementation is patterned after the C/C++ implementation provided by Semtech, available through the RAK-nRF52-RUI developers platform.
Co-authored-by: ceekdee <taigatensor@gmail.com>
Co-authored-by: Chuck Davis <91165799+ceekdee@users.noreply.github.com>
1004: Fix internal channels for adc v2 r=lulf a=chemicstry
Internal channel reading was broken on adc_v2, because `Adc::read()` requires gpio pin trait, which was not implemented by `VrefInt`, `Temperature`, `Vbat`. The required configuration bits `tsvrefe`, `vbate` were not enabled either. This PR makes it a bit closer to how adc_v4 works.
While at it, I also changed adc_v2 to use `RccPeripheral` instead of permanently enabling all ADCs.
Co-authored-by: chemicstry <chemicstry@gmail.com>
1003: all Cargo.toml: Add license to all crate Cargo.toml files r=lulf a=chrysn
This sets the license to "MIT OR Apache-2.0" in a machine readable form on all crates, as it was already in human readable form in the README.md file, and reaffirmed in #1002.
(The statements on all the individual examples might not be strictly essential for the `cargo deny` use case as they are leaf crates, but other tools might use that information).
Co-authored-by: chrysn <chrysn@fsfe.org>
1000: Forgot to add space function to immediate publisher r=lulf a=diondokter
Title says it all really. This function was added to the normal publisher, so now also to the immediate publisher
Co-authored-by: Dion Dokter <dion@tweedegolf.com>
996: Add required info to embassy-sync package r=Dirbaio a=lulf
Updates the README.md based on embassy-futures structure.
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
993: rp i2c: blocking example r=Dirbaio a=jsgf
i2c example talking to mcp23017 i2c gpio expander.
Co-authored-by: Jeremy Fitzhardinge <jeremy@goop.org>
992: (embassy-stm32): remove flash lock/unlock public API from stm32 flash r=lulf a=MathiasKoch
Instead, perform the unlocking and locking automatically on erase and write operations.
This makes the `embedded-storage` abstraction actually useable in libraries, while still keeping the flash peripheral locked the majority of the time.
Co-authored-by: Mathias <mk@blackbird.online>
991: usb: remove all "Direction as u8" casts. r=Dirbaio a=Dirbaio
Alternative fix for #989 , see comment there for rationale.
bors r+
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
990: Small pubsub improvements r=Dirbaio a=diondokter
- Futures in pub & sub are now awaited instead of returned
- Added functions for reading how many messages are available
This helps people get better compiler diagnostics. For example, I forgot to call await on a future and the compiler didn't complain.
This also helps with making some decisions based on the state of the channels.
Co-authored-by: Dion Dokter <dion@tweedegolf.com>
914: (embassy-rp): Add I2C master implementation r=Dirbaio a=MathiasKoch
This PR adds both blocking and DMA based async implementations of I2C master.
Both E-H 0.2 & E-H 1.0 abstractions are implemented as well.
### Questions & concerns:
- Do we need an I2C interrupt handler (for transfer done, abort & error handling?) (async only)
- Do we need to add some automatic attempt at unblocking an I2C bus in case of failures (see ref: 7ebfd553f3/src/i2c_dma.c (L116-L142))
- Should I add `vectored_{read, write}` implementations?
Co-authored-by: Mathias <mk@blackbird.online>
Co-authored-by: Mathias Koch <mk@blackbird.online>
