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 <matthewtresc...@gmail.com> > 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 <peter.m...@mnet-mail.de> 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
