Fixes#18
Syn considers doc comments to be attributes, so forwarding those fixes the issue.
It's probably a good idea to forward most attributes anyway.
Currently this looks up the frequency in the global singleton that must
be initialized by the per-chip RCC implementation. At present, this is
only done for the L0 family of chips.
* Moves the tim2-specific code into macro which always uses TIM2
* For peripherals without clock specified, attempt to locate enable and
reset registers in the RCC block matching the peripheral name. This
could be useful for peripherals where deducing the clock name might
not be feasible, but it remains to be tested with more chip families
to see if it is sufficiently accurate.
Modify init function to return a Clock instance defined by a per-chip
SystemClock type and use this in macro setup
A proof of concept implementation for STM32 L0 chips.
This allows using embassy::main macros for STM32 devices that have the
clock setup logic.
This removes the need to duplicate the configuration for each individual
chip, but will instead pass on the configuration specified in the config
attribute.
Update nrf, stm32, rp macros with passing the config to a per-chip
configure function which assumes the appropriate configuration to be
passed to it.
To demonstrate this feature, the stm32l0xx clock setup and RTC is added which exposes
clock configuration different from stm32f4xx (and has a different set of timers and HAL APIs).
This allows crates depending on embassy that wants to use a different
module path to do so for the 'task' and 'main' macros, by passing the
parameter 'embassy_prefix'. The prefix defaults to '::', which will
retain the existing behavior.
The `interrupt` package previously tried to be drop-in compatible with the
`interrupt` package from PACs. THis meant that there was both a PAC-style enum
value `UARTE0` and an embassy-style owned `UARTE0Interrupt` type. This made
things VERY confusing.
This drops compatibility with the PAC, improving the names for embassy interrupts.
- It's no longer possible to call run() reentrantly from within a task (soundness issue)
- it's now possible to spawn Send tasks across threads (SendSpawner, #37)
