Commit Graph

4815 Commits

Author SHA1 Message Date
Ulf Lilleengen
32c3725631
add waker for DNS slots 2023-02-10 18:44:51 +01:00
Ulf Lilleengen
48dff04d64
Bump max queries 2023-02-10 18:34:21 +01:00
Ulf Lilleengen
472473d8c1
Create slice using ::Owned 2023-02-10 18:32:35 +01:00
Ulf Lilleengen
6e68353a93
attempt removing option 2023-02-10 18:30:17 +01:00
Ulf Lilleengen
7ae47cb1d8
Expose api on Stack and add doc
Make it work with smoltcp 0.9
2023-02-10 18:20:50 +01:00
Ulf Lilleengen
cd440a49d6
Rewrite to use a single socket 2023-02-10 17:46:08 +01:00
Ulf Lilleengen
614740a1b2
cargo fmt 2023-02-10 17:45:25 +01:00
Ulf Lilleengen
c203cefe01
Handle cancellation 2023-02-10 17:45:19 +01:00
Ulf Lilleengen
9cfea693ed
Add DNS socket to embassy-net 2023-02-10 17:45:03 +01:00
bors[bot]
023b0d5b22
Merge #1209
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>
2023-02-10 02:19:31 +00:00
Caleb Jamison
bd7b3bd455 Clamp ticks to 1 and round to nearest. 2023-02-09 20:57:27 -05:00
Caleb Jamison
a4371e9544 Add from_hz function for Duration. 2023-02-09 19:22:06 -05:00
bors[bot]
e1a0df7d46
Merge #1205
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>
2023-02-09 11:39:52 +00:00
Lucas Granberg
2b6654541d rustfmt 2023-02-09 13:01:44 +02:00
Lucas Granberg
43d018b67f Use rng_v2 cfg instead of chip specific for seed error recover hack 2023-02-09 12:44:20 +02:00
Lucas Granberg
ab4b3fa96d update stm32-data to include rng_v2 2023-02-09 12:42:57 +02:00
Dario Nieuwenhuis
26474ce6eb
Merge pull request #1207 from embassy-rs/net-driver-reexport
net: reexport driver crate.
2023-02-08 18:25:51 +01:00
Dario Nieuwenhuis
5edb3052e6 net: reexport driver crate. 2023-02-08 17:52:02 +01:00
Dario Nieuwenhuis
13666c9f12
Merge pull request #1206 from embassy-rs/update-nightly
Update Rust nightly.
2023-02-08 17:34:01 +01:00
Dario Nieuwenhuis
ac3e225988 Update Rust nightly. 2023-02-08 17:13:19 +01:00
Lucas Granberg
bab4277a86 hack for STM32WL, rcc reset in case of seed error
The STM32WL series has a more complicated rng device that gets stuck
when there is a seed error.
2023-02-08 17:57:37 +02:00
Lucas Granberg
da6b1e8399 Reset rng in case of clock or seed error 2023-02-08 17:52:49 +02:00
bors[bot]
9d637070a5
Merge #1203
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>
2023-02-07 23:31:24 +00:00
Dario Nieuwenhuis
86487db5d1 usb: use InterfaceNumber in msos. 2023-02-08 00:30:53 +01:00
Dario Nieuwenhuis
3af991ab63 usb: unify ControlHandler+DeviceStateHandler, route all control requests to all handlers.
- 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).
2023-02-08 00:17:08 +01:00
Dario Nieuwenhuis
1d841cc8ac usb: make max interface count configurable at compile time. 2023-02-08 00:16:04 +01:00
bors[bot]
4a224efe75
Merge #1200
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>
2023-02-07 22:24:15 +00:00
bors[bot]
c4a2c62096
Merge #1199
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>
2023-02-07 22:06:25 +00:00
bors[bot]
366fab5b87
Merge #1189
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>
2023-02-07 19:31:10 +00:00
alexmoon
aa21aebb0b Lazily encode UTF16 values and add docs 2023-02-07 14:24:35 -05:00
alexmoon
9f9230ae7a Convert MS OS descriptor builder to a writer API
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.
2023-02-07 14:24:35 -05:00
Matt Ickstadt
b9ecdb72bb usb: remove msos dead code 2023-02-07 14:24:35 -05:00
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