LinuxCNC-RIO - RealtimeIO for LinuxCNC based on FPGA (ICE40 / ECP5)

Your consideration is much appreciated!! You're way too cool bud, thank you for what you've done for this community so far, no joke, it's EPIC <-- repost, take it.

Have a look and see if that's feasible. Problem on my side is not about keyboarding stuff but the Linuxcnc RTAI rather. I honestly wouldn't know where and how to test all that up, prolly would shave a month+ off my short life just to learn (min).

Side note; anyone telling you he/she's an expert in verilog and/or parallel-thinking is utterly lying to you. Bet there is only 5 persons on earth who master that brilliant e.e. mess of a codebase... (/rant_over lol)

ARP & Ping are handled internally via the W5500, the only control is whether to respond to a ping or not.
After looking at info on the W5500 I read, whilst theoretically it can run an 80Mhz clock for real life 33Mhz is the max recommended.
As I said the packet issue seems to be random, you can have a period of 20000 packets be fine then you can 3 periods when the packets go south every 5000 packets and then be good for another 30k.
According to wireshark when the packets are delayed the data is good, no issues there.
Just wondering if rather than a combined r\w function in the driver whether it could be split. I have a feeling the Hostmot2 driver has seperate r\w functions. Maybe with a few functions added in between the read & write functions it may help.

Should RTAI be used with Ethernet ?
I thought RT_PREEMPT was the go, at least with the hostmot2 Ethernet driver.

cornholio wrote:

Should RTAI be used with Ethernet ?
I thought RT_PREEMPT was the go, at least with the hostmot2 Ethernet driver.
 

Don't think for a split second that was a typo, I hardly make any difference between both rtai and rt_preempt. No kidd... so much to catch up, not even to the ankle level of guys like meister or yourself when it comes to lcnc devs. My bad btw... I should have been specific /RT/RTAI/PREEMPT/USPACE/WHO/WHAT... ... ...

to be clear, i have no idea about rtai/rt_preempt either, the hal component is also just a derivative of the remora project.
i'm not a good python programmer either, but when i set my mind to something i try until it somehow fits

meister wrote:

if we get rid of the errors in the w5500, i would of course always prefer this interface to the esp, as it is faster, reduces the parts and you don't have to program the esp as well.
Of course, the (r)mii interface would be even better, but the w5500 will do for now

That's the whole idea to have something as low-cost, easy to implement, small footprint/real-estate. That wizzy 5500 part win on all championships... I can count the required passives on one hand almost. Winner stuff. 

You said it better, anything to prevent having to impose an utterly complex implementation let alone adding a MCU + extra firmwares. Messyland guaranteed. Less is more!

Anything you need me to test with please do shoutout. I'm not far. 

Maybe some sed magic might fix it ?

cornholio wrote:

Maybe some sed magic might fix it ?

You've tried the new state machine driver and confirming it still doesn't perform as it should? I'm overflowing a 1Mb/s fifo uart module with it here, no pkts drama... what's the magical fix for?  

Nah mate it’s midnight where I am, was just making a bit of a joke in reference to some code I submitted last year.

You had me worried. Thought you had a go at it and already binned hope! Wish I'd be able to give it a TRUE Lcnc perf stress-test myself but can't - dependent on meister on that side of things. If you needed 'delays', those spi and w5500 sync'd state machines should deliver that magic plenty

Let's try again when the weather is better... f n inferno hot here lool