Hello All,
I have been working on adding support for the FDCAN peripheral in the
STM32H7 and have a basic driver working. It's a bit of a hack in some
places right now, but it follows the same basic structure as the F7
driver, which was used as a template to start. I should note that I have
only been testing by using the CAN example program running in loopback
mode since I do not currently have any external devices to test with.
The FDCAN hardware in the H7 is a pretty significant departure from the
F7 and earlier, so there is some additional functionality that the
current upper-level CAN driver isn't really setup to support. I wanted
to bring the community in on my efforts so we could discuss those things
and decide whether they are worth pursuing. I personally have zero prior
experience with CAN, so I am not sure what hardware features are
typically utilized by most developers here.
The biggest difference that sets the H7 FDCAN apart from its
predecessors is the storage of messages. Unlike previous hardware that
made use of a fixed number of mailboxes for sending/receiving messages,
the H7 FDCAN integrates a 10kb segment of memory called the Message RAM
that is dedicated to the peripheral. All messages, both transmitted and
received, and filters are stored here. But more interestingly, the RAM
is dynamically configured by the user during the initialization process
based on their needs and can be split up into a variety of sections. I
don't want to get into a lot of detail here since I am likely telling
people what they already know, so interested parties should look at [1]
for a great summary of what the hardware can do. What I would like to
discuss right now is what features we want to use and some
implementation ideas for them. Since the upper-level driver places
messages into FIFOs, it is easy to make use of the Rx and Tx FIFOs in
hardware. The filters will also be necessary for the driver to function.
Right now, I have created kconfig options for configuring the sections
in RAM. That allows to user to specify what sections they want, how many
messages they want to store in each section, and how big the messages
are expected to be.
So what works right now? In short, the driver currently replicates the
functionality of the F7 driver. Here is a bullet list
* Hardware initialization
* Bit timing
* Message RAM setup for filters and FIFOs, configurable via kconfig
* Rx/Tx FIFOs with appropriate interrupts
* IOCTL calls implemented by F7 driver (no add/del filters)
* Txready/Txdone functions
* Functions to send/receive messages within hardware
* Tx/Rx interrupt enable/disable
What work needs to be done?
* Settle on what features to implement and a way to represent the
message RAM layout for efficient use by the driver
* Add support for RTR messages
* Add support for FD mode
* Add config option to enable/disable FIFO overwrite (default setup is
to block when full)
* Add support for bitrate switching?
* LOTS of testing
* nxstyle checks
* licensing since two files are derived from the F7 code that has
non-ASF licenses.
For now, I think the best path forward is to match the feature set of
existing CAN drivers. That will allow us to get the basics working and
well tested before moving onto anything that might require us to modify
the upper-level driver to add more advanced features such as bitrate
switching. So that means only using the hardware FIFOs for now. I think
we should allow the user to configure the message RAM via kconfig
options for maximum flexibility in the future. Even if we only add
options for the filter and FIFO sections right now, adding in additional
features later would be much easier with the infrastructure in place.
It also lets the user specify exactly what they want, removing the need
for the driver to hardcode potentially stupid assumptions. For
filtering, I have currently enabled a single bitmask filter to accept
all incoming messages. Implementing the add/del filter IOCTL calls
should be trivial, but I have some concerns there as well.
Please feel free to take a look at the code on my H7CAN branch
<https://github.com/rippetoej/incubator-nuttx/commits/H7CAN> - I am
prepared for a good old-fashioned code mocking
<https://dilbert.com/search_results?terms=code+mocking>. The code
follows the same structure as the F7 and earlier drivers and is well
documented I think. It is also based off my work in progress port of
the STM32H753XI evaluation board, so you will see a few commits
sprinkled in that are specific to my board.
Regards,
John Rippetoe
CONFIDENTIALITY NOTICE: This communication may contain private, confidential
and privileged material for the sole use of the intended recipient. If you are
not the intended recipient, please delete this e-mail and any attachments
permanently.
