Remora - Rpi Software Stepping Using External Microcontroller via SPI

Ok, still no go on the octopus.
But I think I have found a working example of what looks like the system_clock for the specific differences between the octopus and the nucleo f446ze,

community.platformio.org/t/nucleo-f446ze...-for-advice/23292/12

github.com/maxgerhardt/nucleo-f446ze-wit...ob/main/src/main.cpp

github.com/maxgerhardt/nucleo-f446ze-wit...fc3c8c44ee47e0086339

Are you using the good remora.c driver ? 

cakeslob wrote:

Ok, still no go on the octopus.
But I think I have found a working example of what looks like the system_clock for the specific differences between the octopus and the nucleo f446ze,

community.platformio.org/t/nucleo-f446ze...-for-advice/23292/12

github.com/maxgerhardt/nucleo-f446ze-wit...ob/main/src/main.cpp

github.com/maxgerhardt/nucleo-f446ze-wit...fc3c8c44ee47e0086339
Hmm, when I use those clock setting in STM32 CubeMX it results in a CPU frequency of 168Mhz, the same as the SKR2.

BTW, the Klipper guys test their STM32F407 code on a 446 by using the 407 binary. Have you tried using the SKR2 bin file on the Octopus?

scotta wrote:

Hmm, when I use those clock setting in STM32 CubeMX it results in a CPU frequency of 168Mhz, the same as the SKR2.

BTW, the Klipper guys test their STM32F407 code on a 446 by using the 407 binary. Have you tried using the SKR2 bin file on the Octopus?

yeah I thought that clockspeed was odd also, I thought maybe it had something to do with USB otg. I just loaded skr2 with my octo config.
It comes out of estop, this is a success we are connected to linuxcnc. Thank you for your work.
Problems - the terminal is outputting all messed up and following errors after a few mm (i am having same issue with skr2 but like 10-20mm i will post it in the other thread)
where do we go from here? Just change up the sk2 system_clock to different clockspeed and use the rest of the octo custom target?

gtt38 wrote:

Are you using the good remora.c driver ? 

I have a few rip builds for each component, I have been trying them all

Yes, if the serial comms is all messed up then this would point to a baud rate error caused by the wrong CPU clock config. 

I've update the LinuxCNC Remora component in the develop branch to allow the PRU chip type to be selected on the command line. This sets up the SPI frequency and chip select behavior for the different chips.

loadrt remora chip_type=STM

Options are lpc, LPC, stm or STM

Doesnt come out of estop for me with the new remora.c with lpc1768 and stm32f407vgt6
Just curious are you using a rpi3 or a rpi4 ?

gtt38 wrote:

Doesnt come out of estop for me with the new remora.c with lpc1768 and stm32f407vgt6
Just curious are you using a rpi3 or a rpi4 ?
 

Hi, thanks for the feedback. I've fixed a logical error in the SPI comms. Tested on LPC1769 and pushed to the develop branch.

I use both RPi3 and RPi4, but use RPi4 for my large printer so as to handle million line g-code smoothly in the Axis GUI.

same for me : Bad SPI payload = f6fdfffd

"stm" is for 168mhz and "STM" is for 180mhz ?

Edit : it works on the lpc1768 but not on the stm

gtt38 wrote:

same for me : Bad SPI payload = f6fdfffd

"stm" is for 168mhz and "STM" is for 180mhz ?

Edit : it works on the lpc1768 but not on the stm

Hi, please download the latest firmware and remora component. I pushed some corrections today and have confirmed on both STM and LPC boards. The "stm" and "STM" is just to make the command line more forgiving and nothing to do with the version or speed of the STM32.