514: Refactor sx127x driver to use async SPI r=lulf a=lulf
It also contains a fix to SPI DMA transfer/read_write operations to ensure MISO doesn't contain any old data.
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
513: Update stm32data ref r=lulf a=lulf
Not including the changes to stm32-data main which seems to break the build.
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
509: Remove unsafe from nRF uarte and improve doco with rationale r=Dirbaio a=huntc
The constructors themselves are not strictly unsafe. Interactions with DMA can be generally unsafe if a future is dropped, but that's a separate issue. It is important that we use the `unsafe` keyword diligently as it can lead to confusion otherwise.
I've also provided some rationale re. the usage of [Uarte] vs [BufferedUarte].
Co-authored-by: huntc <huntchr@gmail.com>
The constructors themselves are not strictly unsafe. Interactions with DMA can be generally unsafe if a future is dropped, but that's a separate issue. It is important that we use the `unsafe` keyword diligently as it can lead to confusion otherwise.
507: Stm32 data upate 4 r=Dirbaio a=Dirbaio
Main imrpvement is RCC regs info comes from yamls now.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
506: Clock cleaning r=Dirbaio a=lulf
Different STM32 RCC peripherals have different capabilities and register values. Define types for each RCC types inside each module to ensure full range of capabilities for each family can be used
Co-authored-by: Ulf Lilleengen <ulf.lilleengen@gmail.com>
Different STM32 RCC peripherals have different capabilities and register
values. Define types for each RCC types inside each module to ensure
full range of capabilities for each family can be used
449: STM32: Add PWM support r=Dirbaio a=bgamari
Here is a first-cut at implementing PWM support for STM32 targets via the TIM peripherals. Currently this only contains pin configuration for the STM32G0 but it would be straightforward to extend to other platforms.
Co-authored-by: Ben Gamari <ben@smart-cactus.org>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
486: Pwm ppi events r=Dirbaio a=jacobrosenthal
More PWM yak shaving. I was going to do some safe pwm ppi events stuff but I just dont think it fits this api design.. ppi is just very low level, im not sure how safe it will be in general
* first we should probably have borrows of handlers for ppi with lifetime of the peripheral? hal does eb4ba6ae42/nrf-hal-common/src/pwm.rs (L714-L716)
* in general having access to tasks can put the state in some configuration the api doesnt understand anymore. for `SequencePwm` ideally id hand you back either only seq_start0 or seq_start1 because youd only use one based on if your `Times` is even or odd.. but again we only know that with this api AFTER start has been called. I dont think were ready for typestates
SO I figured why not add the pwm ppi events but make them unsafe and commit this example since I started it.
Somewhat related drop IS removing the last duty cycle from the pin correctly, but stop DOES NOT..the only thing that sets the pin back is pin.conf() as far as I can tell, so I tried to document that better and got rid of stop for the `SimplePwm` again since that doesnt need it then. However its ackward we dont have a way to unset the pwm without setting a new sequence of 0s, or dropping the peripheral
Co-authored-by: Jacob Rosenthal <jacobrosenthal@gmail.com>
