- 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 pins P5.2, P5.1, P5.3 configured as SPI pins are only routed to
USART1 and not to USART0, but previously USART0 was configured as
peripheral backing the bus. This fixes the peripheral configuration by
changing it to USART1.
This is quite unfortunate as USART1 is also used to provide the UART
interface used for `stdio`. Hence, one can either use `stdio` or SPI.
A feature conflict between UART and SPI has therefore been added.
Note that while it would be possible to use P3.2, P3.1, P3.3 to provide
SPI with USART0, this would not work in practise: P3.1 and P3.3 are
connected to the CC1020 transceiver.
Switching to P3.4/P3.5 for UART to provide it using USART 0 would also
resolve the resource conflict. However, these pins are not available
via any of the header and would require soldering the UART<->USB
adapter directly to the pins of the MCU chip on the PCB. It is therefore
much more user friendly to keep the UART bus backed by USART1 to use
pins P3.6 and P3.7 that are easily accessible via the pin header.
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
19593: boards/msb-430: add documentation r=maribu a=maribu
### Contribution description
This adds basic documentation, schematics, pinouts, and info how to get started with the `msb-430` board.
19597: sys/shell: Add coreclk command to shell_cmd_sys r=maribu a=maribu
### Contribution description
The coreclk shell command now prints the CPU frequency in Hz, which can be useful for boards with RC generated CPU frequency (e.g. RP2040, FE310, or MPS430Fx1xx MCUs allow this) which may quite a bit off the target frequency.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Provide a common clock initialization driver rather than leaving
clock initialization to the boards code. A declarative description of
the board's clock configuration using a struct does still allow to
fine-tune settings. In addition, a board is still allowed to just
provide a custom `void clock_init(void)` if there really is the need
to do crazy things.
- 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 file always exist so no need to do '-include'.
Replaced using:
sed -i 's|-\(include $(RIOTCPU)/.*/Makefile.features\)|\1|' \
$(git grep -l '$(RIOTCPU)/.*/Makefile.features' boards)
- Use RIOT's GPIO interface to access the sensor to increase portability
- Changed API to allow more than one sensor per board
- Added `sht1x_params.h` that specifies how the sensors is connected - each
board can overwrite default settings by #defining SHT1X_PARAM_CLK and
SHT1X_PARAM_DATA
- Changed arithmetic to use integer calculations only instead of floating point
arithmetic
- Added support for checking the CRC sum
- Allow optional skipping of the CRC check to speed up measuring
- Added support for advanced features like reducing the resolution and skipping
calibration to speed up measuring
- Allow specifying the supply voltage of sensor which heavily influences the
temperature result (and use that information to calculate the correct
temperature)
- Reset sensor on initialization to bring it in a well known state
- Support for the obscure heater feature. (Can be useful to check the
temperature sensor?)
- Updated old SHT11 shell commands to the new driver interface, thus allowing
more than one SHT10/11/15 sensor to be used
- Added new shell command to allow full configuration of all attached SHT1x
sensors
- Removed old command for setting the SHT11 temperature offset, as this feature
is implemented in the new configuration command
