This is necessary for the machine.CAN implementation to use the same
low-level functions.
Includes some refactoring around FIFO selection as there was a footgun
where CAN_FIFO0/1 are 0/1 but FDCAN_RX_FIFO0/1 are not. Added an explicit
type for non-hardware-specific FIFO numbering.
Also moved responsibility for re-enabling CAN receive interrupts into the
higher layer (pyb_can.c layer) after calling can_receive().
Also includes this behaviour change for FDCAN boards:
- Fix for boards with FDCAN not updating error status
counters (num_error_warning, num_error_passive, num_bus_off). These are
now updated the same as on boards with CAN Classic controllers, as
documented.
- Previously FDCAN boards would trigger the RX callback function on error
events instead (passing undocumented irq numbers 3, 4, 5).
This behaviour has been removed in favour of the documented behaviour of
updating the status counters.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
The memory bank addresses used for these are independent, can (and must)
enable both.
Also looks like no need to shrink these if FDCAN2 is added, the Reference
Manual is a bit unclear but looks like the peripheral's RAM multiplies out
for each additional controller.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
The STATIC macro was introduced a very long time ago in commit
d5df6cd44a. The original reason for this was
to have the option to define it to nothing so that all static functions
become global functions and therefore visible to certain debug tools, so
one could do function size comparison and other things.
This STATIC feature is rarely (if ever) used. And with the use of LTO and
heavy inline optimisation, analysing the size of individual functions when
they are not static is not a good representation of the size of code when
fully optimised.
So the macro does not have much use and it's simpler to just remove it.
Then you know exactly what it's doing. For example, newcomers don't have
to learn what the STATIC macro is and why it exists. Reading the code is
also less "loud" with a lowercase static.
One other minor point in favour of removing it, is that it stops bugs with
`STATIC inline`, which should always be `static inline`.
Methodology for this commit was:
1) git ls-files | egrep '\.[ch]$' | \
xargs sed -Ei "s/(^| )STATIC($| )/\1static\2/"
2) Do some manual cleanup in the diff by searching for the word STATIC in
comments and changing those back.
3) "git-grep STATIC docs/", manually fixed those cases.
4) "rg -t python STATIC", manually fixed codegen lines that used STATIC.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
This is now consistent with other ports.
Also renamed `pin_{board/cpu}_pins_locals_dict` to
`machine_pin_{board/cpu}_pins_locals_dict`.
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
- Enable CAN FD frame support and BRS.
- Optimize the message RAM usage per FDCAN instance.
- Document the usage and different sections of the Message RAM.
The original code used a independent state with regards to the interrupt.
During heavy bus error conditions the internal state could become
out-of-sync with the interrupts.
Further explanation: during the development of an application using CAN
communication, a interrupt-run-away was found in some situations. It was
found that the error interrupt triggered (Warning, Passive or Bus-Off, all
triggered it) the run-away. The only recovery was a reset.
Two problems were found:
- the error interrupt is enabled but not cleared in the interrupt routine;
- an internal variable 'State' that was used to track the message received
state (empty, new, full, overflow) that was not directly related to
interrupt that indicated the state.
In this commit these issues are fixed by adding more values for the
interrupt reason (warning, passive, bus off) and clearing the error
interrupts, and making the internal state directly dependent on the
interrupt state for received messages.
Furthermore, introducing the FIFO1 in the CAN receive stage, another issue
existed. Even if the messages are received into the FIFO1 (by selecting
message filtering for FIFO0 and FIFO1), the interrupt firing was indicating
FIFO0 Rx. The configuration of the interrupts for this is now also fixed.
The CAN peripheral has 2 interrupt lines going into the NVIC controller.
The assignment of the interrupt reasons to these 2 interrupt lines was
missing. Now the reception of FIFO1 messages triggers the second interrupt
line. Other interrupts (Rx FIFO0 and bus error) are assigned to the first
interrupt line.
Tested on a Nucleo-G474, and also checked the HAL function to work with the
H7 family.
The new fdcan.c file provides the low-level C interface to the FDCAN
peripheral, and pyb_can.c is updated to support both traditional CAN and
FDCAN, depending on the MCU being compiled for.
