They did the IP protection quite clever. The way the protocol works is protected by patents. You can't be (fully) compatible with the standard and at the same time don't violate their patents. Well, patents expire after 20 years but they update the standard, say every 10 years, and register new patents. As member of the ETG you have to sign a contract that you implement the changes within one year. So if it's not fully compatible it violates the contract and if it is then you're bound to the patents.
Also it's no open standard. You only get acess to all of the documents if you sign the contract. There is of course the possibility that this information somehow leaks to a person that doesn't have signed anything. That would be illegal but they can't completely avoid it. That "outlaw" could then implement some sort of "EtherDOG" which would then be theoretically legal if it only uses the technology of the already expired patents. That would be by definition incompatible to the current standard. If you're lucky you could possibly come up with something that is at least compatible enough so that you could still use some third party components like drives and IO boards. But what would be the benefit of all that? It would be bad for the end user or customer because it sort of counterfeits compatibility. And the manufacturer/dealer wouldn't gain anything as long as there is an easier and affordable way to make it fully compatible.
There is a second loophole. AFAIK patent law explicitely allows that anyone who wants to is allowed to replicate the subject of a patent for evaluation purpose. You are not allow to sell anything or not even give it away for free. It's also forbidden to take advantage of anything that is produced as part of the experiment. After you're done you have to either destroy or lock away the devices you've built for evaluation. So that would definitely make it useless for any commercial application. However, I don't know if trying something out still counts as evaluation if at the same time it's demonstrated to others for the purpose of education. Teaching students could be interpreted as taking intellectual advantage out of the experiment.
But again, why all the trouble? I thought there was an easy way to implement an EtherCAT slave in a P2. It turned out that it's much harder than I thought. So as long as nobody finds a solution that makes this feasible, again, I'd go the path of the least resistance, e.g. buy a LAN9252.
Furthermore, it is still posible to implement an EtherCAT master interface with a P2 without any legal trouble. So let's do that, first.
@Simonius said:
what if you just cloned parts of the specificiation and called it EtherDOG?
This would be indeed possible, at least technically. We could build an EtherDOG slave device with the P2 that is not able to respond immediately to a dynamical frame layout. Instead it requires a fixed layout where the position and length of the subpackets are statically assigned to the slave devices. This would make an efficient handling of the Ethernet frames possible with only block replacement by the P2 required on-the-fly. The error handling mechanism of EtherCAT could be "abused" so that the P2 can signal "hey, I'm not ready, yet" if the layout changes. The frame would be repeated and the P2 answers the command with one cycle time delay. This is not a problem for one-shot commands. Cyclic commands could be processed in real-time and without delay as long as the frame layout doesn't change.
The master device could even be implemented in a fully EtherCAT compatible way. So let's call it "EtherPET" because it can talk to both EtherCAT and EtherDOG devices. AFAIK, the standard does not forbid that a device supports more than the standard requires. EtherCAT slaves mixed with EtherDOG slaves in the same network would work without problems with an EtherPET master. But of course, EtherDOG devices would not work in a network with an EtherCAT master because it makes assumptions that the standard doesn't guarantee. So even if that didn't violate the copyright because we name it differently that would be completely against the philosophy of a standard where all devices from all manufacturers should be inter-operable. So it's a bad idea.
My original intention was to take this as a demonstration of how powerful the Propeller 2 is. A driver that bit-bangs the EtherCAT protocol purely in software and only requires PHY chips and magnetics would be really cool. However, if that's not possible I don't see a justifyable reason to take any detours or do any tricks. It also doesn't make any sense, economically. As long as the licensed ESC chips are available and Beckhoff doesn't charge horrendous fees there is no need for clones.
I just noticed that the latest version of the driver somehow got lost in the translation from the GITHUB to the new OBEX. The driver in post #135 had an outdated pin assignment and therefore was obsolete. Now, I fixed this. Link to OBEX
I recently found a bug in the driver. The frequent polling of the link status via the SMI (serial management interface) somehow disturbed the data transmission of the next packet. I had the suspect that this has had something to do with the pin sharing. I use the same pin for MDIO of the SMI and TXD0 if the RMII. I thought that TXD0 should be "don't care" as long as TXDEN is low which means no packet is currently transmitted.
I have double checked that TXDEN really stays low while the SMI is in use and that the smartpins are reset before and after so that no garbage data remains in the shift registers. But it still doesn't work. So I decided to simply skip the status polling as long as there is traffic on the network interface. The SMI polling is a waste of bandwidth, anyway. It takes >30µs to read a register while it only takes 5µs to trasmit a short Ethernet packet. If I have sucessfully received packets in the last 100ms I know that the link is still up and I don't need to poll the status. Only if the network is idle I have to check for a cable disconnect or re-connect.
I now have a simple and small protocol on top of the Ethernet PHY driver: It supports UDP and ARP. UDP (user datagram protocol) is ideal for small packets of data that are frequently transmitted like PWM values for a motor or solenoid driver or an LED display panel. For such applications there is no need for fragmentation of larger data chunks and acknowledges would also be of no use. Retransmitting data after a packet loss (collision or noise -> checksum mismatch) makes no sense as the older data is soon outdated anyway and would be simply overwritten by new data.
The current implementation can handle one in and one out port only and has a fixed IP address. The IP address is announced on startup with "gratuitous ARP" or with ARP request/response if required. I'll add the protocol driver to the OBEX as soon as the software for my flight simulator motion controller is finished.
What have you found so far that may limit the UDP port to one in and one out? Is it due to the search index size for a 16 bit port range being large or something else like managing the multiple per port buffers? In time, could some per-port state be held in hub RAM to allow scaling or is there a execution time constraint or something else that would prevent that?
I still hope to look into this stuff at some point, and I recall you sent me your Ethernet PHY board some time ago. Thanks again for that BTW.
The reason for the port limit is just my laziness. I need only one for my current application and it's difficult to invent the logistics to handle multiple ports as long as I don't have a clue how a multi-port application might look like. It probably would also need multiple cogs or some sort of scheduling. If I came up with an incomplete solution it wouldn't be of any use, anyway.
I think some sort of multi-port buffer should be no problem. But you need to know the requirements, first.
I know zip about implementing, or even coding for, Internet Protocols but sounds cool to me anyway. It would just have to work through an Ethernet switch to make me happy ... I suspect.
Comments
They did the IP protection quite clever. The way the protocol works is protected by patents. You can't be (fully) compatible with the standard and at the same time don't violate their patents. Well, patents expire after 20 years but they update the standard, say every 10 years, and register new patents. As member of the ETG you have to sign a contract that you implement the changes within one year. So if it's not fully compatible it violates the contract and if it is then you're bound to the patents.
Also it's no open standard. You only get acess to all of the documents if you sign the contract. There is of course the possibility that this information somehow leaks to a person that doesn't have signed anything. That would be illegal but they can't completely avoid it. That "outlaw" could then implement some sort of "EtherDOG" which would then be theoretically legal if it only uses the technology of the already expired patents. That would be by definition incompatible to the current standard. If you're lucky you could possibly come up with something that is at least compatible enough so that you could still use some third party components like drives and IO boards. But what would be the benefit of all that? It would be bad for the end user or customer because it sort of counterfeits compatibility. And the manufacturer/dealer wouldn't gain anything as long as there is an easier and affordable way to make it fully compatible.
There is a second loophole. AFAIK patent law explicitely allows that anyone who wants to is allowed to replicate the subject of a patent for evaluation purpose. You are not allow to sell anything or not even give it away for free. It's also forbidden to take advantage of anything that is produced as part of the experiment. After you're done you have to either destroy or lock away the devices you've built for evaluation. So that would definitely make it useless for any commercial application. However, I don't know if trying something out still counts as evaluation if at the same time it's demonstrated to others for the purpose of education. Teaching students could be interpreted as taking intellectual advantage out of the experiment.
But again, why all the trouble? I thought there was an easy way to implement an EtherCAT slave in a P2. It turned out that it's much harder than I thought. So as long as nobody finds a solution that makes this feasible, again, I'd go the path of the least resistance, e.g. buy a LAN9252.
Furthermore, it is still posible to implement an EtherCAT master interface with a P2 without any legal trouble. So let's do that, first.
This would be indeed possible, at least technically. We could build an EtherDOG slave device with the P2 that is not able to respond immediately to a dynamical frame layout. Instead it requires a fixed layout where the position and length of the subpackets are statically assigned to the slave devices. This would make an efficient handling of the Ethernet frames possible with only block replacement by the P2 required on-the-fly. The error handling mechanism of EtherCAT could be "abused" so that the P2 can signal "hey, I'm not ready, yet" if the layout changes. The frame would be repeated and the P2 answers the command with one cycle time delay. This is not a problem for one-shot commands. Cyclic commands could be processed in real-time and without delay as long as the frame layout doesn't change.
The master device could even be implemented in a fully EtherCAT compatible way. So let's call it "EtherPET" because it can talk to both EtherCAT and EtherDOG devices. AFAIK, the standard does not forbid that a device supports more than the standard requires. EtherCAT slaves mixed with EtherDOG slaves in the same network would work without problems with an EtherPET master. But of course, EtherDOG devices would not work in a network with an EtherCAT master because it makes assumptions that the standard doesn't guarantee. So even if that didn't violate the copyright because we name it differently that would be completely against the philosophy of a standard where all devices from all manufacturers should be inter-operable. So it's a bad idea.
My original intention was to take this as a demonstration of how powerful the Propeller 2 is. A driver that bit-bangs the EtherCAT protocol purely in software and only requires PHY chips and magnetics would be really cool. However, if that's not possible I don't see a justifyable reason to take any detours or do any tricks. It also doesn't make any sense, economically. As long as the licensed ESC chips are available and Beckhoff doesn't charge horrendous fees there is no need for clones.
Yes, we should focus on our USP's and not on others USP's. That's leading to a cul-de-sac
deleted
I just noticed that the latest version of the driver somehow got lost in the translation from the GITHUB to the new OBEX. The driver in post #135 had an outdated pin assignment and therefore was obsolete. Now, I fixed this. Link to OBEX
I recently found a bug in the driver. The frequent polling of the link status via the SMI (serial management interface) somehow disturbed the data transmission of the next packet. I had the suspect that this has had something to do with the pin sharing. I use the same pin for MDIO of the SMI and TXD0 if the RMII. I thought that TXD0 should be "don't care" as long as TXDEN is low which means no packet is currently transmitted.
I have double checked that TXDEN really stays low while the SMI is in use and that the smartpins are reset before and after so that no garbage data remains in the shift registers. But it still doesn't work. So I decided to simply skip the status polling as long as there is traffic on the network interface. The SMI polling is a waste of bandwidth, anyway. It takes >30µs to read a register while it only takes 5µs to trasmit a short Ethernet packet. If I have sucessfully received packets in the last 100ms I know that the link is still up and I don't need to poll the status. Only if the network is idle I have to check for a cable disconnect or re-connect.
I now have a simple and small protocol on top of the Ethernet PHY driver: It supports UDP and ARP. UDP (user datagram protocol) is ideal for small packets of data that are frequently transmitted like PWM values for a motor or solenoid driver or an LED display panel. For such applications there is no need for fragmentation of larger data chunks and acknowledges would also be of no use. Retransmitting data after a packet loss (collision or noise -> checksum mismatch) makes no sense as the older data is soon outdated anyway and would be simply overwritten by new data.
The current implementation can handle one in and one out port only and has a fixed IP address. The IP address is announced on startup with "gratuitous ARP" or with ARP request/response if required. I'll add the protocol driver to the OBEX as soon as the software for my flight simulator motion controller is finished.
Interesting 👍
Nice stuff @ManAtWork
What have you found so far that may limit the UDP port to one in and one out? Is it due to the search index size for a 16 bit port range being large or something else like managing the multiple per port buffers? In time, could some per-port state be held in hub RAM to allow scaling or is there a execution time constraint or something else that would prevent that?
I still hope to look into this stuff at some point, and I recall you sent me your Ethernet PHY board some time ago. Thanks again for that BTW.
The reason for the port limit is just my laziness. I need only one for my current application and it's difficult to invent the logistics to handle multiple ports as long as I don't have a clue how a multi-port application might look like. It probably would also need multiple cogs or some sort of scheduling. If I came up with an incomplete solution it wouldn't be of any use, anyway.
I think some sort of multi-port buffer should be no problem. But you need to know the requirements, first.
I know zip about implementing, or even coding for, Internet Protocols but sounds cool to me anyway. It would just have to work through an Ethernet switch to make me happy ... I suspect.