stm32f103xx-hal
stm32f103xx-hal copied to clipboard
japaric
HAL for the STM32F103xx family of microcontrollers
The `stm32f103xx` chips have built-in analog-to-digital converters which aren't supported ATM by `stm32f103xx-hal`. I'd be nice if there was support because they're often useful. I did some digging and this...
There are some questions about the future of this crate. Some questions: - using stm32f1 crate as the device crate - being generic on stm32f1xxxx chips - modernizing and cleaning...
At the moment DMA can be done with peripherals. One cannot use the hal to configure the dma subsystem to have arbitrary dma transfers, or transfers triggered by Timer peripherals....
Unless I'm mistaken, this crate isn't published on crates.io. I'm currently including it in my project like this: ```rust [dependencies.stm32f103xx-hal] git = "https://github.com/japaric/stm32f103xx-hal.git" features = ["rt"] version = "*" ```...
Depends on the unproven+unreleased watchdog traits from `embedded-hal`
Stm32f103xx MCUs come in different flash densities, which affects the FLASH and RAM specified in memory.x. This change adds features to this board support package to be able to specify...
The CFGR builder API doesn't let you select a clock source. Possible sources: * HSI (high speed internal) oscillator * HSI as source for PLL * HSE (high speed external)...
Currently the SPI code hard configures MSB first transfers. stm32f103xx-hal/src/spi.rs@83574bc starting at line 135: ``` // mstr: master configuration // lsbfirst: MSB first […] spi.cr1.write(|w| { w.cpha() […] .lsbfirst() .clear_bit()...
My current project reads a `MonoTimer` in order to keep track of signals which have been received. These signals are then sent over serial to a pc. This works flawlessly...
To make this timer2 based blinky example work, I had to add clear_interrupt_pending to the timer implementation macro. ' /// use this in the interrupt handler pub fn clear_interrupt_pending(&mut self)...
