Since https://github.com/RIOT-OS/RIOT/pull/20935 gpio_write()
uses a `bool` instead of an `int`. This does the same treatment for
`gpio_read()`.
This does indeed add an instruction to `gpio_read()` implementations.
However, users caring about an instruction more are better served with
`gpio_ll_read()` anyway. And `gpio_read() == 1` is often seen in
newcomer's code, which would now work as expected.
In case both periph_gpio_irq and periph_gpio_ll_irq are used, the
periph_gpio_irq implementation now uses periph_gpio_ll_irq, so that
they can coexist.
This implements `pm_set_lowest()` for the MSP430. Unlike most other
platforms, it intentionally does not use pm_layered. It is pretty
similar to `pm_layered` in that is does use reference counters, but it
uses them for two independent clock sources.
The main difference is that the low frequency clock domain can be
disabled even when the high frequency clock is still active. With the
layers, disabling layer n-1 while layer n is still blocked would not
work.
For super low symbol rates the auxiliary clock (ACLK) is used to
conserve power. But with only 32,678 Hz clock just prescaling will
result in poor bit timing, hence correct modulation control settings
to compensate are needed. Since computing this is too expensive, a
look-up table (as switch statement) for the four most common symbol
rates was used.
The datasheet gave the prescaler values ordered by ascending symbol
rate, the switch statement was ordered descending.
This changes the order to match the datasheets order and matches the
correct prescaler setting to the corresponding symbol rate.
Fixes https://github.com/RIOT-OS/RIOT/issues/20620
In TX-only mode the UART was previously release before all bits of the
last byte were shifted out. This adds a busy loop waiting while the
peripheral is still busy, fixing the issue.
Co-authored-by: benpicco <benpicco@googlemail.com>
The driver assumes that timer A and timer B have the same register
layout regarding all the features exposed by the driver. This is
backed by the MCU family datasheets for the MSP430 x1xx and the
MSP430 G2xx / F2xx MCUs (and likely more families).
The assert() is pretty limited in coverage, but more to document why
a "timer A clear" mask is used but still claiming the driver also
works for timer B. It just looks too much like a bug otherwise.
This cleans up the USCI based UART and SPI implementations and allows
multiple instances of either interface to be configured by the
boards. In addition, it allows sharing the USCI peripherals to provide
multiple serial interfaces with the same hardware (round-robin).
- Move common code for USART (shared SPI / UART peripheral) to its
own file and allow sharing the USART peripheral to provide both
UART and SPI in round-robin fashion.
- Configure both UART and SPI bus via a `struct` in the board's
`periph_conf.h`
- this allows allocating the two UARTs as needed by the use case
- since both USARTs signals have a fixed connection to a single
GPIO, most configuration is moved to the CPU
- the board now only needs to decide which bus is provided by
which USART
Note: Sharing an USART used as UART requires cooperation from the app:
- If the UART is used in TX-only mode (no RX callback), the driver
will release the USART while not sending
- If the UART is used to also receive, the application needs to power
the UART down while not expecting something to send. An
`spi_acquire()` will be blocked while the UART is powered up.
- add support for multiple timers
- add support for selecting clock source in the board's `periph_conf.h`
- add support for the prescaler
- implement `periph_timer_query_freqs`
- add a second timer to all MSP430 boards
- the first timer is fast ticking, high-power
- the second is slow ticking, low-power
The MSP430 vendor files already provide macros containing register
constants and symbols (provided via linker scripts) containing addresses
of peripheral registers. So lets make use of that rather than
maintaining a long list of constants.
RIOT supports two distinct families of the MSP430: The [MSP430 x1xx]
MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible
MCU families the code was located in the msp430fxyz folder, resulting
in case of the UART driver in particularly bizarre code looking roughly
like this:
#ifndef UART_USE_USCI
/* implementation of x1xx peripheral ... */
#else
/* implementation of F2xx/G2xx peripheral ... */
#endif
/* zero shared code between both variants */
This splits the peripheral drivers for USCI and USART serial IP blocks
into separate files and relocates everything in cpu/msp430, similar to
how cpu/stm32 is organized.
[MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf
[MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
