Commit Graph

4883 Commits

Author SHA1 Message Date
Matt Ickstadt
617b0a03b9 usb: fix descriptor set length and DeviceInterfaceGUIDs 2023-02-07 14:24:35 -05:00
Matt Ickstadt
f5ff3c4ac3 usb: add support for MS OS Descriptors 2023-02-07 14:24:35 -05:00
bors[bot]
a7fa7d0de2
Merge #1201
1201: net: use released smoltcp 0.9.0 r=Dirbaio a=Dirbaio

bors r+

Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
2023-02-07 17:16:08 +00:00
Dario Nieuwenhuis
102b2e52cb net: use released smoltcp 0.9.0 2023-02-07 18:15:26 +01:00
Rasmus Melchior Jacobsen
7b11e339bd feat(fmc): Add 16 data bit ctor 2023-02-07 16:06:59 +01:00
bors[bot]
dadd6aafe9
Merge #1197
1197: fix(stm32): Align FMC with new versions from stm32-data r=lulf a=rmja



Co-authored-by: Rasmus Melchior Jacobsen <rmja@laesoe.org>
2023-02-07 14:48:26 +00:00
Rasmus Melchior Jacobsen
1b6aae9dde Also exclude fsmc_v1x3 2023-02-07 15:06:16 +01:00
Rasmus Melchior Jacobsen
e4dc473e04 Update stm32-data 2023-02-07 14:46:36 +01:00
Rasmus Melchior Jacobsen
562432ad8b Update stm32-data 2023-02-07 14:16:13 +01:00
Rasmus Melchior Jacobsen
494a76a0f1 React to updated fsmc versions 2023-02-07 14:14:47 +01:00
Rasmus Melchior Jacobsen
36ca18132d Update stm32-data 2023-02-07 12:35:59 +01:00
Rasmus Melchior Jacobsen
218f8e0490 fix(stm32): Align FMC with new versions from stm32-data 2023-02-07 12:17:37 +01:00
bors[bot]
ba18656e94
Merge #1177
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>
2023-02-06 18:05:22 +00:00
bors[bot]
c8a7b74bc2
Merge #1192 #1193
1192: stm32/usart: implement stop_bits configuration r=Dirbaio a=pattop



1193: stm32/usart: fix LPUART clock multiplier r=Dirbaio a=pattop

According to RM0351 Rev 9 (L4) and RM0399 Rev 3 (H7):

baud = (256 * clock) / LPUARTDIV


Co-authored-by: Patrick Oppenlander <patrick.oppenlander@gmail.com>
2023-02-06 13:39:37 +00:00
Ralf
e3174d7a99 STM32 SPI: Set clk-pin pull-up/-down to match spi clock polarity
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).
2023-02-06 13:23:35 +01:00
Patrick Oppenlander
fda36fd81b stm32/usart: fix LPUART clock multiplier
According to RM0351 Rev 9 (L4) and RM0399 Rev 3 (H7):

baud = (256 * clock) / LPUARTDIV
2023-02-06 11:22:41 +11:00
Patrick Oppenlander
64ebb9b7fe stm32/usart: implement stop_bits configuration 2023-02-06 09:44:15 +11:00
bors[bot]
7d8e6649b7
Merge #1187
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>
2023-02-03 06:33:22 +00:00
bors[bot]
662a02a557
Merge #1191
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>
2023-02-03 06:00:50 +00:00
Josh Mcguigan
0bb6000e5c stm32 gpio implement degrade to AnyPin 2023-02-02 21:42:42 -08:00
Dario Nieuwenhuis
a432d91d82
PeripheralRef docs improvements. 2023-02-03 06:36:10 +01:00
bors[bot]
9af25c3396
Merge #1188
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>
2023-02-02 12:09:22 +00:00
Samuel Tardieu
ef4a20f67b LoRa/STM32WL: adjust Rx window offset and duration
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.
2023-02-02 13:01:18 +01:00
Samuel Tardieu
c4cbb89fcd LoRa/SX126x: adjust Rx window offset and duration
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.
2023-02-02 13:01:18 +01:00
bors[bot]
95cff35a91
Merge #1179
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>
2023-02-02 10:09:33 +00:00
Dario Nieuwenhuis
cb88dd285d
nrf/twis: FIx doc typo 2023-02-01 20:54:32 +01:00
Grant Miller
791fbb3ca0 Make poll_fn lazily initialized again 2023-01-31 21:46:25 -06:00
Grant Miller
4a8e9cf4d9 Add internal AvailableTask type 2023-01-31 19:04:41 -06:00
Grant Miller
fb1946be7f Replace the pointer in TaskHeader with an Option<&Executor> 2023-01-31 18:59:03 -06:00
Grant Miller
a697f1517a Set poll_fn in TaskStorage::new 2023-01-31 18:59:03 -06:00
bors[bot]
465e4c8b19
Merge #1151
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>
2023-02-01 00:36:22 +00:00
bors[bot]
594969f281
Merge #1186
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>
2023-02-01 00:18:01 +00:00
Dario Nieuwenhuis
b5cf332cc0 nrf: docs. 2023-02-01 01:17:41 +01:00
Dario Nieuwenhuis
ca10fe7135 usb: docs 2023-01-31 22:27:19 +01:00
bors[bot]
4c19464548
Merge #1184
1184: Pass the correct buffer when creating TcpSocket r=lulf a=lulf



Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
2023-01-31 18:38:16 +00:00
Ulf Lilleengen
768fe699cf
Pass the correct buffer when creating TcpSocket 2023-01-31 19:36:41 +01:00
bors[bot]
c21cc21c62
Merge #1182
1182: executor: Replace `NonNull<TaskHeader>` with `TaskRef` r=Dirbaio a=GrantM11235



Co-authored-by: Grant Miller <GrantM11235@gmail.com>
2023-01-29 22:34:48 +00:00
Grant Miller
b6ca6d699a Make wake_task safe 2023-01-29 16:32:12 -06:00
Grant Miller
48e1aab762 executor: Replace NonNull<TaskHeader> with TaskRef 2023-01-29 15:52:13 -06:00
bors[bot]
7e251a2550
Merge #1180
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>
2023-01-27 15:06:35 +00:00
Samuel Tardieu
e453334870 LoRa/SX1276: adjust Rx window offset and duration
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.
2023-01-27 16:01:41 +01:00
nitroxis
c9e2cd6dd4 usb: allow adding isochronous endpoints 2023-01-27 15:53:13 +01:00
bors[bot]
7ec15f2def
Merge #1178
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>
2023-01-27 14:44:51 +00:00
nitroxis
1e60c60afd rp: allow isochronous USB endpoints to be up to 1023 in size 2023-01-27 07:24:49 +01:00
ivmarkov
34b67fe137 STD driver needs a reentrant mutex; logic fixed to be reentrancy-safe 2023-01-26 20:41:18 +00:00
bors[bot]
ffa75e1e39
Merge #1173 #1174
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>
2023-01-24 09:26:21 +00:00
Ulf Lilleengen
2a0ea52878
add missing copy of icmpv6 checksum
add proto-ipv6 feature to stm32h7 example to catch issues in CI
2023-01-24 10:25:37 +01:00
bors[bot]
5ee8626d72
Merge #1172
1172: IPv6 has no checksum r=lulf a=davidedellagiustina

As title says. Fixes `embassy-net` not compiling when feature `proto-ipv6` is enabled.

Co-authored-by: Davide Della Giustina <davide@dellagiustina.com>
2023-01-24 08:56:01 +00:00
Davide Della Giustina
32bdc54ccb
Changed crates' names for nrf examples since they were conflicting 2023-01-24 08:27:53 +00:00
Davide Della Giustina
f38d54a6a6
IPv6 has no checksum 2023-01-24 08:15:22 +00:00