- Hardware & Machines
- Computers and Hardware
- LinuxCNC-RIO - RealtimeIO for LinuxCNC based on FPGA (ICE40 / ECP5)
LinuxCNC-RIO - RealtimeIO for LinuxCNC based on FPGA (ICE40 / ECP5)
01 Aug 2024 17:42 #306644
by Mecanix
WT32-ETH01 ESP32 Ethernet Development Board
Replied by Mecanix on topic LinuxCNC-RIO - RealtimeIO for LinuxCNC based on FPGA (ICE40 / ECP5)
This one?At the moment a UDP2SPI bridge (esp32) is still the best solution.
WT32-ETH01 ESP32 Ethernet Development Board
Please Log in or Create an account to join the conversation.
01 Aug 2024 18:01 #306647
by meister
Replied by meister on topic LinuxCNC-RIO - RealtimeIO for LinuxCNC based on FPGA (ICE40 / ECP5)
i tryed RMII with the tangnano9k, bitfile generation works, but get no connection ![:( :(](/media/kunena/emoticons/sad.png)
better go with esp32:
github.com/multigcs/LinuxCNC-RIO/tree/main/UDP2SPI-Bridge
i prefer the WT32-ETH01, cheap and available
![:( :(](/media/kunena/emoticons/sad.png)
better go with esp32:
github.com/multigcs/LinuxCNC-RIO/tree/main/UDP2SPI-Bridge
i prefer the WT32-ETH01, cheap and available
The following user(s) said Thank You: Mecanix
Please Log in or Create an account to join the conversation.
01 Aug 2024 19:01 #306654
by cornholio
Replied by cornholio on topic 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.
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.
The following user(s) said Thank You: meister
Please Log in or Create an account to join the conversation.
02 Aug 2024 05:46 #306694
by meister
Replied by meister on topic LinuxCNC-RIO - RealtimeIO for LinuxCNC based on FPGA (ICE40 / ECP5)
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.
Please Log in or Create an account to join the conversation.
02 Aug 2024 06:48 #306697
by cornholio
Replied by cornholio on topic LinuxCNC-RIO - RealtimeIO for LinuxCNC based on FPGA (ICE40 / ECP5)
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 ?
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;
reg [5:0] initialization_progress = 6'b000000;
More 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]};
Please Log in or Create an account to join the conversation.
02 Aug 2024 09:25 #306703
by meister
you must not look at it as a programmer![:) :)](/media/kunena/emoticons/smile.png)
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
Replied by meister on topic LinuxCNC-RIO - RealtimeIO for LinuxCNC based on FPGA (ICE40 / ECP5)
i have no problem with discarding initial concepts if it brings an advantage, unfortunately i still see disadvantages in softcore.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;
[/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 ?
you must not look at it as a programmer
![:) :)](/media/kunena/emoticons/smile.png)
this is verilog logic, not serial programming.
Everything runs in parallel
that:
initialization_progress <= initialization_progress + 6'b000001;
case (initialization_progress)
@(posedge clk) begin' is it 1
verilog can be a real brainfuck
![:) :)](/media/kunena/emoticons/smile.png)
Please Log in or Create an account to join the conversation.
02 Aug 2024 09:52 - 02 Aug 2024 09:57 #306708
by cornholio
Replied by cornholio on topic LinuxCNC-RIO - RealtimeIO for LinuxCNC based on FPGA (ICE40 / ECP5)
Attachments:
Last edit: 02 Aug 2024 09:57 by cornholio.
Please Log in or Create an account to join the conversation.
02 Aug 2024 10:21 #306714
by Mecanix
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).
Replied by Mecanix on topic LinuxCNC-RIO - RealtimeIO for LinuxCNC based on FPGA (ICE40 / ECP5)
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.i prefer the WT32-ETH01, cheap and available
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).
The following user(s) said Thank You: meister
Please Log in or Create an account to join the conversation.
02 Aug 2024 11:18 #306718
by meister
Replied by meister on topic LinuxCNC-RIO - RealtimeIO for LinuxCNC based on FPGA (ICE40 / ECP5)
my knowledge of verilog is extremely limited and i would be happy to have someone with me who is more familiar with it.
I'm the last person who would complain about someone getting things to work in RIO that I'm too stupid for![:) :)](/media/kunena/emoticons/smile.png)
i will test the new driver later at home, the integration into RIO is not so hard.
all what rio 'know' about the w5500 plugin is here:
riocore/plugins/w5500/
so, more or less, copy the new files into this folder and editing plugin.py:
changing list of verilog files:and add the new pin:
The only thing missing is this in the w5500.v:
sync: goes to 1 if a new package is received
pkg_timeout: goes to 1 if no package received for a while (parameter TIMEOUT)
tx_data: the data to send
rx_data: the received package
pkg_timeout is needed to trigger the error state of the CNC
sync is needed for multiplexed data
BUFFER_SIZE depends on the configuration and will be set while generating the rio.v
I'm the last person who would complain about someone getting things to work in RIO that I'm too stupid for
![:) :)](/media/kunena/emoticons/smile.png)
i will test the new driver later at home, the integration into RIO is not so hard.
all what rio 'know' about the w5500 plugin is here:
riocore/plugins/w5500/
so, more or less, copy the new files into this folder and editing plugin.py:
changing list of verilog files:
self.VERILOGS = ["w5500.v", "SPI.v"]
self.PINDEFAULTS = {
....
"w5500_rst": {
"direction": "output",
"invert": False,
"pull": None,
},
}
The only thing missing is this in the w5500.v:
input [BUFFER_SIZE-1:0] tx_data,
output [BUFFER_SIZE-1:0] rx_data,
output reg sync = 0,
output reg pkg_timeout = 0
sync: goes to 1 if a new package is received
pkg_timeout: goes to 1 if no package received for a while (parameter TIMEOUT)
tx_data: the data to send
rx_data: the received package
pkg_timeout is needed to trigger the error state of the CNC
sync is needed for multiplexed data
BUFFER_SIZE depends on the configuration and will be set while generating the rio.v
The following user(s) said Thank You: Mecanix
Please Log in or Create an account to join the conversation.
02 Aug 2024 11:27 #306719
by meister
Replied by meister on topic LinuxCNC-RIO - RealtimeIO for LinuxCNC based on FPGA (ICE40 / ECP5)
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
Of course, the (r)mii interface would be even better, but the w5500 will do for now
![:) :)](/media/kunena/emoticons/smile.png)
Please Log in or Create an account to join the conversation.
- Hardware & Machines
- Computers and Hardware
- LinuxCNC-RIO - RealtimeIO for LinuxCNC based on FPGA (ICE40 / ECP5)
Time to create page: 0.130 seconds