Remora - Rpi Software Stepping Using External Microcontroller via SPI

Bari wrote:

You'll run out of memory if you try to run the full LCNC on an STM32. Not to mention needing to run it headless.

There was someone that got it running about 10 years ago on an ARMv5 or v6 with a few hundred megs of RAM.

code.google.com/archive/p/miniemc2/downloads
 

i have 1go on my board but its definitly not coming from the memory. i suspect the CPU/GPU...

So Printf is working now ! lol I m focus on the bootloader of the SKR2, i m trying to change it for a better one. i found this repo :
github.com/akospasztor/stm32-bootloader
it s originally a L4 bootloader but it s easy to port it to F4.
 

scotta wrote:

A quick update. I've just got a test SPI DMA slave running on the STM32 SKR2 board. LinuxCNC comes out of E-stop!

I think I'm going to like the STM32 version of Remora when the port is complete. The SPI comms are now running x4 faster (25Mhz) than on the LPC1768. The SPI actually pre-loads the buffers so we don't need hit the E-stop button twice to get the comms loop back active.

I'm also proposing to alter the SPI checking logic as we can now use the Slave Select line, via EXTI interrupt, to trigger the DMA transfer and packet checking. This will increase the noise tolerance on the SPI even more.

One step closer...
 

Did you update the repo ? 25Mhz is the best news of the day !

For those interested, I've updated the repo with a working SPI DMA Slave example. There is no SPI error checking yet, but you will see the slave select rising edge interrupt which will trigger the checking routine eventually. Not that I've seen an error on the SPI as yet and it's run for days. Much more reliable than with the LPC1768.

There is also a new version of the LinuxCNC Remora component which uses a different SPI transfer function and that for the LPC176x.

I've been battling with the DMA interrupt routines jumping to wrong code. Root cause was needing to use NVIC_SetVector to point things in the correct place. Something which is not needed with using STM32 HAL which I ported the code from.

Het Scotta update for the Linux side or the sd card in the skr1.4t board? also, is the tmc driver support for SPI or uart drives?

Thank you

Hi, the SKRv1.4 is supported by the master branch. TMC2209 under UART are supported. I've started on an SPI based version for the other TMC drivers but I've been so happy with the 2209's that I've focused on the STM32 port of Remora. LPC1768 boards are nearly impossible to get now.

i am interested in the stm32 port.
do you think it will be better than the LPC based on speeds and chip features?

Hi Scotta, sorry I meant you comment

"There is also a new version of the LinuxCNC Remora component which uses a different SPI transfer function and that for the LPC176x."

is this for the Pi side or sd card side,

thank you

Aaroncnc wrote:

i am interested in the stm32 port.
do you think it will be better than the LPC based on speeds and chip features?

The STM32 port will be based on the same code base, just like Rommel has done. So the higher clock speed of the STM32F407 will be the only advantage. We'll be able to play with some higher step speeds.

Cncninja wrote:

Hi Scotta, sorry I meant you comment

"There is also a new version of the LinuxCNC Remora component which uses a different SPI transfer function and that for the LPC176x."

is this for the Pi side or sd card side,

thank you

It's slightly different in the LinuxCNC Remora component as the STM32 has a different Chip Select logic (better IMO). I've run the board for days now without a hint of errors on the SPI bus.

On the STM32F4 side, yes there will be a different module for access the SD card. On the SKRv2 the SD card is on the SDIO interface rather than an SPI interface. There is no out of the box Mbed support for the SDIO interface but I've managed to read in the config.txt this week. It just interfered with the the SPI comms for some reason.. working this one out. One step at a time...

scotta post=220174 userid=24854

Aaroncnc post=220009 userid=24455i am interested in the stm32 port.
do you think it will be better than the LPC based on speeds and chip features?
The STM32 port will be based on the same code base, just like Rommel has done. So the higher clock speed of the STM32F407 will be the only advantage. We'll be able to play with some higher step speeds. 

But the STM chips have more than just speed correct?
From some of the sheets it sounds like there are more abilities for high speed encoders up to 4 vs the lpc 1.
I understand its early in dev but looking long term would the stm32 variant win out so to speak.