Open bondus opened 4 years ago
Hi bondus, I saw your KlipperToolboard project, it's great and exactly what I wanted to make. Unfortunately, my old hardware version was too buggy and I put it temporary on hold: https://workspace.circuitmaker.com/Projects/Details/Eugene-Krashtan-2/Can2Klipper So now I have only one wrapping board working. Can you please put this change as PR if it was tested and working?
I have 5 working boards and can do scalability and high load testing. Surprisingly the boards worked good enough at the first attempt. It's interesting to see your board, we have made very different design choices but the concept is the same. I am overhauling your CAN code in klipper and canserial, making it more complete and robust. There will be PRs in a while, it's a bit tricky to get it right.
To minimize board size I've used TSSOP-20 chips and two designs on one 50x50 PCB to reduce fabrication cost. Unfortunately, there was some hardware errors. Probably will make another design, but want to use a more powerful chip with a bootloader https://photos.app.goo.gl/bQDJkFZuVNNjKeCX8
Aha, you split heaters/fans and steppers into two boards, it did look a bit strange.
I modified your CAN code in the klipper firmware to be more stable and efficient. Fork at https://github.com/bondus/klipper.
Using a more powerful chip, such as the F103 is a good idea, a proper bootloader would make flashing over serial or even CAN possible. It's pin compatible with the F042 on my board, I'll give it a try.
it did look a bit strange.
Actually, it should fit my new printer design with separate heads (toolchanger with one stepper and many heaters). It not implemented yet.
In Readme.md it states that nodes should use id 0x17F+(2 x PortNumber). Neither the klipper code or this canserial code does that, they use 0x180+PortNumber, and 0x180+PortNumber+1 as a response ID. Since they do not do that "x 2" and the CAN nodes responds to the host using canid+1 there will be ID collisions on the CAN bus if nodes get port numbers next to each other. Collisions leads to all kind of problems.
A very ugly small fix is a change in cansocket.c in ConfigurePort():
Easiest is probably to fix this issue in canserial and leave the STM32 code alone. I will make a better fix...
Are you still planning on maintaining this code? It's been a while since last modification