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

I have a sneaky suspicion that the W5500 has trouble keeping up with the small packets.
I’ve noticed that when there is an issue with the packets there is quite a long response time. It’s difficult as the packets seem to have issues at random intervals, there doesn’t seem to be anything consistent to it.
Tho the code doesn’t seem to do the required software reset, but one would think if it was an issue it would show up quite early in the piece.
Another option would be a soft core to handle the Ethernet interface. From looking at the Mesa code the softcores they use are to handle the smart serial and Ethernet comms.
But in all honesty the bridge works great.

with soft cores you again have the problem that it does not run so easily on all FPGA's, plus the problems with writing the flash with the firmware.

I was just throwing it out there.
In all honesty it really doesn't go with the ethos of your project. From the beginning you wanted to stay away from softcores.
Just while I have it on my mind;
More code...... Am I right in thinking that SET_PHY_MODE is never acted on as initialization_progress is incremented before the case stanza ?

Cant do this anymore bye all wrote:

I was just throwing it out there.
In all honesty it really doesn't go with the ethos of your project. From the beginning you wanted to stay away from softcores.
Just while I have it on my mind;

i have no problem with discarding initial concepts if it brings an advantage, unfortunately i still see disadvantages in softcore.

Cant do this anymore bye all wrote:

Code:

reg [5:0] initialization_progress = 6'b000000; More code...... [code]end else if (state == STATE_INITIALIZING) begin spi_clk <= 1'b0; state <= STATE_SENDING_COMMAND; initialization_progress <= initialization_progress + 6'b000001; spi_chip_select_n <= 1'b0; spi_clock_count <= 10'd0; is_busy <= 1'b1; case (initialization_progress) // TODO: Perhaps add software reset here? 0: current_instruction <= SET_PHY_MODE; // Set our MAC address 1: current_instruction <= {SET_MAC_ADDRESS_BYTE_0, MAC_ADDR[47:40]}; 2: current_instruction <= {SET_MAC_ADDRESS_BYTE_1, MAC_ADDR[39:32]}; 3: current_instruction <= {SET_MAC_ADDRESS_BYTE_2, MAC_ADDR[31:24]}; 4: current_instruction <= {SET_MAC_ADDRESS_BYTE_3, MAC_ADDR[23:16]}; 5: current_instruction <= {SET_MAC_ADDRESS_BYTE_4, MAC_ADDR[15:8]}; 6: current_instruction <= {SET_MAC_ADDRESS_BYTE_5, MAC_ADDR[7:0]}; Am I right in thinking that SET_PHY_MODE is never acted on as initialization_progress is incremented before the case stanza ?

[/code]

you must not look at it as a programmer

this is verilog logic, not serial programming.
Everything runs in parallel

that: and this: is executed at the same time and therefore the value in the 'case' is still 0 and only in the next 'always
verilog can be a real brainfuck

Yeah it seems that way.

More reading required. I've got a evaluation board on the way an old Diligent Spartan 3AN. So rather than trying to take everything at once I'll have a chance to "do little bits at a time". And not bother you so much
 
Thanks

meister wrote:

i prefer the WT32-ETH01, cheap and available

Understood, thanks for the advice/heads up. I have placed an order for the WT32-ETH01 and will receive this within 36~48hrs. I'll update. 

As important; For your review and consideration, Oliver.  I've quickly re-wrote a w5500 UDP protocol driver featuring a robust state machine and both a soft & hard reset (set on hard rst atm - preference). The SPI is a high-performance 50meg judging from the initial tests carried (see attached Gowin project/ZIP file). Additionally, please pardon my arrogance and persistence in trying to get this w5500 badboy to work; the reasoning behind is not fueled by my potential $1.99 investment losses (lol) I assure you, but more or less by the enthusiasm of that wizzy part being as simplistic as they come - let alone a ridiculously low-cost BOM and beyond ease for hardware implementation. All good reasons if RIO is to be adopted by makers like myself (iThink). 

You guessed; I wouldn't know where to begin neither would know how to implement this into RIOCore. Therefore I leave it to you to investigate that possibility (or feasibility rather).