Add spi0e bus for rp2040, used on pitb v2 by fysetc #6683
Conversation
|
Hi, Good job and thanks a lot for the help, but DECL_ENUMERATION index number for spi1a/b/c must be incremented, no? |
|
Good catch, totally didnt even see that, I'll add a fix shortly :) |
|
I'm far from a klipper expert, mostly just stumbling around until i got it working, buut, with that said, I think you need to make sure you've got the PR checked out, and flashed to the PITB for this to work, for example, mine the version looks like this: Take a look at this: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally guide for how to get the pr locally if your unfamiliar, and ignore all this if you did that already and I'm just missing something because it worked fine for me Here is a sample of mine, I've successfully homed my x/y, though my printer is still otherwise in pieces, it shows the spi bus working on the PITB: *Edit: Also, your log shows this further your log shows and mine has: Notice, that it is missing spi0e, which corroborates that you have not flashed this PR further. |
|
Thanks for your attention. I'm a bit flawed. I must have missed something, I updated everything including the linux process, to "new version" but... I'll do it again based on your git. for a clean installation, Thank you very much.
yes, my defect or my files, with clean files, no spi0e error :D S2 klippy (3).log |
|
Thankyou for submitting a PR, please can you sign off your as mentioned in point 3 in https://github.com/Klipper3d/klipper/blob/master/docs/CONTRIBUTING.md#what-to-expect-in-a-review Thanks |
Hi James, I think I got that message in there properly, and squashed all my non-sense, so the upstream repo stays clean :) |
|
I think my code should meet all the stuff in the contributing doc.
|
|
Have you try sensorless ? |
|
I have not, but this is more about the communication bus than the tmc driver implementation, so I cant see why it wouldnt work. I have no use for sensorless homing on my printer. |
|
I don't want to abuse it, I know you've already done a lot, and I thank you, I would like to ask you for the pinout.cfg file, so I can make it as similar as possible, because I may be making a mistake in something, like before when there was no pitb update, shameful, but... Otherwise, I thank everyone for everything. Long life and prosperity. S2 |
Hi @ejhoness I did post my config for the motors above in the original PR, but if you read through your log, it will start connecting the various MCU's you have on your printer. In that look for your PITB, and it should list the various SPI and I2C busses it has, if it isnt listing the spi0e bus, then something went wrong with compiling and flashing this change to the mcu. You shouldnt need to reflash all your mcu's if your on a recent klipper version otherwise, but make sure the PITB is flased with this. I basically made sure my klipper/src/rp2040/spi.c had the 6-7 lines updated if you look on the files changed tab here, you can match it up, its a fairly small code file. Then in the main klipper folder I did: This assumes you have it setup with katapult as your bootloader already (following something like esoterical's canbus guide for example), so you can flash over canbus. You obviously need to setup the menuconfig properly for the PITB, like this (again assuming katapult!):
Finally you need to make sure the canbus ID in my snippet above is accurate mine is eda86b2923a2 Once youve done this all, then check your klipper log for something like: the really important key here is: if that's not listed, then it didnt include this code change, and thus, you cant use the hardware spi configuration that is needed for the mcu processor to actually talk to the TMC drivers to control your motors. Software spi should work, but I didnt dig into why it actually doesnt, I could probe it and figure it out, but really hardware spi seems superior to me in every way I can think of, why emulate it in software if I dont need to... Hopefully that helps, I know this is pretty nitty gritty embedded programming stuff that even I dont deal with often, as I'm more an enterprise software dev in my daily life. Here is a complete snippet (including random commented out old crap etc) of everything in my code related to the PITB, just for posterity, im currently only using it for the A/B motors in my voron 2 (x/y in config), and a few thermal probes, but it is working fine: |
|
Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html There are some steps that you can take now:
Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available. Best regards, PS: I'm just an automated script, not a human being. |
|
Thanks. We can add this, but we've given up on introducing names like "spi0e". The new scheme is to use names like "spi0_gpio4_gpio3_gpio2" - see src/stm32/spi.c for examples. Separately, I agree the spi (and i2c) interface would be better if the pins were passed as parameters explicitly from the host (instead of using these weird bus names). (Something like what src/atsamd/sercom.c does.) Something to look at refactoring in 2025. Cheers, |
|
Thanks for this - got mine working, appreciate the effort undertaken |
|
I can look in a day or two at renaming the buses using the 'current' ("spi0_gpio4_gpio3_gpio2") format, but I definitely dont have the cycles to refactor it like the atsamd example sadly. I'd be somewhat worried about this breaking a bunch of config files though, at least the approach i used is backwards compatible... whereas if its renamed, anyone using spi0d etc would need to update to the new name, and they seem rather poorly documented imo, I had to come to the spi source to figure it out, and why it wasnt working. edit: or were you suggesting I just add the new spi0e bus as the new format, and leave the existing ones named as is? |
Introduce new using the new format. It'd be nice to also add new definitions for the existing buses in addition to the existing definitions. See -Kevin |
|
I will take a look when I have a few minutes, that sounds like a reasonable approach! |
|
I've started working on using the new naming convention, I was going to look at all the permutations of buses, but i think its unwieldy, and without re-writing to a more dynamic approach, doesnt seem appropriate, its fairly easy to add a new bus as needed, if a board is released using something new and odd. |
|
Hey there, can you confirm if this Katapult config looks correct, or did I miss anything. When I make this and flash it to my PITB v2.0 over USB, it flashes successfully. Then I power off and disconnect USB, connect the CAN Bus cable, and when I power up, all three red LEDs on the PITB light up solid, and the PITB isn't found when I run the CAN Bus query from the command line. |
|
Figured out why. I hadn't jumpered the pins that switch the PITB between CAN FD and CAN operations, and so it was defaulting to CAN FD. Once I jumpered those pins, the CAN query was able to return the UUID, and I was able to flash Klipper. |
Please don't make help requests in a PR. The correct place to ask questions like this is the Klipper Discourse forum. |
|
I did update this with the new bus name styles, but I want to do a bit more testing, however my printer had a hardware failure, so until I get parts I'm stuck. Hopefully the slow boat gets here soon :) |
|
I've been running this now for a week without any issues, and other than the change below needed in the config I'm happy with how its working. |
|
Thanks. In general it seems fine, but I don't think we should add a new old-style "spi0e" name. The new mapping should be available solely as "spi0_gpio4_gpio3_gpio2". -Kevin |
The Fysetc PITB V2 board uses a spi bus config that is supported by the RP2040 chip, but not klipper, so this adds the relevant config to the file to allow you to run the tmc5160's on the board via hardware SPI. This resolves the issue of software spi not working on this board, which I was unable to fully understand. I have also seen other users encounter similar bus config issues with the rp2040 setting up things like accelerometers and such with this pin layout. As requested, this also uses the new convention for spi bus naming, while maintaining the old bus names for compatibility. Signed-off-by: Jessica Hunt <[email protected]>
|
Sorry, that was a oversight! Should be removed now. had it on a couple printers and hadn't changed everyone's config file ;) |
|
Thanks. -Kevin |
…pper3d#6683) The Fysetc PITB V2 board uses a spi bus config that is supported by the RP2040 chip, but not klipper, so this adds the relevant config to the file to allow you to run the tmc5160's on the board via hardware SPI. This resolves the issue of software spi not working on this board, which I was unable to fully understand. I have also seen other users encounter similar bus config issues with the rp2040 setting up things like accelerometers and such with this pin layout. As requested, this also uses the new convention for spi bus naming, while maintaining the old bus names for compatibility. Signed-off-by: Jessica Hunt <[email protected]>
…pper3d#6683) The Fysetc PITB V2 board uses a spi bus config that is supported by the RP2040 chip, but not klipper, so this adds the relevant config to the file to allow you to run the tmc5160's on the board via hardware SPI. This resolves the issue of software spi not working on this board, which I was unable to fully understand. I have also seen other users encounter similar bus config issues with the rp2040 setting up things like accelerometers and such with this pin layout. As requested, this also uses the new convention for spi bus naming, while maintaining the old bus names for compatibility. Signed-off-by: Jessica Hunt <[email protected]>
…pper3d#6683) (Klipper3d#452) The Fysetc PITB V2 board uses a spi bus config that is supported by the RP2040 chip, but not klipper, so this adds the relevant config to the file to allow you to run the tmc5160's on the board via hardware SPI. This resolves the issue of software spi not working on this board, which I was unable to fully understand. I have also seen other users encounter similar bus config issues with the rp2040 setting up things like accelerometers and such with this pin layout. As requested, this also uses the new convention for spi bus naming, while maintaining the old bus names for compatibility. Signed-off-by: Jessica Hunt <[email protected]> Co-authored-by: Jessica Hunt <[email protected]>
I purchased the fysetc PITB v2 board, which is not functioning via software spi, and I'm not 100% sure why.
The issue with hardware spi, is that this board is wired such that:
SCK: gpio2
MOSI: gpio3
MISO: gpio4
however, the spi0 configuration currently in the klipper codebase, only allows an spi permutation of:
SCK: 2
MOSI: 3
MISO: 0
However, that said, I've seen a few cases around the internet in troubleshooting this, that show people using the rp2040 spi bus configured this way, as well as the PITB v2 board. The rp2040 datasheet (page 13: here) shows it as a supported configuration, so I added spi0e as an option, and everything now started up and works.
I'd almost suggest perhaps a more configurable way of managing these spi buses for this chip, as many gpio can be used for spi0 for example, but I'm not familiar enough with the klipper code to realize it. This solved my immediate issue so I offer it up for the masses to accept or not :)
Once this is done, the config looks like this for that board: