Remora - Rpi Software Stepping Using External Microcontroller via SPI

I will be more than happy, to share something I know how.
meanwhile, I added your suggestion to .hal file. did not work.
   

Ok, thanks Viren.


Hmm that is odd for sure. I am only using RPI4. I dont know exactly the difference between RPI3 vs RPI4 in regards to SPI

What board are you using with your setup? I dont think it should matter, but just wondering

Also, how long is your cables?
I had to use shorter cables than I normal (3d printer boards I was using around 100-130mm) with my nucleo setup, I had to use less than 100mm cable length.

ok, just to have our bases covered
- leave the base_freq entry in hal regardless, we need that for the nucleo repo
- test with axis gui, (shouldnt be any different but lets make sure)
- try the flexi-hal RPI4 image, that one should positively work software side.
- copy the comp from your RPI 3 setup. I dont think Ive made any changes since you first installed, but just double check

Re compiled,
Re halcompiled remora.c.
All working in RPI 3B.
Changed the Dupont cables for 100 mm.
Just to check I intensely pulled MOSI cable from RPI 3B, same result as I have with RPI 4B.
Estop comes out but on jog jont 0/1 error.

So all in all I had fried my pin 19(MOSI) in RPI 4B.

Now I will have to wait for ethernet branch!

That is unfortunate to hear viren. At least you could reproduce the error...

You might have better luck changing the linuxcnc component to use RPI SPI1 instead

pinout.xyz/pinout/spi

Hello, just thought I would share this project based on Remora for STM32F103C8 (blue pill).
github.com/iforce2d/weenyPRU

Most of the component side is as for Remora, the firmware is written from scratch except for the DDS section. It uses STM32 HAL and is quite narrow in scope compared to Remora, there's no nice way to change settings and no considerations for other microcontroller targets.

The idea was to see how far I could get with a lowly blue pill, and how small and cheap a LinuxCNC build could be and still have reasonable performance. I'm building a little solder bot that fits on an A4-size paper, and it seemed silly to have a big PC twice the size of it to run the controller. I want to use a PiZeroW, first I tried software stepping but that was pretty slow, so I started searching for SPI based methods and discovered Remora. With an external PRU the ZeroW actually holds it together pretty well, at least when not also running the GUI.

Anyway, the blue pill works but made for an awfully messy wiring setup, so I designed a PCB to keep everything tidy. Some info about that here if anyone is interested: 

Hey iforce2d, lookin good. I am interested to see your PCB for this. Ive started working on a cheap RPI shield to work with the STM32 bluepill and blackpill as well.
I am interested in poking around your repo though, to see whats going on. I like the analog in.

If you are interested in working with mainline remora, Ive made a bluepill/blackpill repo. I havent made an SD card version yet, but I can cook one up if you are interested, although you seem capable enough on your own.
edit, right, removing the sd was the only way i could get it small enough for the firmware

github.com/cakeslob/Remora/tree/blackpill

This is why I love opensource projects. Great work iforce2d. With the ZeroW how are you implementing a GUI?

@cakeslob I shared the next revision PCB design here (click Editor Open to view and edit): oshwlab.com/iforce2d/stm32-pru_copy

That's actually a modified design to what I showed in the video, as yet untested. I ordered some new boards and once I've confirmed that my changes are ok I'll add this to the github readme. fwiw the changes are:
- fix the need for bodge wire seen in the video
- replace TXB0108 level shifter with 74HCT541
- rearrange so that PA9/PA10 (for UART1) are not connected to optocouplers
- link the UART pin of all stepsticks together, to allow Trinamic 'single wire interface' settings for motor drivers
- add a few more solder pads for GND, 5V, VMOT

Regarding the setting of options, it seems to me that this might be possible via HAL files, eg. use a separate .hal file that causes the LinuxCNC component to fill messages with different information, and the firmware to interpret incoming messages differently. Each message would of course include a flag to denote which type of message it is. To change settings, the secondary .hal file (containing a 'setp' to set the message mode) would be included in the .ini file. In settings mode the PRU would simply read settings and store them to EEPROM or some other onboard storage. For normal usage, comment out the settings .hal line from the .ini file. Each configurable setting would need its own 'pin' in the HAL configuration, and the component could cycle around all settings in turn, sending one per message so that the number of settings can grow in future without needing a larger message size. The firmware could reply with the normal response to keep the connection going and avoid e-stop... I guess. Admittedly I haven't really thought this idea through much, so perhaps there is some problem I'm not foreseeing, but I can elaborate on the details more if it sounds interesting.

@scotta First, thanks for all the effort you put into this, not least of which being decent documentation - I know how that can be a pain in the ass
I have two intended use cases for this in the near future, neither of which actually need any GUI.

The first is a little soldering bot which will do the same job over and over, so the main interaction during the course of normal operation is just to press start after placing another PCB into it, this will be a hardware HALUI button. Initially after a power up, it will need to be enabled and homed which I will do via my g-code server but that will not be very often. Occasionally it will need to be jogged into the starting position with HALUI joystick and rotary encoder, then another HALUI button to touch off.

The second application is as a back-end for the OpenPNP pick-and-place controller, so again no GUI is needed. OpenPNP will issue g-code commands over the network as if it were talking to a more typical 3d printer style firmware, which seems to be common with OpenPNP users.

The g-code server was loosely based on linuxcncrsh, you can find more info about it here: github.com/iforce2d/linuxcnc-gcode-server
Demo video of the headless operation: 

What are you using the message section for right now?

Also can you elaborate on your decision for 74HCT541 over TXB0108? I am working on that part, if its dedicated outputs that makes sense but I am just wondering

By "messages" I mean the information passed between LinuxCNC and the microcontroller over the SPI connection. For example LinuxCNC sends (among other things) the desired motor movement and which digital outputs should be on, and the microcontroller sends back the current motor positions and which digital inputs are on, etc. These messages are exchanged at (typically) 1kHz continuously, always with the same message content, about what is happening in the current 1 millisecond time slice.

But the message content could be anything, including settings for the microcontroller. You probably would not want to send settings all the time because it takes up SPI bandwidth, is not really necessary, and some settings might require the microcontroller to be restarted. So I think the settings would need to be saved in some kind of storage onboard the microcontroller. As for how the user can define the settings, the .hal files give us a way to set a large number of arbitrary values that will be accessible to the LinuxCNC component, which can pass them to the microcontroller.

To look at a concrete example. the first thing I would find this useful for is setting the current of the TMC2209 stepper drivers I'm using, which the microcontroller can do via UART. In my .hal file I might have something like:

The first line would instruct the HAL component to send config messages instead of the normal messages, and the subsequent lines give the values of whatever needs to be set. It would be also possible to switch between config messages and normal messages at run time, although I'm not sure how practical that is. At some point the microcontroller will need to write the settings to storage, which is slow and might cause the SPI connection to drop, but that's not a big problem.

To be fair, I am probably making this sound easy because I'm only looking at one specific microcontroller and I'm basically making my own PCB to run it on so adding extra components like flash storage is no big deal. Whether something like this would be practical to try on the wide range of existing boards that Remora supports is a completely different story. I'm also just outlining an idea I came up with a few hours ago and have never tried, so it could all go badly wrong when I eventually try it out

About the level shifter decision, to be honest I don't know much about these. I forget how I came across the TXB0108 but I just can't get it to work  at all, and I've seen a lot of people having problems with it. Somebody suggested 74HCT541 in the comments of my video, so I'm just trying that next. Apparently the 74HCT541 only does translation in one direction which hopefully makes it easier to work with... fingers crossed.