Honeywell ABP2 pressure sensors series.
Implement all sensors features, only supporting the SPI version
of the sensor.
Prepare future support for the I2C interface by emphasizing where
to implement the code that will support the I2C bus version.
Add an API to search for the frequency supported by a timer that
is closest to the given target frequency.
This is in fact non-trivial to get right, as pre-scaler registers can
be 16 bit or even 32 bit in size, making a naive loop over all possible
pre-scalers too expensive (computationally).
Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>
Both SPI and I2C peripheral drivers *MUST NOT* be initialized by the
application code / (non-peripheral) device driver, as this is done
automatically be default. Some peripheral drivers have a non-idempotent
initialization and initializing them twice will break things.
Sadly, the doc states the exact opposite.
This updates the documentation to match the implementation. In addition
the special case is pointed out of disabling the automatic
initialization during boot, in which case the app indeed has to do the
initialization.
During the data phase of a FDCAN transmission only one node is
transmitting, all others are receivers. The length of the bus line has
no impact.
When transmitting via pin FDCAN_TX the protocol controller receives the
transmitted data from its local CAN transceiver via pin FDCAN_RX. The
received data is delayed by the CAN transceiver loop delay.
If this delay is greater than TSEG1 (time segment before sample point),
a bit error is detected. Without transceiver delay compensation, the bit
rate in the data phase of a FDCAN frame is limited by the transceiver's
loop delay.
Since this parameter is related to the transceiver used, there cannot be
a default value, and it must be explicitly defined with the
configuration variable CONFIG_FDCAN_DEVICE_TRANSCEIVER_LOOP_DELAY.
Signed-off-by: Gilles DOFFE <gilles.doffe@rtone.fr>
Add CAN FD specifities to CAN system library in RIOT:
* 64 bytes payload
* Bit rate switching
* Error State Indicator
Signed-off-by: Gilles DOFFE <gilles.doffe@rtone.fr>
Whole CAN code in RIOT is using 'struct can_frame' to represent a CAN
frame.
However incoming CAN FD support will bring 'struct canfd_frame' to
represent CAN FD frames.
Even if the 'struct canfd_frame' has additional flags and a bigger
payload, it is aligned on 'struct can_frame' and thus they can be
referenced by the same pointers in the code.
As it is impossible to predict which one will be used in RIOT, just
define a new type 'can_frame_t' which will map to the right struct
according to the MCU CAN supported format.
Signed-off-by: Gilles DOFFE <gilles.doffe@rtone.fr>
The UART API has not spelled out what happens when `uart_init()` is
called twice. This adds precise language that states that
acquire/release semantic is to be expected from the caller. Hence,
a caller needs to call `uart_poweroff()` before reconfiguring the UART
with a second call `uart_init()` for the same UART interface.
In practise, few apps will ever reconfigure the symbol rate. So the
impact is rather low.
However: This API now allows drivers to implement sharing of a serial
peripheral that can provide multiple interfaces (e.g. UART, SPI, I2C,
etc.). It would require some cooperation from the code that does use
the UART to actually release the UART again after each transaction;
something that will only work when RX data is only expected at
known points in time (e.g. in response to a request, or never in case
of TX only stdio). But still, this can mean the difference between
a use case becoming feasible on an MCU with a low number of serial
peripherals or not.
