This commit allows to share GPIO, Timers and UARTs driver across SAM3/SAM4s MCUs as they relies on the same IPs
Signed-off-by: dylad <dylan.laduranty@mesotic.com>
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>
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.
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>
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>
To avoid type conflicts between the `pthread_rwlockattr_t` definition in RIOT's `pthread` implementation and newlibc's `sys/_pthreadtypes.h`, the macro `_POSIX_READER_WRITER_LOCKS` must be undefined.
The cleanup reduces the number of linker scripts used for the ESP32x ROMs and thus the symbols used from the ESP32x ROMs. It works with both gcc 12.2 and gcc 14.2. The latter gcc version is a prerequisite for ESP-IDF v5.2 and higher and thus a prerequisite for starting the work on the RIOT-OS port for the latest version of ESP-IDF.
