Fixes a new opaque type error in the task macro.
Full error is "opaque type's hidden type cannot be another opaque type from the same scope".
This got disallwed by the lazy-TAIT PR: https://github.com/rust-lang/rust/pull/94081
Sadly there's now some weird type inference errors with pre-lazy-TAIT
nightlies, so support for those is dropped.
The stack reads its own descriptors to figure out which endpoints
are used in which alt settings, and enables/disables them as needed.
The ControlHandler has a callback so it can get notified of alternate
setting changes, which is purely informative (it doesn't have to do anything).
727: Switch to crates.io embedded-hal, embedded-hal-async. r=Dirbaio a=Dirbaio
This temporarily removes support for the async UART trait, since it's
not yet in embedded-hal-async.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
713: Bootloader external flash r=lulf a=lulf
Includes e-s and e-s-a impls for nrf QSPI
WIP: Working on testing it.
Co-authored-by: Ulf Lilleengen <ulf.lilleengen@gmail.com>
* Add FlashProvider and FlashConfig traits to define flash
characteristics
* Use traits in bootloader to retrieve flash handles and for
copying data between flash instances
* Add convenience implementations for using a single flash instance.
723: Add embedded-storage trait impls for QSPI r=Dirbaio a=lulf
* Adds implementations of embedded-storage and embedded-storage-async
for QSPI
* Add blocking implementations of QSPI
* Use blocking implementation in new() and embedded-storage impls
* Use async implementation in embedded-storage-async impls
* Add FLASH_SIZE const generic parameter
* Own IRQ in Qspi instance to disable it on drop.
Co-authored-by: Ulf Lilleengen <ulf.lilleengen@gmail.com>
* Adds implementations of embedded-storage and embedded-storage-async
for QSPI
* Add blocking implementations of QSPI
* Use blocking implementation in new() and embedded-storage impls
* Use async implementation in embedded-storage-async impls
* Add FLASH_SIZE const generic parameter
* Own IRQ in Qspi to disable it on drop
720: USB: New builder API r=Dirbaio a=Dirbaio
usb: improved descriptor building API
The same API call allocates interfaces/endpoints/etc and writes their descriptors.
This means less API calls, and less possibility to screw things up.
DescriptorWriter is now private.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
The same API call allocates interfaces/endpoints/etc and writes their descriptors.
This means less API calls, and less possibility to screw things up.
DescriptorWriter is now private.
- Renamed structs to HidReaderWriter, HidReader, HidWriter.
- Removed unused const generics on `State`.
- Simplified generics on `HidReaderWriter`.
The class type previously was `HidClass<D, Driver<'d, USBD>, ReportReader<'d, Driver<'d, USBD>, OUT_N>, IN_N>`
It's now `HidClass<D, Driver<'d, USBD>, IN_N, OUT_N>`. Note that the driver type `Driver<'d, USBD>` is no longer repeated.
- Constructors are now: `HidWriter::new()` for IN-only, `HidReaderWriter::new()` for IN+OUT. No complicated bounds.
- HidReaderWriter has all the methods from HidReader, HidWriter.
711: Add DeviceStateHandler, DeviceCommand channel, and remote wakeup support r=Dirbaio a=alexmoon
Apologies for the size of this PR. Once I started getting into the Vbus power management side of my device I found a couple of areas of functionality missing from embassy-usb. Specifically, I need the application to be able to respond to changes in the USB device state in order to properly control the amount of power I'm drawing from Vbus. I also wanted to enable remote wakeup support for my device.
In order to enable device state monitoring, I've created a `DeviceStateHandler` trait and made it possible to pass in an optional reference a handler implementing that trait when creating the `UsbDeviceBuilder`.
Remote wakeup required a way to send commands to the bus which is exclusively owned by the `UsbDevice::run` method. This is the same problem we were discussing for enabling/disabling the device on Vbus power events. My solution is to allow an optional `Channel` to be provided to the `UsbDeviceBuilder` (via `UsbDeviceBuilder::new_with_channel`), allowing the application to send commands into the `run` method. Right now it supports enable, disable and remote wakeup commands.
Since there's now a way to dynamically enable and disable the device, I also added `Config::start_enabled` to control whether or not the `UsbDevice` should start in the enabled state. That also allowed me to make `UsbDeviceBuilder::build` sync again and move enabling the bus into `UsbDevice::run`.
This led to a few driver changes:
1. `Driver::enable` became `Driver::into_bus`
2. `Bus::enable`, `Bus::disable`, and `Bus::remote_wakeup` were added
3. I removed `Bus::reset`, `Bus::suspend`, and `Bus::resume` because they were only ever called based on the result of `Bus::poll`. It made more sense to me to have `Bus::poll` handle the driver-specific state management itself.
I've updated the `usb_hid_keyboard` example to take advantage of all these additional features.
Let me know what you think.
Thanks!
Co-authored-by: alexmoon <alex.r.moon@gmail.com>
714: add more clock options for l4 and l5 r=Dirbaio a=ant32
- added an assert so it panics if pll48div is not 48Mhz
- added MSI as a clock source for PLL
- removed hsi48 option for MCUs mentioned in l4 rcc presentation
- copied some code from l4 to l5, but don't have a way of testing it.
Co-authored-by: Philip A Reimer <antreimer@gmail.com>
694: Add select, select3, select4. r=Dirbaio a=Dirbaio
The difference with those from the `futures` crate is they don't return the other partially-run futures, so they can work with `!Unpin` futures which makes them much easier to use.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
715: stm32/dac: Check proper channel r=Dirbaio a=michalsrb
Small fix. Otherwise it panics when trying to use channel 1 if channel 2 does not exist.
Co-authored-by: Michal Srb <michalsrb@gmail.com>
699: Add ADC support for H7 r=Dirbaio a=matoushybl
Seems to work on H743, ADC1 works fine, but ADC3 has different ADC_COMMON block which stm32-data does't yet support, so measuring VREFINT or TEMP doesn't work. I'd like to discuss how adding support for the different ADC_COMMON could be done.
Co-authored-by: Matous Hybl <hyblmatous@gmail.com>
