The `channels` member should not be set to the number of hardware
channels *n*, but to *n* - 1 instead. The last channel is implicitly
used in `timer_read()`. Hence out of *n* hardware channels, only *n* - 1
are available to the application.
This fixes a bug introduced by 4d02e15247
which incorrectly set the channel number to *n* rather than to
*n* - 1.
- All nRF52 timers support 32 bit mode, so use that
- All nRF52 timers support at least 4 channels, the timers NRF_TIMER3
and NRF_TIMER4 even support 6 channels.
- Add a warning that `TIMER_DEV(1)` is used by the IEEE 802.15.4 driver
The peripheral configuration has been completely reworked to resolve
pin conflicts while provided as much of the peripherals as possible.
The changes include:
- Move `I2C_DEV(0)` from PB6/PB7 to PB8/PB9 to solve pin conflict with
`QDEC_DEV(2)`.
- Use pins PB0, PB1, PB4, and PB5 for PWM instead PA8, PA9, PA10, and
PA11
- PA9 and PA10 is in pin conflict with `UART_DEV(0)` which is used
for stdio with `stdio_uart`, PA8 was in conflict with
`QDEC_DEV(0)`, PA11 was in conflict with USB D-
- Use PB6, PB7 as `QDEC_DEV(0)` (previously `QDEC_DEV(2)`), as this is
the only completely conflict free setting
- Use PB4/PB5 instead of PA6/PA7 for QDEC_DEV(1)
- This fixes a pin conflict with `SPI_DEV(0)` MISO (and
`ADC_LINE(4)`)
- Only provide QDEC at PB4/PB5 when PWM is not used to avoid conflict
- Only provide QDEC at PA8/PA9 when UART is not used to avoid conflict
- Use SPI2 (PB15, PB14, PB13, PB12) as `SPI_DEV(0)` instead of SPI1,
use SPI1 (PA7, PA6, PA5, PA4) as `SPI_DEV(1)`
- Only provide `SPI_DEV(1)` if the ADC is not in used to resolve a
pin conflict
- Move PB0 and PB1 at the end of the ADC lines (previously
`ADC_LINE(6)` and `ADC_LINE(7)`, now `ADC_LINE(8)` and `ADC_LINE(9)`)
- Only provide them when PWM is not in use (to resolve pin conflict
with PWM)
- Also do not provide them for the Blackpill boards, which are
missing pins PB0 and PB1 on the headers
To make life of users easier, a Pinout diagram with the new
configuration was added.
The `fs` in the file name means that on-chip FS PHY is configured for USB OTG HS. The file is renamed to `cfg_usb_otg_hs_phy_fs.h`
- to clarify that USB OTG HS is just configured with PHY FS and not HS and FS,
- to allow a configuration of USB OTG FS and HS in one file called `cfg_usb_otg_hs_fs.h` or whatever, and
- to allow a configuration of USB OTG HS with ULPI PHY in a file called `cfg_usb_otg_hs_phy_ulpi.h`.
f
- most were trivial
- missing group close or open
- extra space
- no doxygen comment
- name commad might open an implicit group
this hould also be implicit cosed but does not happen somtimes
- crazy: internal declared groups have to be closed internal
The inverted and non-inverted `LED<num>_ON` and `LED<num>_OFF` macros
are swapped. This didn't reveal in testing as the
`LED<num>_IS_INVERTED` macros where not properly evaluated, due to a
typo in the check. This fixes both.
Using `UART_DEV(0)` (UASRT1) for stdio allows to use the same TTL
adapter that is used for programming via `stm32flash` to be used for
serial, without re-wiring after flashing.
Let boards only define the port and pin number of each LEDs. The common
definitions in `stm32_leds.h` will provide `LED<x>_ON`, `LED<x>_OFF`,
`LED<x>_TOGGLE`, `LED<x>_PIN`, `LED<x>_MASK` and `LED<x>_PORT`.
In addition to code de-duplication, this also makes it easier to use
LEDs in GPIO LL, which can be beneficial for super low overhead
debugging output - e.g. when a bug is timing sensitive and `DEBUG()`
would spent to much time for stdio to reproduce a bug.
