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>
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>
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>
1171: Implement From<gpio::Level> for bool r=Dirbaio a=hulthe
From implies Into, so this won't break anything.
Co-authored-by: Joakim Hulthe <joakim@hulthe.net>
1168: Fix rcc prescaler for wb55 HCLK1 r=lulf a=chrenderle
- fix prescaler not divided which incorrectly set prescaler divided by 3
Issue: #1137
Co-authored-by: Christian Enderle <mail@chrenderle.de>
- Rename feature to `embedded-sdmmc`.
- Move embedded-sdmmc fork repo to the embassy-rs org.
- Remove unused features in the fork
- Fix impl in embassy-stm32
- Add to CI so it doesn't break again.
1161: WIP: Smoltcp socket config r=Dirbaio a=Czocher
This PR updates the smoltcp version to the newest master one as well as implements the feature specified in #1154 - to allow the dhcpv4 socket to be configured.
Currently it should be considered a WIP PR - requires testing.
`@Dirbaio` can you have a look and check if this is compatible with what we discussed on the matrix channel?
Co-authored-by: Paweł Jan Czochański <pawel@czochanski.pl>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
1162: rp gpio: make pin_bank() inline r=Dirbaio a=mkj
This allows set_high() etc to be inlined, toggling pins should be much faster.
Co-authored-by: Matt Johnston <matt@ucc.asn.au>
