This makes the header a lot more readable and `clang -Wdocumentation`
happy, which does not like HTML tags (`<a href="...">...</a>`) to
contain random line breaks.
- The responsibility for handling matching CoAP No-Response Options
has been split:
- `coap_build_reply()` only needs to report this and return
`-ECANCLED`
- `coap_handle_req()` does generate the empty ACK is needed.
==> As a result, writing CoAP request handlers correctly becomes a
lost easier. Correct error handling to be present is now
sufficient for correct handling of No-Response options.
==> This change is backward compatible with existing code.
- The API doc has been cleaned up and straightened
Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>
For in-band signalling that a content format is not valid / present,
the magic number `COAP_FORMAT_NONE` was introduced and the type
`uint16_t` was used. Some APIs however used different in-band signalling
values and types:
- coap_reply_simple(): No signal available, `unsigned int`
- coap_build_reply_header(): negative values, `int`
(Using `int` would prevent using larger content format numbers on
8-bit and 16-bit archs, where `int` and `int16_t` have the same
range.)
This changes the behavior to consistently use `COAP_FORMAT_NONE` as
"no content format" signal and `uint16_t` as type.
There is an `typdef void sock_udp_ep_t` hack in `nanocoap.h` that tries
allow using parts of nanocoap without a RIOT network stack.
There is a similar hack to allow it to be used without RIOT at all. This
has been used in the early days during development on Linux directly.
This however has not been tested and left bit rotting.
Both hacks are remove and nanocoap now just depends on sock/udp.h.
In a future cleanup, the CoAP packet parsing and building code of
nanocoap can be separated from the part that does the transmission and
reception of UDP packets. That way, using nanocoap's packet parsing and
building will again be available without using a network stack.
Until then, let's drop the hacks and just depend on a network stack.
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>
