Hi All,
Since no new files are allowed to come into the repo without ASF
licenses, I need some direction on how I should go about re-licensing
two of the files for this driver. The files in question are
arch/arm/src/stm32f7/stm32_can.h -- This is only copyrighted by Greg.
Greg, do I have your permission to re-license this under the new ASF
license?
arch/arm/src/stm32f7/stm32_can.c -- In addition to Greg, this is also
copyrighted by Paul Alexander Patience from Omni Hoverboards Inc. What
steps do I need to take for this file?
Thanks,
John
On 4/23/20 4:48 PM, John Rippetoe wrote:
I just realized that the reference I made to an external document in
my first email didn't actually get linked too. For those interested,
see below.
[1]
https://www.st.com/resource/en/application_note/dm00625700-fdcan-peripheral-on-stm32-devices-stmicroelectronics.pdf
- John
On 4/23/20 3:54 PM, John Rippetoe wrote:
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.
