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>
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 CAN stack support only raw CAN at this time.
It contains a device interface (drivers/include/can/candev.h) and the data link
layer, build around can/device.c can/pkt.c and can/router.c. can/dll.c contains
the upper level and lower level interface to send and receive CAN frames.
Upper layer interface is located in include/can/raw.h
