Allowing to configure the CAN controller to start in monitor mode right
away reduces the risk to change traffic (e.g. by sending an ACK)
between initialization and the switch to monitor mode, if intneded to
be a passivle listnener only.
Being able to specify the bitrate from the peripheral config makes
a lot more sense than starting up the CAN with an incorrect bitrate and
letting the app change it later on.
Allow the board to configure whether the transmit pause feature of the
CAN controller should be used or not.
The default is to not enable transmit pause feature for consistency with
other CAN controllers. For many use cases enabling the transmit pause is
the better option though, as it will only slightyly decrease the maximum
throughput by inserting a 2 bit time pause between two subsequent
frames to send. The benefit is that it will ensure that nodes on the CAN
bus with a lower priority (according to their CAN ID) will not starve,
effectively prevending the "Babbling Idot Syndrome".
Allow the board to configure whether automatic retransmission is to be
used or disabled.
This also changes the default to enabling automatic retransmission, as
this is the best choice for most use cases.
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.
Using `PROGRAMMER=bmp` has been proven to work reliably at least on
SAMD21, SAMD5x and SAML21.
Since using unsupported programmers is treated as a warning, this change
only reduces the noise in the shell a bit and is not a functional
change.
[1]: https://black-magic.org/supported-targets.html
This formats the code to improve readability and apply the coding
convention. This is a whitespace only change that will not change
generated binaries.
The only peripheral that currently uses the FDPLL1 is SDHC. However, the SDHC IP can only be clocked at up to 150 MHz. Therefore, 100 MHz is currently used as the frequency of the FDPLL1. If another peripheral device requires 200 MHz in the future, this must be realized via different clock generators.
These functions can be used to set both FDPLL0 and FDPLL1 by using an extra argument 'idx' (index) and allow to set the ONDEMAND bit using the 'flags' argument
Signed-off-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Setting up a DMA transfer can take longer than sending out a buffer
byte by byte if the buffer is small.
DMA only shows advantages for large buffers, using it for every transfer
will cause a net slowdown.
Since we did not come up with a good way to determine the treshold based
on the SPI frequency, just use a fixed buffer for now so that DMA can be
used without slowing things down overall.
