Use pseudomodules to add a dependency on the relevant feature:
periph_spi if the abp2_spi pseudomodule is selected,
or periph_i2c if the abp2_i2c pseudomodule is selected.
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>
RIOT implementation of CAN bus relies on SocketCAN model.
Since commit c398e56 (can: add optional DLC element to Classical CAN
frame structure), '__u8 can_dlc' attribute of struct can_frame is
considered as deprecated in SocketCAN and kept for legacy support.
Attribute '__u8 len' should be used instead.
union {
/* CAN frame payload length in byte (0 .. CAN_MAX_DLEN)
* was previously named can_dlc so we need to carry that
* name for legacy support
*/
__u8 len;
__u8 can_dlc; /* deprecated */
};
Moreover, CAN FD frame structure does not support legacy attribute
'can_dlc', making 'len' mandatory for incoming CAN FD support in RIOT.
struct canfd_frame {
canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */
__u8 len; /* frame payload length in byte */
__u8 flags; /* additional flags for CAN FD */
__u8 __res0; /* reserved / padding */
__u8 __res1; /* reserved / padding */
__u8 data[CANFD_MAX_DLEN]
__attribute__((aligned(8)));
};
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.
