> dirbaio: so I was checking how zephyr does UARTE RX on nRF
> dirbaio: because currently we have the ugly "restart DMA on line idle to flush it" hack
> dirbaio: because according to the docs "For each byte received over the RXD line, an RXDRDY event will be generated. This event is likely to occur before the corresponding data has been transferred to Data RAM."
> dirbaio: so as I understood it, the only way to guarantee the data is actually transferred to RAM is to stop+restart DMA
> dirbaio: well, guess what?
> dirbaio: they just count RXDRDY's, and process that amount of data without restarting DMA
> dirbaio: with a timer configured as counter https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/serial/uart_nrfx_uarte.c#L650-L692
> dirbaio: 🤔🤷⁉️
> dirbaio: someone saying you can do the "hook up rxdrdy to a counter" trick, someone else saying it's wrong 🤪https://devzone.nordicsemi.com/f/nordic-q-a/28420/uarte-in-circular-mode
So we're going to do just that!
- BufferedUarte is lock-free now. No PeripheralMutex.
- The "restart DMA on line idle to flush it" hack is GONE. This means
- It'll work correctly without RTS/CTS now.
- It'll have better throughput when using RTS/CTS.
When using gpio pin changes for things like peripheral interrupts these
debug! calls flood defmt, making it difficult to find what you're
actually looking for.
1255: common: allow atomic ringbuf to fill up to N instead of just N-1. r=Dirbaio a=Dirbaio
Extracted out of #1208. Since I don't think that'll end up using the ringbuf in the end, I've separated it.
This allows the ringbuf to be filled up to `N` instead of just `N-1`, using some fun tricks on the indices.
The advantage is better performance: Before, the first write would fill N-1 bytes, The second would write just the 1 byte left before wrapping, then N-2. Then 2, then N-3, and so on. This would result in more smaller chunks, so worse perf. This problem is gone now.
bors r+
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
This allows the ringbuf to be filled up to `N` instead of just `N-1`, using some fun tricks on the indices.
The advantage is better performance: Before, the first write would fill N-1 bytes, The second would write just the 1 byte left before wrapping, then N-2. Then 2, then N-3, and so on. This would result in more smaller chunks, so worse perf. This problem is gone now.
1247: `PacketQueue::init()` r=davidedellagiustina a=davidedellagiustina
`PacketQueue` is pretty big, so I added a method to initialize it without requiring an allocation on the stack (which could in fact overflow). Before this PR, the only solution would be to declare a `PacketQueue` instance as a `static mut`, while now one could for example have a `Box<MaybeUninit<PacketQueue<...>>>` and then use `init()` on it.
Ideally, the same work would need to be done for all those structures that own big arrays which could overflow the stack.
Co-authored-by: Davide Della Giustina <davide@dellagiustina.com>
1248: embassy-time: add async tick() method to Ticker r=Dirbaio a=kbleeke
Small QOL change so you don't have to add a direct dependency on futures-util to use the Ticker
Co-authored-by: kbleeke <pluth@0t.re>
1238: embassy-net: DNS resolver detects when name is just an IP address r=lulf a=kbleeke
fixes#1237
I am not sure, if this is the right place to put this code. Alternatively, It could be in dns::DnsSocket or reqwless (and all other libraries that need to maybe resolve hostnames).
Are there other DNS query-types where it would make sense to try to parse an IP address?
Co-authored-by: kbleeke <pluth@0t.re>
1236: Add `#[must_use]` to all futures r=Dirbaio a=GrantM11235
I think that's all of them, I just grep'd for `impl.* Future for`
Co-authored-by: Grant Miller <GrantM11235@gmail.com>
1231: embassy-time: Implement conversions to/from core::time::Duration for embassy-time::Duration r=Dirbaio a=kbleeke
I chose microseconds for the conversion as the lowest resolution that embassy provides. A new Error-type did not seem that useful but I can add one, if necessary.
Co-authored-by: kbleeke <pluth@0t.re>
1228: stm32/sdmmc: Implement proper clock configuration r=chemicstry a=chemicstry
This implements proper clock configuration for sdmmc based on chip family, because `RccPeripheral::frequency()` is almost always incorrect. This can't be fixed in PAC, because sdmmc uses two clock domains, one for memory bus and one for sd card. `RccPeripheral::frequency()` usually returns the memory bus clock, but SDIO clock calculations need sd card domain clock. Moreover, chips have multiple clock source selection bits, which makes this even more complicated. I'm not sure if it's worth implementing all this logic in `RccPeripheral::frequency()` instead of cfg's in sdmmc.
Some chips (Lx, U5, H7) require RCC updates to expose required clocks. I didn't want to mash everything in a single PR so left a TODO comment. I also left a `T::frequency()` fallback, which seemed to work in H7 case even though the clock is most certainly incorrect.
In addition, added support for clock divider bypass for sdmmc_v1, which allows reaching a maximum clock of 48 MHz. The peripheral theoretically supports up to 50 MHz, but for that ST recommends setting pll48 frequency to 50 MHz 🤔
Co-authored-by: chemicstry <chemicstry@gmail.com>
