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.
The generated `partitions.csv` needs to state the size of the flash
file. This so far used `ls -l | awk '{print $5}'` to achieve that, but
that is not robust, as the columns of `ls -l` depend on the tool and
system configuration used.
This commit replaces the call with `wc -c`, which should be more robust,
as `wc -c` behavior is POSIX specified.
Co-Authored-By: Karl Fessel <karl.fessel@ml-pa.com>
Co-Authored-By: Benjamin Valentin <benjamin.valentin@ml-pa.com>
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.
Instead of listing 'no targets found', detect unsupported targets as
well. Once we need to attach, assert that the target is supported.
Starting with firmware 2.0.0 of the BMP, not all targets are supported
by defaults (depends on the firmware flavor). Adding support for this
case therefore makes sense.
Parse the version number from the product description as returned by
libusb. This works for stable firmware releases, and ensures that
older firmwares work out of the box.
CAN required CLK_CANx_APB and CLK_CANx_APB to be running and will not
request any clock by itself. We can ensure both clocks to be running
by preventing the MCU from entering IDLE state.
The SAMD5x/SAME5x Family Data Sheet says in Section
"39.6.9 Sleep Mode Operation" says:
> The CAN can be configured to operate in any idle sleep mode. The CAN
> cannot operate in Standby sleep mode.
>
> [...]
>
> To leave low power mode, CLK_CANx_APB and GCLK_CANx must be active
> before writing CCCR.CSR to '0'. The CAN will acknowledge this by
> resetting CCCR.CSA = 0. Afterwards, the application can restart CAN
> communication by resetting bit CCCR.INIT.
tl;dr: At most SAM0_PM_IDLE is allowed while not shutting down the CAN
controller, but even that will pause communication (including RX).
Apparently, the CAN controller was never tested without also using the
USB peripheral, which kept the clocks running as side effect.
Additionally to requesting a delegated prefix via DHCPv6 this also
enables to ask for a temporary (non-permanent) address on the 6lbr. If
the upstream DHCP server provides one, this can be used to establish
end-to-end connectivity from the 6lbr towards an Internet host directly.
Increase Shell buffer size for 64 bytes payload length of CAN FD frame.
This also implies to increase main thread stack size and especially for
native architectures.
Add two new sub-commands to test_can command:
* fdsend: to send a CAN FD frame
* fdsendrtr: to send a CAN FD RTR frame (payload length = 0).
Signed-off-by: Gilles DOFFE <gilles.doffe@rtone.fr>
As CAN FD is already supported by SocketCAN on Linux, just enable the
fdcan pseudomodule and allow CAN FD frames.
Signed-off-by: Gilles DOFFE <gilles.doffe@rtone.fr>
Until now, STM32 MCUs classic CAN support is coded in can.c file.
However CAN FD in STM32G4 family is designed in a very different way:
* CAN FD channels are independant
* CAN FD channel configuration is done in a dedicated RAM block called
message RAM, with one message RAM per channel
* Each message RAM is divided this way:
- 11-bit filter (28 elements / 28 words)
- 29-bit filter (8 elements / 16 words)
- Rx FIFO 0 (3 elements / 54 words)
- Rx FIFO 1 (3 elements / 54 words)
- Tx event FIFO (3 elements / 6 words)
- Tx buffers (3 elements / 54 words)
Due to these design differences with other STM32 MCUs, the choice is
made to split the driver in two files:
* classiccan.c for STM32 MCUs that support classical CAN. This file
has just been renamed (previously can.c) to avoid build conflicts
but does not introduce changes
* fdcan.c for STM32 MCUs that support CAN FD
Message RAM definitions is not provided in CMSIS headers of the STM32G4
family, they are defined in fdcandev_stm32.h. Those definitions could be
extracted to a new file for each STM32 families as some differences
exist with other STM32 families that support CAN FD (for instance
STM32H7). This could be done in a futher commit, according to new
families requirements.
CAN hardware parameters stay similar and are kept in can_params.h.
There are 36 filters per channel:
* 28 first filters are standard ID (11 bit) filters
* 8 last filters are extended ID (29 bit) filters
On each Tx frame sent, the STM32G4 can store Tx events in a dedicated
FIFO. This feature is not yet implemented and Tx event FIFO is disabled
by default.
Automatic retransmission on arbitration loss is enabled by default by
the STM32G4.
About Rx, if no filter is configured, all frames are accepted by
default.
Signed-off-by: Gilles DOFFE <gilles.doffe@rtone.fr>
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>
