743: Add PLL config support for F2 r=Dirbaio a=Gekkio
- minor changes to make the F2 RCC API a bit more flexible
- low-level PLL config with assertions based on datasheet specs. It shouldn't be very difficult to later add a "reverse API" where you pass the clocks you want to a function and it generates a `PLLConfig` struct for you
- PLL API tested on my custom board with 12 MHz HSE as source for PLL to generate max clocks for SYSCLK/AHB/APB/APB1/PLL48
- the example *should* work but is untested since I don't have the Nucleo board 😞
Co-authored-by: Joonas Javanainen <joonas.javanainen@gmail.com>
733: Add f107 ethernet support. r=Dirbaio a=davidlenfesty
The original driver works perfectly, the only required changes were only to clock and pin configuration.
Bits that are also present and deserve some scrutiny:
- Migrated LAN8742a driver to a generic SMI version (only *functional* difference is a couple extra status checks for the link poll, which IMO weren't great anyways (i.e. it would consider the link down if it negotiated to 10M)
- Migrated f1 RCC init to "new" style. As of creating this draft PR, it is pretty much only tested on the happy path for my specific configuration, and also needs a couple things done (calculated clock speeds are hardcoded and ADC clock isn't implemented)
- Support for v1b driver (f2 and f4) was added, but not tested.
(Made a draft PR until f4 support is verified and I finish the clock init - adding testing and at least feature parity with how it was before)
Co-authored-by: David Lenfesty <lenfesty@ualberta.ca>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
SMI Ethernet PHYs all share a common base set of registers that can do
90% of all tasks. The LAN8742 driver used some vendor-specific
registers to check link negotiation status, but the need for that was
debatable, so I migrated it to a generic driver instead, anybody who
wants extra functionality can copy it and impl their own on top of it.
This makes the configuration more flexible and closer to the underlying
configuration register structure. For example, we could use HSI for the
system clock, but use HSE to output a clock with MCO.
742: Only 1 argument in embassy::main when there is no HAL r=Dirbaio a=jbeaurivage
There is a slight mistake in an error message from `[embassy::main]` macro. When there is no HAL specified, `main` should take only one argument.
Co-authored-by: Justin Beaurivage <justin@wearableavionics.com>
738: Add split method to UarteWithIdle in nrf hal r=lulf a=ZoeyR
I needed this method because I was writing a driver for the sim7000 modem. Its a line based protocol so the read until idle was very useful to me. Unfortunately unlike the primary `Uarte` struct the `UarteWithIdle` didn't have `split()`. So I added it 😄
Co-authored-by: Zoey Riordan <zoey@dos.cafe>
740: Allow using separate page sizes for state and dfu r=lulf a=lulf
* Less generics on bootloader. Keep PAGE_SIZE as a common multiple of
DFU and ACTIVE page sizes.
* Document restriction
* Add unit tests for different page sizes
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
* Less generics on bootloader. Keep PAGE_SIZE as a common multiple of
DFU and ACTIVE page sizes.
* Document restriction
* Add unit tests for different page sizes
* Add flash drivers for L0, L1, L4, WB and WL. Not tested for WB, but
should be similar to WL.
* Add embassy-boot-stm32 for bootloading on STM32.
* Add flash examples and bootloader examples
* Update stm32-data
736: executor: allow Send-spawning of tasks if their args are Send. r=Dirbaio a=Dirbaio
This allows send-spawning (spawning into an executor in another thread) tasks if their args are Send. Previously this would require the entire future to be Send.
--
When send-spawning a task, we construct the future in this thread, and effectively
"send" it to the executor thread by enqueuing it in its queue. Therefore, in theory,
send-spawning should require the future `F` to be `Send`.
The problem is this is more restrictive than needed. Once the future is executing,
it is never sent to another thread. It is only sent when spawning. It should be
enough for the task's arguments to be Send. (and in practice it's super easy to
accidentally make your futures !Send, for example by holding an `Rc` or a `&RefCell` across an `.await`.)
Luckily, an `async fn` future contains just the args when freshly constructed. So, if the
args are Send, it's OK to send a !Send future, as long as we do it before first polling it.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
The normal `spawn()` methods can be called directly by the user, with arbitrary hand-implemented futures.
We can't enforce they're only called with `async fn` futures. Therefore, make these
require `F: Send`, and add a "private" one only for use in the macro, which can enforce it.
734: executor: Add `Spawner::for_current_executor`. r=Dirbaio a=Dirbaio
This is needed to spawn non-Send tasks in an InterruptExecutor, after the fixes in #730 .
`@matoushybl` could you check if this works for your use case?
735: stm32: add stm32u5 GPDMA, SPIv4 support, add HIL tests. r=Dirbaio a=Dirbaio
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
732: macros: simplify task macro using "TAIT laundering". r=Dirbaio a=Dirbaio
This brings the macro to the state before the nightly update #729#730, with a much cleaner workaround for the opaque type error, from https://github.com/rust-lang/rust/issues/96406
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
