-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FD-CAN or not... #20
Comments
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>
.
|
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. |
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>
.
|
Andys CoreSTM32F4 is not compiling for F7 variant. Already check that. |
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.
The text was updated successfully, but these errors were encountered: