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).
1187: executor: Minor refactoring r=Dirbaio a=GrantM11235
The third commit may be slightly more controversial than the first two. Personally, I think it makes the code more readable and easier to reason about, but I can drop it if you disagree.
Co-authored-by: Grant Miller <GrantM11235@gmail.com>
1191: stm32 gpio implement degrade to AnyPin r=Dirbaio a=JoshMcguigan
This PR implements a `degrade` method on the STM32 GPIO structs `Flex`/`Input`/`Output`/`OutputOpenDrain`. This allows, for example, transforming some `Input<T>` to an `Input<AnyPin>`.
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
1188: LoRa timings for SX126x/STM32WL r=lulf a=samueltardieu
Those timings open Rx time windows covering 99.7% of the one expected
by the antenna while allowing 3ms for the Rx subsystem to start listening.
Co-authored-by: Samuel Tardieu <sam@rfc1149.net>
1179: LoRa/SX1276: adjust Rx window offset and duration r=lulf a=samueltardieu
After a transmission, two receive windows Rx1 and Rx2 are opened for one second each, one right after the other, after a fixed delay (for example 5s). The Rx window offset is added to the starting date of each window and the Rx window duration represents the maximum delay we will wait for an incoming message before declaring that a timeout occurred.
A value of -500ms for the offset and 800ms for the duration means that instead of having Rx1 = [5000, 6000[ and Rx2 = [6000, 7000[ we get Rx1 = [4500, 5300[ and Rx2 = [5500, 6300[. We only cover 30% of the expected windows.
The maximum time a SX127x can take before the Rx side is ready is TS_HOP + TS_RE = 50µs + 2.33ms. Using 3ms for the offset and 1003ms for the duration will give much better time windows: Rx1 = [4997, 5997[ and Rx2 = [5997, 7000]. Note that the
lorawan-device crate caps Rx1 end date to Rx2 start date.
This change allows a previously failing Murata CMWX1ZZABZ-091 module (STM32L + SX1276) to connect to the TTN LoRa network.
Co-authored-by: Samuel Tardieu <sam@rfc1149.net>
1151: USB: allow setting the interface string for interface alt settings r=Dirbaio a=mattico
This is a breaking change to embassy-usb's API.
Co-authored-by: Matt Ickstadt <matt@beckenterprises.com>
1186: Add some docs r=Dirbaio a=Dirbaio
This also does some renames of things to more intuitive/consistent names.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
1180: usb: allow adding isochronous endpoints r=Dirbaio a=nitroxis
This adds (basic) support for isochronous endpoints. In theory, isochronous endpoints have guaranteed bandwidths and are support to adhere to strict timings. But it seems that nothing bad happens if you don't follow the specs closely in this regard. Better handling could also still be added in the future.
Co-authored-by: nitroxis <n@nxs.re>
After a transmission, two receive windows Rx1 and Rx2 are opened
for one second each, one right after the other, after a fixed delay
(for example 5s). The Rx window offset is added to the starting date
of each window and the Rx window duration represents the maximum
delay we will wait for an incoming message before declaring that
a timeout occurred.
A value of -500ms for the offset and 800ms for the duration means
that instead of having Rx1 = [5000, 6000[ and Rx2 = [6000, 7000[
we get Rx1 = [4500, 5300[ and Rx2 = [5500, 6300[. We only cover
30% of the expected windows.
The maximum time a SX127x can take before the Rx side is ready is
TS_HOP + TS_RE = 50µs + 2.33ms. Using 3ms for the offset and
1003ms for the duration will give much better time windows:
Rx1 = [4997, 5997[ and Rx2 = [5997, 7000]. Note that the
lorawan-device crate caps Rx1 end date to Rx2 start date.
This change allows a previously failing Murata CMWX1ZZABZ-091
module (STM32L + SX1276) to connect to the TTN LoRa network.
1178: rp: allow isochronous USB endpoints to be up to 1023 bytes in size r=Dirbaio a=nitroxis
The datasheet allows isochronous USB endpoints to be up to 1023 bytes in size (see "4.1.2.5. DPSRAM"). This PR changes the check to allow this and also changes the length computation to align to 64 bytes (instead of hardcoded 64 bytes).
Embassy does not yet support isochronous USB endpoints, however I'm investigating adding support. This change is simple enough and should be correct according to the datasheet, so maybe future implementers don't run into this issue.
Co-authored-by: nitroxis <n@nxs.re>
