This CanOpenNode Library is totally out of date

[pirupic]

I have the feeling that this CanOpenNode library is not linked to the CanOpenNode project so the library is totally out of date compared to the original one.

It is a pity, we are missing all the important improvements and updates.

[CANopenNode]

I don't understand the issue. Did you check git history? What is wrong?

[pirupic]

I am Sorry for my comment it was an error

I wanted to post in this repository,
https://github.com/CANopenNode/CanOpenSTM32
It is the repository for the STM32 microcontrollers
the library seems to be a copy, not a link to the CanOpenNode lIbrary.
I though I was posting on that forum.

Sorry Again

[CANopenNode]

No problem. CanOpenSTM32 is currently poorely maintained. It is not updated to the latest version. Recently CANopenNode changed a lot - rewritten to follow some misra rules and reformatted. But it should not be hard to update CanOpenSTM32 to the latest version anyway.

As I know, CanOpenSTM32 is not in so bad condition. Latest maintainer added much, but is currently not very active. Is I know, main problem is still with CANsend with larger bus load.

I wish, I have more time to fix things in CanOpenSTM32 too.

[RoxerRN]

Hi guys,

Just to let you know that I managed to set up a board with an stm32f303 with CAN and another board with STM32u599 and canfd.

I used the CanOpenSTM32 and the last version of CanOpenNode, it worked out of the box without any troubles.

But can you please elaborate a bit concerning the problems with the large bus load on stm32 ?

[CANopenNode]

Did you run CANFD and message larger than 8 bytes? Driver would need to be implemented for that. PDO should be already able to handle long CANFD messages.

I didn't check STM32 driver. There are complains when several TPDOs are used. I suspect driver, cansend, tx interrupt. STM32 have 3 hw cantx buffers, driver uses 3, as I know. But I would recommend using only one, as I did with PIC32. There is no need to use three, it just adds complexity and problems.

[mlout]

Just to let you know that I managed to set up a board with an stm32f303 with CAN and another board with STM32u599 and canfd.

I used the CanOpenSTM32 and the last version of CanOpenNode, it worked out of the box without any troubles.

I can confirm the latest CANopenNode also works using a STM32F3DISCOVERY board (which also uses the STM32F303).
I have added a PR to update CANopenNode in the repository and add an example project for the above mentioned board (CANopenNode/CanOpenSTM32#73)

[RoxerRN]

Did you run CANFD and message larger than 8 bytes? Driver would need to be implemented for that. PDO should be already able to handle long CANFD messages.

I didn't check STM32 driver. There are complains when several TPDOs are used. I suspect driver, cansend, tx interrupt. STM32 have 3 hw cantx buffers, driver uses 3, as I know. But I would recommend using only one, as I did with PIC32. There is no need to use three, it just adds complexity and problems.

No I didn't run can FD by now I just used regular CAN 2.0B with a CAN FD peripheral of the STM32 and it worked out of the box. But it's planned, I will implement the FD driver.

About the mailbox I modified STM32CanOpenNode driver to use only 1 mailbox for sending and it work well with multiple PDO.

Now I struggle with the SDO client, it work but sometime SDO are not sent and I get a timeout, I suspect problems with the CANsend or CANreiceive function (maybe problem with RX mailbox in the driver? ).

Do you have some insights about the SDO client ?

[CANopenNode]

SDO client in https://github.com/CANopenNode/CANopenLinux works without any detected problems, also with very large data. See https://github.com/CANopenNode/CANopenDemo/blob/master/test/test_report.md#sdo-transfer-test-reports-for-different-target-systems

[RoxerRN]

Hi Janez, you are right SDO client work very well now. The error encounter was due to a misbehaving node, the bus was overload because of too frequent sdo access. Thank you for your answer.

[CISSOIDjmr]

Can't this issue be closed (the discussion looks finished, the title is misleading and the original poster even said that the issue creation was a mistake) ?