Remora - ethernet

scotta,

what did you do with the reset pin on the w5500? I read in a few places that it is required to be toggled, like the arduino libs use the reset pin. It appears unconnected in your video.

I tried getting this working last night but I can't find the w5500 ethernet implimentation of Remora documented anywhere. In arduino libs the reset on the w5500 is controlled by a gpio. So I have no idea how that's handled in Remora or if it's necessary. From what I've read the w5500 has a default IP of 192.168.1.2 but if I set my NIC to 192.168.1.x I can't ping it.

I was hoping to avoid buying a Mesa card for this thing because a 3D printer board is more suitable for this. I'd have to get something like a 7i92 and make my own IO board.

blazini36 wrote:

I tried getting this working last night but I can't find the w5500 ethernet implimentation of Remora documented anywhere. In arduino libs the reset on the w5500 is controlled by a gpio. So I have no idea how that's handled in Remora or if it's necessary. From what I've read the w5500 has a default IP of 192.168.1.2 but if I set my NIC to 192.168.1.x I can't ping it.

I was hoping to avoid buying a Mesa card for this thing because a 3D printer board is more suitable for this. I'd have to get something like a 7i92 and make my own IO board.

Hi, the W5500 Ethernet version of Remora is / was a proof of concept which is hacked together. It was working on an SKR v2 so you will need to check the SPI pin definition for the Octopus. Also check you IP address settings as the code is looking for LinuxCNC to be on 10.10.10.11

Hey Scott. Any suggestions to try to get the RP2040 stuff backported here to STM32? This would still be quite useful as many boards do not have onboard ethernet populated and the W5500 is price competitive with something like the LAN8720 and uses fewer pins.

Yes, I need to get back to that. Really only need to finalise the W5500 stuff as TFTP upload etc was worked out for the original NVEM boards.

I did find my testing code for interrupt driven receive (rather than polled). So that could be moved over to the Mbed code. The DMA transfer bit was the last piece of the puzzle.

I think I may have just found the issues with the RT1052 C++ version which was killing the Ethernet. If I'm right I'll get that code finalised and then come back to the W5500 work, and the new RISC-V board sitting on the bench.

Dear Scotta,
I have compiled and Ping 10.10.10.10 it is successfully connected.
But still, E-stop not working.

That dev branch is / was highly experimental. I will come back to a W5500 driver module for the Mbed based Remora boards. Just a long list on the To Do items ATM.

I'd start looking at your max configuration to ensure that the joint can try and reduce the following error.

I've had a quick look at some of the recent config examples and the velocity configs is not what I'd normally suggest.

[TRAJ] MAX_LINEAR_VELOCITY < [JOINT] MAX_VELOCITY
STEPGEN_MAX_ACCEL > 1.2 x MAX_ACCELERATION

This stops the MAX_LINEAR_VELOCITY from overriding the [JOINT] MAX_VELOCITY.