You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by John Rippetoe <jr...@roboticresearch.com> on 2020/04/23 19:54:30 UTC
STM32H7 FDCAN driver
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.
Re: STM32H7 FDCAN driver
Posted by John Rippetoe <jr...@roboticresearch.com>.
So it sounds like our options are
1. Contact Paul Patience and see if he is willing to donate the code he
wrote to the ASF?
2. Leave the BSD license on the file as is
Is there a preferred order in which these should be attempted? Meaning,
does the ASF have a preferred set of procedures for dealing with
situations like this where 3rd party licenses exist in the code?
Thanks for your help Justin.
Regrds,
John
On 5/1/20 8:33 PM, Justin Mclean wrote:
> HI,
>
> It’s not that every file that gets submitted needs to have an Apache license.
>
> It's only files developed at the ASF by people who have signed ICLAs. If it done by people who have not signed ICLA and it’s a new file, it should also have a ASF headers, but whoever accepts that PR is ensuring that there are no IP issues and takes responsibility for that. For any significant contribution it’s best to get an ICLA from the contributor.
>
> If a file has a 3rd party license header DO NOT change it! Even if it Apache licensed, the header the ASF uses is different to the ones 3rd parties use.
>
> The only case you can change a header is if the file was part of a software grant to the ASF or we have explicit permission from the copyright owner of that file (and there may be several) and it that case it best to get them to make that change for you.
>
> Other projects are not going to have all of these issues as they a) started at the ASF or b) have all committers sign ICLA or similar c) changed the license (and all contributors agreed on that) before coming to the ASF.
>
> Thanks,
> Justin
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.
Re: STM32H7 FDCAN driver
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
It’s not that every file that gets submitted needs to have an Apache license.
It's only files developed at the ASF by people who have signed ICLAs. If it done by people who have not signed ICLA and it’s a new file, it should also have a ASF headers, but whoever accepts that PR is ensuring that there are no IP issues and takes responsibility for that. For any significant contribution it’s best to get an ICLA from the contributor.
If a file has a 3rd party license header DO NOT change it! Even if it Apache licensed, the header the ASF uses is different to the ones 3rd parties use.
The only case you can change a header is if the file was part of a software grant to the ASF or we have explicit permission from the copyright owner of that file (and there may be several) and it that case it best to get them to make that change for you.
Other projects are not going to have all of these issues as they a) started at the ASF or b) have all committers sign ICLA or similar c) changed the license (and all contributors agreed on that) before coming to the ASF.
Thanks,
Justin
Re: STM32H7 FDCAN driver
Posted by John Rippetoe <jr...@roboticresearch.com>.
Well I feel dumb. I just realized that the MCAN from the samv7 is nearly
identical to what is used in the STM32H7. That driver already has an ASF
license plus some of the functionality that my driver is missing. So
perhaps this won't be an issue after all.
John
On 5/1/20 3:37 PM, Nathan Hartman wrote:
> On Fri, May 1, 2020 at 3:30 PM John Rippetoe <jr...@roboticresearch.com>
> wrote:
>
>> I've followed a few of the conversations on here regarding licensing and
>> have been a confused as well. It seems like there are a few options, so
>> I want to make sure I do things right.
>
> I'm not a mentor but it seems to me that if you can get him to sign an ICLA
> then that should eliminate all doubt. But let's wait to hear from a mentor.
>
> Nathan
>
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.
Re: STM32H7 FDCAN driver
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, May 1, 2020 at 3:30 PM John Rippetoe <jr...@roboticresearch.com>
wrote:
> I've followed a few of the conversations on here regarding licensing and
> have been a confused as well. It seems like there are a few options, so
> I want to make sure I do things right.
I'm not a mentor but it seems to me that if you can get him to sign an ICLA
then that should eliminate all doubt. But let's wait to hear from a mentor.
Nathan
Re: STM32H7 FDCAN driver
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
> We did do something similar when we created the arch/arm/src/armv8-m port. It started as a clone of the armv8-m port. We changed all of the headers with only my copyright to Apache 2.0. And all questionable headers we copied over with no change. So I suppose we could generalize in this case well. I would think that the solution would be to bring the CAN file in with the existing BSD header. But let's get confirmation on that.
That is a good way to approach it (but not the only one).
Thanks,
Justin
Re: STM32H7 FDCAN driver
Posted by John Rippetoe <jr...@roboticresearch.com>.
> We might also look to see of there is any of Paul's code in the
> current release. I wrote the original file. Paul, and many others,
> contributed changes to it. I don't recall Paul making substantial
> changes. Perhaps we could quantify that with 'git blame' may there
> is no code left by Paul in the file after all of these year?
>
A quick survey of git blame on stm32/stm32_can.c doesn't show a ton of
changes by Paul, but some of them still exist in my copy. So probably
best to proceed with getting him involved.
John
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.
Re: STM32H7 FDCAN driver
Posted by Gregory Nutt <sp...@gmail.com>.
> I've followed a few of the conversations on here regarding licensing
> and have been a confused as well. It seems like there are a few
> options, so I want to make sure I do things right.
>
> I'll wait for a mentor to chime in when they have a chance. I'm not
> ready to merge yet anyways; I just wanted to get the ball rolling now
> rather than stalling in a PR. Thanks for the help.
We did do something similar when we created the arch/arm/src/armv8-m
port. It started as a clone of the armv8-m port. We changed all of the
headers with only my copyright to Apache 2.0. And all questionable
headers we copied over with no change. So I suppose we could generalize
in this case well. I would think that the solution would be to bring
the CAN file in with the existing BSD header. But let's get
confirmation on that.
We might also look to see of there is any of Paul's code in the current
release. I wrote the original file. Paul, and many others, contributed
changes to it. I don't recall Paul making substantial changes. Perhaps
we could quantify that with 'git blame' may there is no code left by
Paul in the file after all of these year?
Greg
Re: STM32H7 FDCAN driver
Posted by John Rippetoe <jr...@roboticresearch.com>.
I've followed a few of the conversations on here regarding licensing and
have been a confused as well. It seems like there are a few options, so
I want to make sure I do things right.
I'll wait for a mentor to chime in when they have a chance. I'm not
ready to merge yet anyways; I just wanted to get the ball rolling now
rather than stalling in a PR. Thanks for the help.
John
On 5/1/20 3:25 PM, Gregory Nutt wrote:
> I really would like to answer your questions, but I don't understand
> the Apache licensing position. Its seems ad hoc and arbitrary to me,
> at least for cases outside of the most mundane.
>
> Perhaps we can get some direction from and Apache mentor?
>
> Sorry,
> Greg
>
> On 5/1/2020 1:14 PM, John Rippetoe wrote:
>> That's unfortunate. Hopefully he is still reachable at that email.
>> What options should I present to him if I do get in touch with him?
>>
>> John
>>
>> On 5/1/20 3:02 PM, Gregory Nutt wrote:
>>>
>>>> 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?
>>>
>>> You have my permission on that file where I am the sole copyright
>>> holder. I have no idea what to do on the second. It cannot come
>>> into the repository, but I have not heard from Paul Patience in years.
>>>
>>> Greg
>>>
>> 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.
>>
>
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.
Re: STM32H7 FDCAN driver
Posted by Gregory Nutt <sp...@gmail.com>.
I really would like to answer your questions, but I don't understand the
Apache licensing position. Its seems ad hoc and arbitrary to me, at
least for cases outside of the most mundane.
Perhaps we can get some direction from and Apache mentor?
Sorry,
Greg
On 5/1/2020 1:14 PM, John Rippetoe wrote:
> That's unfortunate. Hopefully he is still reachable at that email.
> What options should I present to him if I do get in touch with him?
>
> John
>
> On 5/1/20 3:02 PM, Gregory Nutt wrote:
>>
>>> 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?
>>
>> You have my permission on that file where I am the sole copyright
>> holder. I have no idea what to do on the second. It cannot come
>> into the repository, but I have not heard from Paul Patience in years.
>>
>> Greg
>>
> 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.
>
Re: STM32H7 FDCAN driver
Posted by John Rippetoe <jr...@roboticresearch.com>.
That's unfortunate. Hopefully he is still reachable at that email. What
options should I present to him if I do get in touch with him?
John
On 5/1/20 3:02 PM, Gregory Nutt wrote:
>
>> 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?
>
> You have my permission on that file where I am the sole copyright
> holder. I have no idea what to do on the second. It cannot come into
> the repository, but I have not heard from Paul Patience in years.
>
> Greg
>
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.
Re: STM32H7 FDCAN driver
Posted by Gregory Nutt <sp...@gmail.com>.
> 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?
You have my permission on that file where I am the sole copyright
holder. I have no idea what to do on the second. It cannot come into
the repository, but I have not heard from Paul Patience in years.
Greg
Re: STM32H7 FDCAN driver
Posted by John Rippetoe <jr...@roboticresearch.com>.
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.
Re: STM32H7 FDCAN driver
Posted by John Rippetoe <jr...@roboticresearch.com>.
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.
Re: STM32H7 FDCAN driver
Posted by John Rippetoe <jr...@roboticresearch.com>.
Thanks for letting me know! I was actually following the discussion on
whether to include the G4 in the stm32 folder, so I knew it was being
worked on.
I took a quick look at the G4 reference manual and it shows that they
share identical FDCAN core releases, so the basic stuff should all be
the same. The main difference appears to be in the number of CAN cores
(3 in the G4 vs 2 in the H7) and the amount of message RAM (1Kb per core
in the G4 vs 10Kb shared between the 2 cores in the H7). It also appears
that there is no Time Triggered CAN functionality in the G4. So it seems
like it should be pretty easy for us to collaborate.
- John
On 4/23/20 4:29 PM, Nathan Hartman wrote:
> On Thu, Apr 23, 2020 at 3:54 PM John Rippetoe
> <jr...@roboticresearch.com> wrote:
>> 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
> I haven't yet read your whole email. I will revisit it soon. But in
> the meantime I wanted to mention that I'm working on architectural
> support in NuttX for the STM32G474xxxx family, which also has FDCAN.
> In fact, yesterday, I was working on the pinmap for several
> peripherals, including the FDCAN. My work is in my fork on GitHub, in
> https://github.com/hartmannathan/incubator-nuttx in the branch
> stm32g474. This being a recent addition to STM32's family line,
> perhaps the FDCAN peripherals share some common lineage and maybe we
> could split some of the work to support it. I'm not ready yet, because
> first need to get minimal support up and running, to initialize the
> sysclk and boot up NuttX on my board, but I thought it be helpful to
> mention.
>
> Cheers,
> Nathan
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.
Re: STM32H7 FDCAN driver
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Apr 23, 2020 at 3:54 PM John Rippetoe
<jr...@roboticresearch.com> wrote:
> 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
I haven't yet read your whole email. I will revisit it soon. But in
the meantime I wanted to mention that I'm working on architectural
support in NuttX for the STM32G474xxxx family, which also has FDCAN.
In fact, yesterday, I was working on the pinmap for several
peripherals, including the FDCAN. My work is in my fork on GitHub, in
https://github.com/hartmannathan/incubator-nuttx in the branch
stm32g474. This being a recent addition to STM32's family line,
perhaps the FDCAN peripherals share some common lineage and maybe we
could split some of the work to support it. I'm not ready yet, because
first need to get minimal support up and running, to initialize the
sysclk and boot up NuttX on my board, but I thought it be helpful to
mention.
Cheers,
Nathan