Am 2021-12-27 21:40, schrieb Peter van der Perk:
> Hi Peter,
>
> NuttX has an SocketCAN interface as well. But currently only the Kinetis,
> i.MXRT and S32K1 MCU use this interface for their CAN driver.
>
> There's a porting guide to interface with SocketCAN driver as well
> https://nuttx.apache.org/docs/latest/components/drivers/special/socketcan.html
> https://www.youtube.com/watch?v=1ZwL7OU30xw
> I would advise to use the arch/arm/src/s32k1xx/s32k1xx_flexcan.c driver as a
> reference.
>
> Regarding performance SocketCAN in NuttX is quite comparable to the character
> interface. But as Matt indicate the mailbox filtering is done on software
> level. You could expose the hardware filters using a ioctl just like the
> character driver though.
>
> I'm not sure which STM32 part you're using but NuttX already has some CAN
> drivers in place (albeit the NuttX character driver). It should be fairly
> simple to modify these driver and make it compile time configurable to use
> the character device interface or SocketCAN interface.
>
> Kind Regards,
>
> Peter.
>
> -Original Message-
> From: Matthew Trescott
> Sent: Monday, 27 December 2021 20:35
> To: peter.m...@mnet-mail.de
> Cc: dev@nuttx.apache.org
> Subject: [EXT] Re: SocketCAN for STM32 ?
>
> Caution: EXT Email
>
> Hi Peter,
>
> I haven't worked with NuttX's SocketCAN implementation or STM32, but I did
> write a "classic" char-device CAN driver for the Tiva MCUs. The reason I
> wrote a char-device driver is because the char-device CAN subsystem has
> ioctls for things like hardware message filtering and the interface supports
> (IIRC) hardware transmit FIFOs if desired. It's possible those features
> aren't relevant with 100+ MHz MCUs, but I imagine there are use-cases where
> it is. I also found that on the Tiva hardware it is difficult to make use of
> the hardware FIFO capability because you still need to get an IRQ for each
> message to handle bus errors, lost arbitration, etc that an application might
> be interested in.
>
> It's not that the SocketCAN implementation _couldn't_ support those hardware
> features. It just doesn't yet.
>
> Without looking at the Zephyr code, my guess is that it's probably not
> complicated enough to be worth trying to outright port. It would probably be
> just as easy if not easier to write an STM32 SocketCAN driver for NuttX and
> just use the Zephyr one as a reference. Just my (somewhat uninformed) 2¢
> though.
>
> Kind regards,
> Matt
>
> On Sun, Dec 26, 2021 at 12:39 PM Peter Marx wrote:
>
>> Hi,
>> I have seen Peter Van Der Per's great port of SocketCAN to NXP MCUs. On
>> Zephyr there is a SocketCAN for STM32 implementation. I am not deep enough
>> in C business to judge how difficult it would be to port that to Nuttx.
>> Is some insider here around who could comment or maybe works on it already?
>>
>> BR,
>> Peter
Hi Peter,
first: sorry for misspelling your name - I had copied it from the
YouTube video intro where it was also misspelled. Exactly that video
brought me here.
I was flashed by the idea of having SocketCAN on a MCU, getting the
benefits you list in the video - for me CANopen
I am looking for CANopenNode STM32 stack alternatives as I am unhappy
with its application API - it is not well explained for "consumers" and
several requests for app examples over the years from different people
were unheard. I found better alternatives like
opensource.lely.com/canopen/ , but that expects SocketCAN...
My preferred target would be STM32L432KC, maybe also STM32F103.
FlexCAN would not be a requirement for me. "FD" is only on STM32G0
Series, STM32G4 Series, STM32H7 Series, STM32L5 Series, according to a
STmicro Application Note (AN5348).
For L432 I see a can driver at arch [1]/arm [2]/src [3]/stm32l4/ I
this just the lower end and would need either a char-device driver or
SocketCAN driver on top of it ?
When looking on the flexcan driver link you posted, my hope vanishes to
understand all the details. I did embedded C coding decades ago and
today i have some practice in Java/IoT coding. For object oriented guy
like me it is hard to see in driver code the line where functionality
touches the underlying hardware. I have no problems to digest 800 page
MCU manuals, means on the register level I am fine. It is just that
middleware area above, where it is really hard to learn the concepts. It
is a sort of art, I must admit.
Not sure how to proceed - any other idea ?
Best Regards
Peter
Links:
--
[1] https://github.com/apache/incubator-nuttx/tree/master/arch
[2] https://github.com/apache/incubator-nuttx/tree/master/arch/arm
[3] https://github.com/apache/incubator-nuttx/tree/master/arch/arm/src
