1209: Time: Add from_hz function for Duration. r=Dirbaio a=CBJamo
I found myself doing things like this
```rust
let rate_us = 1_000_000 / rate_hz;
let mut ticker = Ticker::every(Duration::from_micros(rate_us));
```
Several times, and figured it was worth adding a little convenience function to handle that. This also makes the calculation const, which is a nice little upside. The compiler might have been doing that already, but this makes sure.
Speaking of const, would it be better to give hz as a float? Obviously we'd want to avoid that at runtime since many targets don't have a fpu, but if it's at compile time that doesn't matter and a float may be more ergonomic.
Co-authored-by: Caleb Jamison <caleb@cbjamo.com>
1205: stm32/rng Fix rng generation lock-up r=Dirbaio a=lucasgranberg
This PR fixes a problem where the device gets locked in case of rng errors.
The PR also includes a hack for stm32wl based devices where the more complicated RNG peripheral can get stuck on seed errors.
Co-authored-by: Lucas Granberg <lukkeg@gmail.com>
1203: usb: unify ControlHandler+DeviceStateHandler, route all control requests to all handlers. r=Dirbaio a=Dirbaio
depends on #1202
- Allows classes to handle vendor requests. (fixes#1078)
- Allows classes to use a single handler for multiple interfaces.
- Allows classes to access the other events (previously only `reset` was available).
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
- 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).
1200: feat(stm32): Add 16 data bit fmc ctor r=Dirbaio a=rmja
This has been validated with the Is42s16400j sdram on stm32f429.
Co-authored-by: Rasmus Melchior Jacobsen <rmja@laesoe.org>
1199: STM32 SPI: Set clk-pin pull-up/-down to match spi clock polarity r=Dirbaio a=jr-oss
Fixes#1094
There are some proposed solutions in #1094
> Keep the DMA transaction open across calls to read/write
This may be problematic if the user changes bus settings between calls, and also the reference manual says the chip should not be placed into low power mode while SPI is enabled
As already described, this is problematic and against reference manual recommendation
> Set the CLK (and maybe MOSI) pins as pull-down on setup (or pull-up, depending on config - and this would need to be updated if the user modified the config)
This is less good than driving the pin to the correct value, but may be better than nothing
That is also my preferred solution. See below citation from reference manual.
> Document this and require users fix it themselves (add a pull-up/down resistor - or configure the pins as pull-up/pull-down before passing them into SPI setup)
Setting internal pull-up/-down won't work, because `sck.set_as_af()` will change the gpio pull mode to none: https://github.com/embassy-rs/embassy/blob/master/embassy-stm32/src/gpio.rs#L552-L555
> Dig around in the reference manual and determine if there is a better way to start/stop a DMA transaction while keeping active control of the clock the whole time
I haven't found a better way
------
From ST reference manual RM0394 (L4)
(Same note in RM0399 (H7) / RM0038 (L1) / RM0316 /F3)):
40.4.6
Communication formats
...
The idle state of SCK must correspond to the polarity selected in the SPIx_CR1 register (by
pulling up SCK if CPOL=1 or pulling down SCK if CPOL=0).
Co-authored-by: Ralf <jr-oss@gmx.net>
1189: USB: Add MS OS Descriptors (alternate implementation) r=Dirbaio a=alexmoon
This is an alternate API for #1152 based on the work of `@mattico.` By switching to a writer-style API instead of a builder API some compile-time guarantees are lost, but it integrates better into the usb `Builder` and makes an api that can be used by USB device class implementations.
It also adds a feature flag so there is zero cost to the MS OS descriptors for devices that don't need to use them.
I've added an example based on `usb_serial` which tells Windows to use the generic `WinUSB` driver instead of the serial port driver for the device.
Comments are welcome. It would be nice to see either this or #1152 merged as my project is going to require the MS OS Descriptors soon.
Co-authored-by: Matt Ickstadt <matt@beckenterprises.com>
Co-authored-by: alexmoon <alex@moonspot.org>
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.
1177: STD driver needs a reentrant mutex; logic fixed to be reentrancy-safe r=Dirbaio a=ivmarkov
...or to summarize it in another way, the code in the alarm thread loop is written as if - when calling the user-supplied callback - the callback will *never, ever* call `alarm.set_alarm()`.
But this happens of course - at least with the generic timer queue implementation. Not sure if that would happen with `embassy-executor`'s own queue, but probably yes?
The end result on Linux is that the code deadlocks because when calling the user-supplied callback, the mutex of the alarms is locked, yet - the code in `set_alarm` tries to take the lock again leading to UB. (I suspect on Windows this will crash rather than deadlock but that's a bit irrelevant.)
(Note also that calling the user-supplied callback *outside* of the alarms' lock is also NOK, because at that time, the callback and/or context itself might be invalid as well, as the user might had changed it with a new one by calling `set_callback`. Right?)
I also had to fix the logic that computed the next timestamp when the alarm should fire; it was running a simple `for {}` loop, not anticipating that the just-traversed alarm might get a new timestamp.
The new code is slightly less efficient, in that on each `loop {}` iteration it always starts traversing the alarms from the beginning, whereas in reality only the timestamp of the alarm that just-fired could've changed, but given the complexities introduced by `RefCell`, I don't think we should bother with these micro-optimizations, for just 4 alarms in total.
Co-authored-by: ivmarkov <ivan.markov@gmail.com>
RM0394:
40.4.6
Communication formats
...
The idle state of SCK must correspond to the polarity selected in the SPIx_CR1 register (by
pulling up SCK if CPOL=1 or pulling down SCK if CPOL=0).
