Remora - Rpi Software Stepping Using External Microcontroller via SPI

Cncninja wrote:

well let's do it, what do you have so far and where can i add to it?
 

I've uploaded my non-PRU version.
github.com/mhelmarc/Jaqueza-NC
Same issue, I can't figure out yet.
When coming from e-stop on first run
it goes idle but it works the on the second press of e-stop.

My observation is:
On first run after pressing the e-stop button on Axis, only the header PRU_READ
is sent and no payload. The controller assumes that there's data so it set SPIdata to true.
So the main loop try to change the state to ST_RUNNING, but there's actually no data
and becomes a sequence of errors so it goes idle again.
Still trying to figure out how to fix it, but other than that it seems stable.

Hi thanks I’m gonna try. But can you upload the modded lib too ?

github.com/mhelmarc/stm32plus/commits/musings

So I was using the good one 
let’s try

yes, it's all set up on a 1.4turbo I have TMC drives and 8822.

After a quick try, it works pretty good. Good job Mhel ! The good thing with your code is that it could be easily ported to F1 and F0 with this library. The bad thing is a lot of modifications of the library are needed if you want to port to F0/F1.
For the E-stop I had the same issue.

Great, now try to figure out the E-Stop problem.

@Cncninja
I'm confused I thought you already have an STM32 hardware,
a quick search shows your Turbo board is based on LPC176x ?

gtt38 wrote:

 

Most 3D printer board manufacturers don’t use the right pin mapping of the chip. The chip is using software pwm to generate steps if the pin is not hardware pwm. I’m trying to use P2.0 to P2.5 for step generation with good results.
The step generation limitation could come from the SPI communication too slow maybe.


 

SPI comms runs at the Servo Thread frequency and it passes the required step frequency. All steps are generated in the Base Thread, which is the limiting factor.

BR
Scott

mhel wrote:

Cncninja wrote:

well let's do it, what do you have so far and where can i add to it?
 
I've uploaded my non-PRU version.
github.com/mhelmarc/Jaqueza-NC
Same issue, I can't figure out yet.
When coming from e-stop on first run
it goes idle but it works the on the second press of e-stop.

My observation is:
On first run after pressing the e-stop button on Axis, only the header PRU_READ
is sent and no payload. The controller assumes that there's data so it set SPIdata to true.
So the main loop try to change the state to ST_RUNNING, but there's actually no data
and becomes a sequence of errors so it goes idle again.
Still trying to figure out how to fix it, but other than that it seems stable.

Hi, 

Great to see some further work on the STM32 version. Just curious, what makes this a non-PRU version?

Thanks
Scott

scotta wrote:

 what makes this a non-PRU version?

Hi Scott,

technically it is still programmable
I thought the idea of PRU is re-programmability without actually
re-compiling the source. Unlike my other attempt the non-PRU
has all the configuration hard-coded. As the library used is
heavy on templates which as I found out only works at compile time.