Remora for RP2040

Bari got me thinking about porting Remora to the RP2040 (Raspberry Pi Pico) so I ordered a Wiznet W5500-EVB-Pico evaluation board to take with me while travelling for work. $21 AUD later and only a few days local shipping it had arrived.

So, first weekend OS killing some time, the toolchain is installed and the Ethernet UDP communications is up and going. I don't have a Linux machine with me so I might have to try a virtual machine to see if I can test the comms with the LinuxCNC component.

Next step is to figure out the best approach for the thread timing. The RP2040 alarm system looks a bit clunky so another method of generating precise interrupts will be needed.

github.com/scottalford75/Remora-RP2040-W5500

Hey Scott. The rp2040 port of Grblhal uses the PIO to generate the step interrupt as well as the step waveform. It has less IRQ overhead than pure software stepping and the step generation is well suited to the fixed interrupt timing of remora.

github.com/grblHAL/RP2040/blob/master/driverPIO.pio#L8

I think there is a good solution using PWM wrap interrupts. Basically using the hardware PWM modules (slices) as a timer as each slice can generate a wrap interrupt.

Need to convert the C code into the Remora timer module, but looking good so far.

The plan will be to use the second core in the RP2040 to run the base thread. Hopefully this will allow a faster thread as the first core can handle the Ethernet stuff and the slower and less time critical servo thread tasks.

 

drewnabobber wrote:

Hey Scott. The rp2040 port of Grblhal uses the PIO to generate the step interrupt as well as the step waveform. It has less IRQ overhead than pure software stepping and the step generation is well suited to the fixed interrupt timing of remora.

github.com/grblHAL/RP2040/blob/master/driverPIO.pio#L8

I did have a quick look at the code earlier when I was thinking on options. The PIO is a bit of a mystery, but very capable. Not sure how to implement the DDS stepgen that dithers (averages) the frequency to overcome the underlying fixed clock frequency.

The advantage of using the Remora software step generator is that it can be assigned to any available pin using the config file. This would allow people to have total flexibility. And with a second core kicking around, we may as well give it a job to do

In case you have not come across this in your travels:

vanhunteradams.com/Pico/Steppers/Lorenz.html

Some more progress on the RP2040 with W5500 yesterday. The hotel cleaners must wonder what the hell the bundle of wires and blinking circuit boards are when they come. After spending most of the day getting LinuxCNC running on a VM and able to send UDP packets out from the host, communication to the RP2040 with the W5500 is up and running. But following errors... not just minor. What the? Below is a Pulseview capture of the threads running with 3 step generators and a blinky on the servo thread. Looks ok, with some fitter on the base thread (need to figure that out). 

 

Below is the same setup with LinuxCNC out of eStop - Ethernet communication happy.

 

Looks like the W5500 + LWIP stack is totally blocking interrupts on the RP2040, something we do not see on the STM32 implementation.

So my thoughts on moving the Base thread onto the second core will be needed. Apparently the LWIP stack will only run on Core 0, so my first attempt at multi-core programming will be to move the Remora state machine and threads all onto the second core, Core1. 

Well, I must say I'm quite impressed with the Pico SDK. It was super easy to move the core of Remora onto the second core. The jitter seen in the threads is gone, so it must have been the Ethernet polling that was causing the jitter when interrupts were being blocked.

 

The issue with the W5500 + LWIP blocking interrupts is significantly gone. Following errors are lessened and I'm suspicious that it's the Virtual Machine latency that's the main issue now. Position corruption is now back. It looks to be the issue that the SPI version had when both the interrupt code and the free running code were accessing the data structure at the same time.

Now to learn how to setup a semaphore / mutex between the cores.

 
 

TFTP upload of the configuration file is "knda" working... well the TFTP server is happy but the data isn't

I will need full debug capability to understand where my memory addressing is wrong. I'm reading data out of the wrong region or something...

I did bring my ST-Link converted to CMSIS-DAP probe with me but the SDK debug does not like the firmware version as some commands are not implemented.

So, I've ordered a Raspberry Pi Debug Probe, which will be waiting when I get back into Oz. This probe may be a nice out of the box use for the RT1052 boards as well. The Pico is also so so cheap and easy to program that a normal Pico would be a simple option as well.