Remora for RP2040

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.

I'm keen for this or something like this, just for GPIO even.

(E.g. for complementing an ethercat setup).

Watching with interest.

With step/dir even low step rates for additional things like auto tool changers would be quite helpful.

So, I've implemented a really super simple semaphore between the threads and the Ethernet data transfer, looks to have solved the data corruption. My hunch about the virtual machine causing the following errors was correct. The servo thread was just to slow for the communication and updates. The video is showing the hotel room test bed running with a 5000ms servo thread.

This is so close to be running now!