pin and irq operations affect the entire pio block. with pins this is
not very problematic since pins themselves are resources, but irqs are
not treated like that and can thus interfere across state machines. the
ability to wait for an irq on a state machine is kept to make
synchronization with user code easier, and since we can't inspect loaded
programs at build time we wouldn't gain much from disallowing waits from
state machines anyway.
- probe-run screwed up the last release 2 weeks ago and it's still not fixed (issue 391). Doesn't look well maintained.
- Even when it's not broken, it lags behind probe-rs-cli in new chips support because it's slow in updating probe-rs.
1379: enable inline-asm feature for cortex-m in examples r=Dirbaio a=pennae
inline assembly is supported since rust 1.59, we're way past that. enabling this makes the compiled code more compact, and on rp2040 even decreses memory usage by not needing thunks in sram.
Co-authored-by: pennae <github@quasiparticle.net>
inline assembly is supported since rust 1.59, we're way past that.
enabling this makes the compiled code more compact, and on rp2040
even decreses memory usage by not needing thunks in sram.
1369: Lora AFIT r=Dirbaio a=Dirbaio
Extracted out of #1367
Probably we should wait until `rust-lorawan` is merged+released?
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
1371: RTC r=Dirbaio a=xoviat
This adds RTC for most of the stm32 chips. Nearly all of the work was not done by me, but I took it the last bit by disabling the chips that weren't working. I think it would be easier to enable them in future PRs if requested.
1374: stm32: remove TIMX singleton when used on timer driver r=Dirbaio a=xoviat
After multiple ways of looking at this, this is the best solution I could think of.
Co-authored-by: Mathias <mk@blackbird.online>
Co-authored-by: xoviat <xoviat@users.noreply.github.com>
1330: stm32/pwm: add complementary pwm r=Dirbaio a=xoviat
This implements complementary PWM with dead time on many supported targets. The specific dead-time programming functions are passed through directly to the user, which is a bit ugly but the best compromise I could reach for now.
Co-authored-by: xoviat <xoviat@users.noreply.github.com>
1333: STM32: Adc V1 r=Dirbaio a=GrantM11235
Based on #947
Co-authored-by: Matthew W. Samsonoff <matt.samsonoff@gmail.com>
Co-authored-by: Grant Miller <GrantM11235@gmail.com>
1321: executor: add Pender, rework Cargo features. r=Dirbaio a=Dirbaio
This introduces a `Pender` struct with enum cases for thread-mode, interrupt-mode and
custom callback executors. This avoids calls through function pointers when using only
the thread or interrupt executors. Faster, and friendlier to `cargo-call-stack`.
`embassy-executor` now has `arch-xxx` Cargo features to select the arch and to enable
the builtin executors (thread and interrupt).
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
1313: (embassy-stm32): rework bufferedUart to get rid of PeripheralMutex r=Dirbaio a=MathiasKoch
New implementation is very similar to the implementation of embassy-nrf & embassy-rp.
Also adds embedded-hal traits to bufferedUart.
**NB**: Still needs testing on actual hardware
Co-authored-by: Mathias <mk@blackbird.online>
This introduces a `Pender` struct with enum cases for thread-mode, interrupt-mode and
custom callback executors. This avoids calls through function pointers when using only
the thread or interrupt executors. Faster, and friendlier to `cargo-call-stack`.
`embassy-executor` now has `arch-xxx` Cargo features to select the arch and to enable
the builtin executors (thread and interrupt).
This example also uses a pio program compiled at runtime, rather than one built at compile time. There's no reason to do that, but it's probably useful to have an example that does this as well.
> dirbaio: so I was checking how zephyr does UARTE RX on nRF
> dirbaio: because currently we have the ugly "restart DMA on line idle to flush it" hack
> dirbaio: because according to the docs "For each byte received over the RXD line, an RXDRDY event will be generated. This event is likely to occur before the corresponding data has been transferred to Data RAM."
> dirbaio: so as I understood it, the only way to guarantee the data is actually transferred to RAM is to stop+restart DMA
> dirbaio: well, guess what?
> dirbaio: they just count RXDRDY's, and process that amount of data without restarting DMA
> dirbaio: with a timer configured as counter https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/serial/uart_nrfx_uarte.c#L650-L692
> dirbaio: 🤔🤷⁉️
> dirbaio: someone saying you can do the "hook up rxdrdy to a counter" trick, someone else saying it's wrong 🤪https://devzone.nordicsemi.com/f/nordic-q-a/28420/uarte-in-circular-mode
So we're going to do just that!
- BufferedUarte is lock-free now. No PeripheralMutex.
- The "restart DMA on line idle to flush it" hack is GONE. This means
- It'll work correctly without RTS/CTS now.
- It'll have better throughput when using RTS/CTS.
The UARTETWISPIn naming is quite horrible. With the nRF53, Nordic realized this
and renamed the interrupts to SERIALn. Let's copy that for our peripheral names, in nrf53 and nrf91.
They're used to communicate from the app to ST's OTA bootloader. See AN5247.
This bootloader is optional, must be flashed by the user, and requires changing the FLASH start address as well, so the current memory regions still require modifications to use it. Therefore there's no point in reserving these words.
Thanks @adamgreig for investigating the purpose.
1218: Lora: sx126x: Change timing window to match values found experimentally. r=Dirbaio a=CBJamo
As mentioned in #1188.
1219: stm32/sdmmc: Fix SDIOv1 writes r=Dirbaio a=chemicstry
This fixes writes on sdmmc v1 (SDIO). I'm pretty sure I tested writes in #669, but maybe I was just lucky or I just forgot.
There were two problems:
- Writes require DMA FIFO mode, otherwise SDIO FIFO is under/overrun depending on sdio/pclk2 clock ratio.
- Hardware flow control is broken for sdmmc v1 (I checked F1 and F4 erratas). This causes clock glitches above 12 MHz and results in write CRC errors.
Co-authored-by: Caleb Jamison <caleb@cbjamo.com>
Co-authored-by: chemicstry <chemicstry@gmail.com>
1217: Fix a typo in "PioPeripheral" r=Dirbaio a=SekoiaTree
Renames "PioPeripherial" to "PioPeripheral" (without the second i).
Co-authored-by: sekoia <sequoia.1009@gmail.com>
- Allows classes to handle vendor requests.
- Allows classes to use a single handler for multiple interfaces.
- Allows classes to access the other events (previously only `reset` was available).
This brings it inline with the other embassy-usb descriptor APIs and allows it to integrate well with the Builder to allow class constructors to add MS OS descriptors.
Also adds a `usb_serial_winusb` example to demonstrate how to use the API.
1173: nRF examples crates names r=lulf a=davidedellagiustina
Fixed nRF examples crates' names: they had the same names and they were conflicting during compilation (Cargo warning).
1174: add missing copy of icmpv6 checksum r=lulf a=lulf
add proto-ipv6 feature to stm32h7 example to catch issues in CI
Co-authored-by: Davide Della Giustina <davide@dellagiustina.com>
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
1142: More rp2040 BufferedUart fixes r=Dirbaio a=timokroeger
* Refactor init code
* Make it possible to drop RX without breaking TX (or vice versa)
* Correctly handle RX buffer full scenario
Co-authored-by: Timo Kröger <timokroeger93@gmail.com>
1147: Support codesigning in the firmware updater r=lulf a=huntc
This PR provides a method to verify that firmware has been SHA-512 hashed and signed with a private key given its public key. The implementation provides both [`ed25519-dalek`](https://github.com/dalek-cryptography/ed25519-dalek/blob/main/Cargo.toml) and [`salty`](https://github.com/ycrypto/salty) as the signature verifiers. Either of the `ed25519-dalek` and `ed25519-salty` features is required to enable the functionality from `embassy-boot`.
The `verify_and_mark_updated` method is used in place of `mark_updated` when signing is used via its feature. This avoids the accidental omission of validation where it has been declared as required at compile time. It also keeps the parity of calls at the same number to the previous situation.
The PR permits other types of signature verifiers in the future on the proviso that the [Signature trait](https://github.com/RustCrypto/traits/tree/master/signature) is supported.
Finally, I've updated the CI to include testing `embassy-boot`, which it was doing before. In addition, I've included a unit test for verification based on a `ed25519-dalek` documentation example. This tests both the `dalek` and `salty` implementations.
In terms of code size comparisons, `dalek` adds about 68KiB and `salty` adds about 20KiB. I'm using `salty` myself. I've also tested this out by signing my code with the OpenBSD `signify` utility and then verify it during firmware upload using `salty`.
Co-authored-by: huntc <huntchr@gmail.com>
This commit provides a method to verify that firmware has been signed with a private key given its public key. The implementation uses ed25519-dalek as the signature verifier. An "ed25519" feature is required to enable the functionality. When disabled (the default), calling the firmware updater's verify method will return a failure.
1141: feat: compile bootloader examples for nRF91 r=lulf a=lulf
* Add nRF91 as target in CI builds
* Add example linker scripts for nrf91
* Make less nRF52 assumptions example config
* Add llvm-tools-preview required for cargo objcopy example
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
* Add nRF91 as target in CI builds
* Add example linker scripts for nrf91
* Make less nRF52 assumptions example config
* Add llvm-tools-preview required for cargo objcopy example
1139: Wdt config changes r=lulf a=huntc
Per commits:
* By passing WDT config around we can control it more easily and promote sharing it between files.
* The memory layout of the s140 crept into a number of memory files, which can cause confusion (well, it did for me!).
* Obtaining the current WDT config is useful so that we do not have to duplicate configurations around the place. A constructor method has been introduced that attempts to return the current running WDT config from the WDT peripheral. The bootloader example has also been updated to show how the watchdog can be obtained and used.
Co-authored-by: huntc <huntchr@gmail.com>
Obtaining the current WDT config is important so that we do not have to duplication configuration around the place. A constructor method has been introduced that returns WDT config in accordance with how the register is presently configured. The bootloader example has also been updated to show the watchdog can be obtained and used.
1093: Add random example r=Dirbaio a=miathedev
Thanks Lulf for the help!
This should be added as example so other people can look it up easily.
With love,
Mia
1127: clean up doc comment generation r=Dirbaio a=Weshnaw
I noticed that when I created doc comments for my tasks that the doc comments got included on the inner function but not the outer functions, I personally prefer keeping the documentation as clean as possible so this PR aims to hide the inner function and then add doc comments to the outer function.
The actual changes include:
* adding #[doc(hidden)] onto the `task_inner` function
* I flip flopped on this one because I could imagine someone may want this in their docs, but decided to include but I think arguments could be made either way
* copy the attributes from `task_inner` to `task_outer`
* I don't work with proc_macros often so I am not entirely sure if the way I went about it is correct but it seems to work fine
* specifically: using `parse_quote` to create the `task_outer` as a `ItemFn` then duplicating the attributes from `task_inner` to `task_outer`
* I also am not sure if it's a good idea to duplicate all attributes over, but I honestly wasn't sure how to just get the just doc comment attributes
Co-authored-by: miathedev <mia@metzler.systems>
Co-authored-by: Brendon Fallquist <bfallquist@gmail.com>
modify RP2040 adc example to get inside biased bipolar diode voltage,
then convert this temperature sensor data into Celsius degree,
according to chapter 4.9.5. Temperature Sensor in RP2040 datasheet.
The eth code is always built and available, but has no own API (other
than the embassy-net Device impl) to rx/tx packets. We could add this
API in the future, so the feature only means "embassy-net support".
1043: Rpi Pico PIO driver r=Dirbaio a=fluffware
This is a driver for the two PIOs in the Pico. I've tried using the type system to get as much compile time checks as possible. There is asynchronous support for FIFOs an Irqs. No DMA support yet. There's an example that shows how to use the driver asynchronously.
1103: embassy-stm32: add rs485 driver enable to uart r=Dirbaio a=FrozenDroid
Co-authored-by: Simon Berg <ksb@fluffware.se>
Co-authored-by: Vincent Stakenburg <v.stakenburg@sinewave.nl>
1089: feat: embassy-boot for rp2040 r=Dirbaio a=lulf
Add embassy-boot support for RP2040, with examples for the Raspberry Pi Pico.
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
1074: Added blinky example for stm32f0 r=lulf a=imrank03
Hi, I have added **blinky** example for `stm32f0` and tested with Nucleo board `STM32F091RC`.
- Can I add more example for stm32f0?
Co-authored-by: @imrank03 <immu0396@gmail.com>
