FD-CAN or not...

[ArkadiuszRaj]

First of all thx!!!! After dowloading gcc-arm-none-eabi-10-2020-q4-major-aarch64 onto my little ARM machine, compilation of RRF works smoothly.

Now The Part To Discusss.

Duet3 uses CAN. Hardware-wise it is prepared for another standard: FD-CAN.
With current PrntrBoardV2 update there is simple CAN interface, not the flexible data-rate alternatve.
I mean both STM32 and the TJA chip supports CAN up to 1 or 2 Mbps.

Personally I do not believe that FD-CAN is really needed to adress hotend board and sychronize extruder steps with other kinematics. But I have started to think. For whole planned Duet CAN' ecosystem maybe it is worth to use FD CAN. But it is not so easy to get such a chip from STM32 family.

What can I do? While awaiting for the prototype of my variant, I will most probably buy Duet 3 Toolboard 1LC and give it a try. I mean will try to connect it via old school CAN.

If this will work, that will be superb.
If not - then I guess switch to STM32H7 would be necessary.

With this issue I wanted to make you aware of my doubts on this topic.

[ghent360]

That seems like a problem. The all Duet3 boards seem to be CAN-FD and I can see in the code #if USE_NEW_CAN_DRIVER <can fd stuff>. The main issue is that can-fd supports 64-byte data messages, where can is only up to 8 and the RRF code does use messages longer than 8 bytes. I don't know if these are broken into smaller chunks and re-constructed in the "Old driver" code. But even if that is so, you will have to re-compile the expansion firmware with different settings and hope it still works. ~V

…

On Sat, Jan 30, 2021 at 2:47 PM Arek ***@***.***> wrote: First of all thx!!!! After dowloading gcc-arm-none-eabi-10-2020-q4-major-aarch64 onto my little ARM machine, compilation of RRF works smoothly. Now The Part To Discusss. Duet3 uses not CAN. Hardware-wise is prepared for another standard: FD-CAN. With current PrntrBoardV2 update there is simple CAN interface, not the flexible data-rate alternatve. I mean both STM32 and the TJA chip supports CAN upt o 1 or 2 Mbps. Personally I do not believe that FD-CAN is really needed to adress hotend board and sychronize extruder steps with other kinematics. But I have started to think. For whole planned Duet CAN' ecosystem maybe t is worth to use FD CAN. What can I do? While awaiting for prototype of my variant, will most probably buy Duet 3 Toolboard 1LC and give it a try. I mean will try to connect is that to CAN. If this will work, that will be superb. If not - then I guess swicth to STM32H7 would be necessary. With this issue I wanted to make you aware of my doubts on this topic. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#20>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6FRVQIUG7IYOHTZ4K5S2LS4SD7NANCNFSM4W2XOBUQ> .

[ArkadiuszRaj]

CAN frames are not interchangable, what I ment was using FD-CAN in CAN 2.0 compatibility mode. New message format in CAN 2 network will be seen as error.

Well, the first and the most important step is to port CAN communication to STM32 which as I understand is not yet done.

As for Today, RRF support clasical CAN and FD-CAN that comes either from CoreN2G (we do not use) or as driver from hardware "abstraction" for SAME7 mcpu. My idea was to go into drirection to create other driver.

[ghent360]

Yes you can create a driver based on the CAN 2.0 hw in the STM, but I don't think it would be able to talk to Duet3 Toolboard and the likes. Migrating RRF to STM32F7 should be doable, there is not that much F4 specific code even though the repo is called CoreSTM32F4. Most of the code works through the Arduino core library, which has been ported to F7. The Arduino core just works over the HAL or LL code layers from ST micro. Supporting H7 is a different story, the chip internal structure is much more complicated than the F7 with multiple busses and power domains. I would probably just wait for Frederic from ST to complete the arduino port. btw. you can contact me at ghent360 at iqury.us

…

On Sat, Jan 30, 2021 at 11:00 PM Arek ***@***.***> wrote: CAN frames are not interchangable, what I ment was using FD-CAN in CAN 2.0 compatibility mode. New message format in CAN 2 network will be seen as error. Well, the first and the most important step is to port CAN communication to STM32 which as I understand is not yet done. As for Today, RRF support clasical CAN and FD-CAN that comes either from CoreN2G (we do not use) or as driver from hardware "abstraction" for SAME7 mcpu. My idea was to go into drirection to create other driver. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6FRVUAWEZFARAFZ6TKWATS4T5XNANCNFSM4W2XOBUQ> .

[ArkadiuszRaj]

Andys CoreSTM32F4 is not compiling for F7 variant. Already check that.
But you are right, that is why I am focusing on building bulid scripts to utilize Arduino_Core libarry rather the Andy one.