LinuxCNC-RIO - RealtimeIO for LinuxCNC based on FPGA (ICE40 / ECP5)
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 
better go with esp32:
github.com/multigcs/LinuxCNC-RIO/tree/main/UDP2SPI-Bridge
i prefer the WT32-ETH01, cheap and available
better go with esp32:
github.com/multigcs/LinuxCNC-RIO/tree/main/UDP2SPI-Bridge
i prefer the WT32-ETH01, cheap and available
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
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
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 1verilog can be a real brainfuck
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)
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
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
Attachments:
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).
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
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
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 = 0sync: 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
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
Please Log in or Create an account to join the conversation.
Time to create page: 0.142 seconds