@Mickster said:
Apologies for derailing the thread
Information is always welcome. But could you please stop posting pictures that promote or bash products that have nothing to do with the subject (or at least I don't get it).
I am absolutely certain that analogue is going nowhere. Jacob Tal, Chuck Lewin and Peter Nachtwey still swear by it. Although Nachtwey has retired, he still communicates. He tells me that they can't live with the jitter of EtherCAT. Of course, the way Beckhoff sugar-coat it: "it's only a little bit pregnant". His RMC200 features an 18bit analog motor command
I absolutely understand why, for example encoder, need a rediculously high resolution to get a good control of speed. Velocity is the derivation of position, so counts per millisecond naturally has 10 bits resolution less than the posiotion. 18bit of analogue (velocity) command also seems a lot. But a +/-300RPM speed range for a typical motor is 36000°/s. So 16 bit resolution or 15 bit + sign would give an LSB of 0.55°/s. I think that should be enough for most applications but if you want dither-free precision motion it's probably not.
Can you explain why jitter is a problem? How high is the jitter of the Beckhoff implementation? I think we could reduce this to almost zero with the P2. A P2 directly connected to a PHY chip can start a packet at any 50MHz clock edge. The receiver synchronizes that to his own 50MHz clock. So the jitter should be in the +/- 20ns range.
We need a revolution, darnit and the P1 & P2 need to be at the heart of it. Time to cut the cr@p.
You named lots of problems with products of the big companies. But I still don't see that the EtherCAT specification is to blame for that. It might be that EtherCAT is not the optimum solution for your applications. As a small company, I think, neither me nor Parallax will be able to make a "revolution" or any kind of "jack of all trades" product. But any such attempts are doomed to fail anyway. Trying to "please them all" always leads to feature-itis and overwhelming complexity.
So what we can do is to devlop products that only serve a smaller market but are easy to use, simple and reliable. If you have objections why this is not possible with EtherCAT (and I don't mean "their" implementation but a nice, clean one) then please explain your reasons in detail.
@Maciek said:
Bear in mind, however, that by chosing this path you make your product totally dependent on THE chip (P2) from THE company (Parallax). Now, that looks like a single point of failure, big time (unless you stockpile the P2 to be on a safe side at any given time - that may require substantial investment up front).
Are they any more immune than the others in case of a crisis ?
There is no such thing as 100% certainty. If you insist on a second source for all of the components you use then you limit yourself to the stone-age of electronics with baking trays full of 74xx logic and OPAs. You have to commit to some manufacturer.
Parallax proved to be much more reliable than any other semiconductor company I know. Maybe it was just luck or the fact that they are so small that nobody cared to hoard and panic-buy their chips. But compared to others I had very little trouble during the COVID crises.
All I can advise is to play with EtherCAT for awhile...I have to deal with it and it's horrendous.
I read all about this distributed servo control with dozens of axes. Where are these things? My life is spent in factories 😐
The most I know of is 20 axes and it's my own invention/creation. I have lots of 17 axes but I have yet to see anything come close to this
Please note the rotary turret that runs 24/7. It's carrying 8 other servo axes that are constantly talking to the main controller. This was a no-brainer of a development....EtherCAT? Be my guest 😂🤣
RJ45 in this brutal industrial environment?
It's just not happening with this guy.
Made sense to some limp-wristed design engineer, I guess, who has never experienced the plant floor 😁
Ethercat has a lot from CANopen, some conceptual simularities:
Take a reliable physical method (CAN/ethernet) and adapt it for SCADA. It relies only on trusted, widely available parts (CAN tranceiver/Ethernet Phy) and uses a standard interface (CAN /(R)MII)
I don't see a problem with the signaling as long as you use CAT5/6 cables.... and inserting into a bypassing ethernet packet ist quite ingenious, as it would allow in theory more than 100k packets/second i.e. about 10 us timing granularity,even though the controller does not use the whole bandwidth, Beckhoff works at 10kHz if i remember correctly. which is quite good for a networked system which can be distributed over a large space, in a big machine or factory..
at least in theory....
working with the vendor tools like Siemens STEP or Beckhoff is of course cumbersome for a real programmer but for engineers it might be a good tool
@ManAtWork This is quite impressive! I am watching Oct 18th's Propeller Liver Forum, and read this thread.
I would be very interested in a module that has everything I need to put 100BaseT networking, even at the MAC level. Do you have them for sale?
Do they use a single 8IO port?
Do they have their own crystal?
What is the actual data throughput you are getting after removing headers & CRCs?
The main reason to use Ladder Logic is to make the source code accessible to the electricians that work on site every day. It sure makes their life a lot easier when they can see what the machine is expecting rather than just guessing. If you detest the idea of letting others see your work then Ladder ain't the right choice.
On that note, using Ladder then locking out the customer is the dumbest move ever.
Anderson's tale involves a vain king who was preoccupied with his appearance and his wardrobe. A pair of swindlers took advantage of this by pretending to be able to weave the finest cloth, which couldn't be seen by people who were either unfit for office or were particularly stupid. The king decided to have a suit of clothes made from the fabric in order to test which of his courtiers was unfit for office. As he didn't want to appear stupid or unfit for rule himself, he pretended to be able to see the new clothes, as did all of his courtiers. He paraded the 'new clothes' through the streets and the onlookers, also not wishing to appear stupid, all admired them. A small child, who didn't understand the apparent necessity for pretence, piped up 'But he has nothing on!'. The bubble of pretence burst and soon all the onlookers were repeating what the child had said, whilst the king continued the procession, attempting to maintain his dignity by pretending that nothing had happened.
Today's control engineers: Yup that stuff is great, amazing in fact. Someone tell that stupid kid to shut up.
A standard is a standard is a standard...
The question is: if you were to sell, say, a motor controller, what would a customer look for? if Beckhoff is a thing, and @Mickster, you admit that, why not go for it? There are a multitude of interface types and each will cover a part of the potential market, or am i wrong? Most vendors include at least 2 interfaces with an optional 3rd one which can be outfitted as needed (RS485, EtherNet, EtherCAT, CANopen, RS232 (some even USB), etc...., maybe PCI (x), ... )
babylon is calling
in the lab equipment up to the recent years (before USB came along), you would find RS232 on all devices, which is perfectly fine, it just works and it was easy to interface... often a handbook would tell you right away which are the commands you can use ... too easy! ... just don't plug in the cable in the wrong port or have the wrong baudrate/etc. set O_o (if you find a USB port on a device, there is really just a ftdi chip inside which will create a virtual rs232 port in the computer, which will do the port swapping for you so you never know which device is on which port, how funny if you have more than one device connected which usually is the case)
as far as i can tell he is advocating for something like RS485, which could be the 2nd option to have on the board - it's actually a good idea to have both, maybe already prepared on the board but not populated by default to save on BOM
the versatility of the Propeller's smart pins would make it easy to swap out ,,communication" modules, tiny boards that are soldered flat on the main PCB with a specific driver chip and connector for each imaginable interface, not unlike the Parallax Modules
The idea is that the fastest way to switch from "repeat incoming data" to "insert local data" and back again is to not switch at all. I mean I want to avoid conditional code, SKIPF and branches. Instead I pre-calculate an array of mask values and an array of overlay data. The overlay data replaces the incoming data for all bytes where the mask is opaque (0) and leaves it the same where the mask is transparent (1). The overlay data is 0 for all bytes where the mask is transparent (1), so it doesn't interfere with the incoming data. Mask and overlay data is stored interleaved. That wastes some memory (twice the packet length) but is fast and easy to handle.
If I counted correctly theese are 38 instructions and execute in at least 76 clocks. Storing the replaced incoming data to a local buffer is not included and takes at least another 2 instructions. So we'd need 80 clocks altoghether and therefore we need to run at 250MHz to be able to do it all in one cog. I'm not very happy with this and like to avoid over-clocking for industrial applications. So it might be a better idea to do it in two cogs and pass the data via shared LUT RAM or a long repository of a smart pin.
I propose the following. COGrx does receive the packet, pushes each Word to the HUB + calculate the CRC as usual + copy the stream to the PIN repository, when the time has come to insert INTO the packet, send that to the pin repository instead
COGtx does transmit a packet as it alsways does but instead of the HUB memory, it taps the pin repository for fresh data, CRC as usual.... at the very end of the procedure there is a flag raised on COGrx that COGtx can read, whenever a CRC error occurs. in that case, the transmitted packet is aborted or it's CRC voluntarily corrupted. 2 COGs, 32+something bits of delay. should work. await the info on the specs
@Simonius OK, I finally have to agree with you. So we need 2 cogs for the downstream data (master to slaves) and one for the upstream port (simple repeater). 3 cogs seem a lot for a single communication interface. But I think 5 cogs left are still plenty for a simple slave device like a digital and analogue IO module. And for a sophisticated slave device like a servo controller it would save one cog for an additional configuration interface (RS232 or 485 serial port). That is no longer needed as the parameters and diagnosis data can also be transmitted over EtherCAT.
@hinv said:
@ManAtWork This is quite impressive! I am watching Oct 18th's Propeller Liver Forum, and read this thread.
I would be very interested in a module that has everything I need to put 100BaseT networking, even at the MAC level. Do you have them for sale?
As @Simonius already said there is a thread about my ethernet accessory board. I have 5 units left but need at least two three of them for my own experiments (one master and slave with two ports).
Do they use a single 8IO port?
Do they have their own crystal?
Yes they have their own 25MHz crystal and they only need 8 IO pins. The MDIO configuration interface, the RMII interface and the I2C bus for the MAC address ROM share some of the pins.
What is the actual data throughput you are getting after removing headers & CRCs?
Theoretically something >10MByte/s. So there is no limit other than the physical line speed. But you would run out of memory very quickly unless you can process the data really fast.
@Mickster said:
RJ45 in this brutal industrial environment?
It's just not happening with this guy.
Made sense to some limp-wristed design engineer, I guess, who has never experienced the plant floor 😁
There are M12 connectors with 8 pins and IP67. But they are horribly expensive.
I wonder why they don't just use 5 pin M12 connectors. EtherCAT and 100Mb/s ethernet uses only 2 of the 4 twisted pairs, anyway. So 4 pins + shield would be enough.
One repository smartpin doesn't go far. If you're going to use two cogs for one driver you may as well make it a lutRAM sharing pair and get all that shared space along with its four event triggers.
@Simonius said:
The driver can sustain the full 100 mbits.
To calculate the theoretical maximum
Start with the 1500 packet size, add the 12 inter-frame-gap + the frame overhead ( 8 for preamble + 14 for header + 4 for the CRC )
then calculate the theoretical max speed:
100 Mbit/s / 8 bits in a byte * (1500/1538)
= 12.19 MB/sec
The throughput will decrease when packets get smaller (the minimal ethernet packet would have 46 bytes payload @ 6,85 MBps).
Yeah, but what DO they actually do for bandwidth. I know there's a missing TCP/IP stack in there at the moment, but I remember how excited I was to see FTP @ 11MB/s bidirectionally simultaneously between two 195MHz SGI Octanes we had on loan, the fastest I had ever seen in actual performance over the network. Of course, those were ~$20K desktop with pipelined and super-scaler R10000 processors and probably 300 other chips. To do that with a P2Edge 32MB and a 2 chip ethernet interface on each side would be awesome, even if it is 25 years later.
What just came to my mind: We have to be careful with the data flow and synchronization in a EtherCAT slave device. Packets are received at the first port (from the master's direction) and transmitted to the second port (to the next slave). Those are handled by different PHY chips driven from different clock sources. So If we implement this with two ethernet PHY accessory boards they run from a different crystal each. The crystals have 20ppm frequency tolerance so after a complete packet with 1.5kB they should be off no more than 2.4ns which is less than one bit.
But just to be sure I would connect the two clocks together on a custom board. But two accessory boards should work OK for testing.
Anyway, I start with a master implementation which is much easier and should run perfectly with one accessory board and the existing driver software.
Ah, thanks for the hint. But doesn't really make much sense because
1. one DP83849 is €6/pc, two LAN8720 are $1.40
2. it doesn't save any PCB space, the TQFP80 is bigger than two QFN24
3. The LAN8720 is already in stock and I don't need to change the software
BTW do you know any single-chip ethernet switches with at least 4 ports and 100Mb/s? I need some for a different project where I can't buy an off-the-shelf switch.
Edit: found the KSZ8895, is also quite expensive (€12.50). The cheaper ones seem to have no integrated PHYs but RMII interfaces for each port.
@rosco_pc said:
What about max linear GSW140A3MC (6 port with 4 integrated PHYs)
Ah thanks, that one is quite cheap and offers everything I need. The magnetics for GBit are more expensive but I think it should fall back to 100Mb automatically if only two pairs are connected.
edit: but BGA package
Yes that is really nasty. I don't have problems with standard BGA packages (with all-occupied square ball patterns). But that MRQFN package has interleaved balls with 0.25mm offsets. It would take days to teach my old P&P machine the optical centering. Maybe I can just get away with mechanical centering.
I've done some further research on EtherCAT. The problem is that only parts of the information is available publicly. You have to sign contracts to get the full specification and even then some important details of the slave device implementation is secret. Now, I have taken a deeper look into the documents and found out that some of my assumptions were wrong.
There is actually a 4-pin connector for EtherCat but it is different from the standard M8 or M12 connectors used for sensors because it needs a shield.
So it's still quite expensove, around $20 for the cable plug and >$5 for the PCB socket.
My explanation of the Ethernet frame layout was a bit oversimplified.
Actually, it is not sufficient to copy a range of bytes from the packet to local memory and replace it with a different content plus re-calculating the CRC. There is no fixed allocation of the sub-packet ranges to the slave devices. Instead, every sub-packet contains an address and a length field. Like with standard Ethernet addressing there are different modes of adressing, single target, broadcast and auto-numbering (based on location inside the chain). So a relatively complex algorithm is required to decide where the subpackets are and to which destination they belong. This all has to be processed in real-time on the fly. The location, length and addressing of the subpackets can change any time from frame to frame and nothing can be pre-calculated.
The driver for the physical and data link layer of the network can't be separated from the application layer, or in other words it is not possible to process the packet on a simple, abstract low level basis and then interpret its contents later. There is a "working counter" in each of the subpackets which has to be updated depending on wether the operation encoded in the data succeded or not. This requires immediate processing of the command and insertion of the result into the outgoing packet in real-time.
I don't say it would be completely impossible to implement a EtherCAT slave device in a P2 but it's definitely a lot harder than I first thought. My biggest problem is that a subpacket can start on any byte boundary but efficient processing of the RMII data stream requires long word operations. I know there are some ASM instruction for byte access to cog RAM (was it ALTGB, ROLBYTE?) but I haven't looked to closely if this is of any help.
And last but not least...
I had a conversation with the ETG executive director. He said that an open source slave device implementation would violate intellectual property rights of Beckhoff. While the mebership in the ETG (EtherCAT technology group), the use of EtherCAT equipment and master device implementations are free but selling slave devices requires licensing and a small fee per unit. If I released the source code I would be liable for any programmer who uses this code and doesn't play by the rules. Well, of course they claim this because the want to make money. There are probably ways to get around this but I have more joyful things to do than starting a legal dispute with a big company.
So I think buying an EtherCAT slave controller IC that already includes the license and implements all the critical protocol stuff is much easier. A LAN9252, for example, can be bought from LCSC for $7 and can easily be interfaced to the P2 via SPI so as long as there is no global chip shortage, again, there is little motivation to do it the hard way.
IANAL, but in order to achieve sufficient compatibility I think you’d struggle to make an argument that you arrived at your product without violating the T&Cs of the EtherCAT licence.
If you came up with something that competes without being compatible you’ll need something spectacularly better to swing the market in your favour.
Comments
Information is always welcome. But could you please stop posting pictures that promote or bash products that have nothing to do with the subject (or at least I don't get it).
I absolutely understand why, for example encoder, need a rediculously high resolution to get a good control of speed. Velocity is the derivation of position, so counts per millisecond naturally has 10 bits resolution less than the posiotion. 18bit of analogue (velocity) command also seems a lot. But a +/-300RPM speed range for a typical motor is 36000°/s. So 16 bit resolution or 15 bit + sign would give an LSB of 0.55°/s. I think that should be enough for most applications but if you want dither-free precision motion it's probably not.
Can you explain why jitter is a problem? How high is the jitter of the Beckhoff implementation? I think we could reduce this to almost zero with the P2. A P2 directly connected to a PHY chip can start a packet at any 50MHz clock edge. The receiver synchronizes that to his own 50MHz clock. So the jitter should be in the +/- 20ns range.
You named lots of problems with products of the big companies. But I still don't see that the EtherCAT specification is to blame for that. It might be that EtherCAT is not the optimum solution for your applications. As a small company, I think, neither me nor Parallax will be able to make a "revolution" or any kind of "jack of all trades" product. But any such attempts are doomed to fail anyway. Trying to "please them all" always leads to feature-itis and overwhelming complexity.
So what we can do is to devlop products that only serve a smaller market but are easy to use, simple and reliable. If you have objections why this is not possible with EtherCAT (and I don't mean "their" implementation but a nice, clean one) then please explain your reasons in detail.
There is no such thing as 100% certainty. If you insist on a second source for all of the components you use then you limit yourself to the stone-age of electronics with baking trays full of 74xx logic and OPAs. You have to commit to some manufacturer.
Parallax proved to be much more reliable than any other semiconductor company I know. Maybe it was just luck or the fact that they are so small that nobody cared to hoard and panic-buy their chips. But compared to others I had very little trouble during the COVID crises.
All I can advise is to play with EtherCAT for awhile...I have to deal with it and it's horrendous.
I read all about this distributed servo control with dozens of axes. Where are these things? My life is spent in factories 😐
The most I know of is 20 axes and it's my own invention/creation. I have lots of 17 axes but I have yet to see anything come close to this
Please note the rotary turret that runs 24/7. It's carrying 8 other servo axes that are constantly talking to the main controller. This was a no-brainer of a development....EtherCAT? Be my guest 😂🤣
Hardware>stage lighting>DMX>RS485>Robust XLR plugs/sockets
RJ45 in this brutal industrial environment?
It's just not happening with this guy.
Made sense to some limp-wristed design engineer, I guess, who has never experienced the plant floor 😁
Ethercat has a lot from CANopen, some conceptual simularities:
Take a reliable physical method (CAN/ethernet) and adapt it for SCADA. It relies only on trusted, widely available parts (CAN tranceiver/Ethernet Phy) and uses a standard interface (CAN /(R)MII)
I don't see a problem with the signaling as long as you use CAT5/6 cables.... and inserting into a bypassing ethernet packet ist quite ingenious, as it would allow in theory more than 100k packets/second i.e. about 10 us timing granularity,even though the controller does not use the whole bandwidth, Beckhoff works at 10kHz if i remember correctly. which is quite good for a networked system which can be distributed over a large space, in a big machine or factory..
at least in theory....
working with the vendor tools like Siemens STEP or Beckhoff is of course cumbersome for a real programmer but for engineers it might be a good tool
@ManAtWork This is quite impressive! I am watching Oct 18th's Propeller Liver Forum, and read this thread.
I would be very interested in a module that has everything I need to put 100BaseT networking, even at the MAC level. Do you have them for sale?
Do they use a single 8IO port?
Do they have their own crystal?
What is the actual data throughput you are getting after removing headers & CRCs?
The main reason to use Ladder Logic is to make the source code accessible to the electricians that work on site every day. It sure makes their life a lot easier when they can see what the machine is expecting rather than just guessing. If you detest the idea of letting others see your work then Ladder ain't the right choice.
On that note, using Ladder then locking out the customer is the dumbest move ever.
@hinv The forum search is no good - have a look at this thread: https://forums.parallax.com/discussion/174402/ethernet-phy-accessory-board/p1
also https://forums.parallax.com/discussion/comment/1547460/#Comment_1547460 ( Calculated optimal throughput = 12.19 MB/sec, one way)
No it is not automatic, it is operated with a foot switch; but if find this topic a bit macabre:/
Lol, the victim as the operator. I don't think so, the operator is the guy who buried the mine.
Anderson's tale involves a vain king who was preoccupied with his appearance and his wardrobe. A pair of swindlers took advantage of this by pretending to be able to weave the finest cloth, which couldn't be seen by people who were either unfit for office or were particularly stupid. The king decided to have a suit of clothes made from the fabric in order to test which of his courtiers was unfit for office. As he didn't want to appear stupid or unfit for rule himself, he pretended to be able to see the new clothes, as did all of his courtiers. He paraded the 'new clothes' through the streets and the onlookers, also not wishing to appear stupid, all admired them. A small child, who didn't understand the apparent necessity for pretence, piped up 'But he has nothing on!'. The bubble of pretence burst and soon all the onlookers were repeating what the child had said, whilst the king continued the procession, attempting to maintain his dignity by pretending that nothing had happened.
Today's control engineers: Yup that stuff is great, amazing in fact. Someone tell that stupid kid to shut up.
A standard is a standard is a standard...
The question is: if you were to sell, say, a motor controller, what would a customer look for? if Beckhoff is a thing, and @Mickster, you admit that, why not go for it? There are a multitude of interface types and each will cover a part of the potential market, or am i wrong? Most vendors include at least 2 interfaces with an optional 3rd one which can be outfitted as needed (RS485, EtherNet, EtherCAT, CANopen, RS232 (some even USB), etc...., maybe PCI (x), ... )
babylon is calling
in the lab equipment up to the recent years (before USB came along), you would find RS232 on all devices, which is perfectly fine, it just works and it was easy to interface... often a handbook would tell you right away which are the commands you can use ... too easy! ... just don't plug in the cable in the wrong port or have the wrong baudrate/etc. set O_o (if you find a USB port on a device, there is really just a ftdi chip inside which will create a virtual rs232 port in the computer, which will do the port swapping for you so you never know which device is on which port, how funny if you have more than one device connected which usually is the case)
It's funny. I, so far, have no idea what Mickster thinks is a good choice.
as far as i can tell he is advocating for something like RS485, which could be the 2nd option to have on the board - it's actually a good idea to have both, maybe already prepared on the board but not populated by default to save on BOM
the versatility of the Propeller's smart pins would make it easy to swap out ,,communication" modules, tiny boards that are soldered flat on the main PCB with a specific driver chip and connector for each imaginable interface, not unlike the Parallax Modules
Oh I have a choice. Have you spent time in the trenches where it's on you to bring a $1M/hour production line back to life?
The bright sparks who decided that an impossible-to-work-with technology are tucked-up in bed. Not fun.
I'll start a new thread because I feel like I'm stomping into @ManAtWork living room with muddy boots.
Apologies, Nicolas 👍
I tried to write some code how the inner loop of an EtherCAT transceiver could look like.
dataLoop waitse2 ' wait for packet data rdpin rxd0,pinRxd0 rdpin rxd1,pinRxd1 ' shift registers -> MSWs shr rxd0,#16 setword rxd1,rxd0,#0 ' combine rxd1:rxd0 mergew rxd1 ' shuffle bits rev rxd1 ' crcnib needs MSB first setq rxd1 rep #1,#8 crcnib rxCrc,rxPoly ' calculate RX CRC rflong mask and rxd1,mask rflong txd0 or txd0,rxd1 ' combine TX data and masked RX data mov txd1,txd0 rev txd1 setq txd1 rep #1,#8 crcnib txCrc,txPoly ' calculate TX CRC splitw txd0 ' even bits -> txd0 LSW getword txd1,txd0,#1 ' odd bits -> txd1 LSW wypin txd0,pinTxd0 wypin txd1,pinTxd1 ' feed smart pins djnz lenCnt,#dataLoopThe idea is that the fastest way to switch from "repeat incoming data" to "insert local data" and back again is to not switch at all. I mean I want to avoid conditional code, SKIPF and branches. Instead I pre-calculate an array of mask values and an array of overlay data. The overlay data replaces the incoming data for all bytes where the mask is opaque (0) and leaves it the same where the mask is transparent (1). The overlay data is 0 for all bytes where the mask is transparent (1), so it doesn't interfere with the incoming data. Mask and overlay data is stored interleaved. That wastes some memory (twice the packet length) but is fast and easy to handle.
If I counted correctly theese are 38 instructions and execute in at least 76 clocks. Storing the replaced incoming data to a local buffer is not included and takes at least another 2 instructions. So we'd need 80 clocks altoghether and therefore we need to run at 250MHz to be able to do it all in one cog. I'm not very happy with this and like to avoid over-clocking for industrial applications. So it might be a better idea to do it in two cogs and pass the data via shared LUT RAM or a long repository of a smart pin.
@Simonius OK, I finally have to agree with you. So we need 2 cogs for the downstream data (master to slaves) and one for the upstream port (simple repeater). 3 cogs seem a lot for a single communication interface. But I think 5 cogs left are still plenty for a simple slave device like a digital and analogue IO module. And for a sophisticated slave device like a servo controller it would save one cog for an additional configuration interface (RS232 or 485 serial port). That is no longer needed as the parameters and diagnosis data can also be transmitted over EtherCAT.
As @Simonius already said there is a thread about my ethernet accessory board. I have 5 units left but need at least two three of them for my own experiments (one master and slave with two ports).
Yes they have their own 25MHz crystal and they only need 8 IO pins. The MDIO configuration interface, the RMII interface and the I2C bus for the MAC address ROM share some of the pins.
Theoretically something >10MByte/s. So there is no limit other than the physical line speed. But you would run out of memory very quickly unless you can process the data really fast.
There are M12 connectors with 8 pins and IP67. But they are horribly expensive.
I wonder why they don't just use 5 pin M12 connectors. EtherCAT and 100Mb/s ethernet uses only 2 of the 4 twisted pairs, anyway. So 4 pins + shield would be enough.
One repository smartpin doesn't go far. If you're going to use two cogs for one driver you may as well make it a lutRAM sharing pair and get all that shared space along with its four event triggers.
Yeah, but what DO they actually do for bandwidth. I know there's a missing TCP/IP stack in there at the moment, but I remember how excited I was to see FTP @ 11MB/s bidirectionally simultaneously between two 195MHz SGI Octanes we had on loan, the fastest I had ever seen in actual performance over the network. Of course, those were ~$20K desktop with pipelined and super-scaler R10000 processors and probably 300 other chips. To do that with a P2Edge 32MB and a 2 chip ethernet interface on each side would be awesome, even if it is 25 years later.
What just came to my mind: We have to be careful with the data flow and synchronization in a EtherCAT slave device. Packets are received at the first port (from the master's direction) and transmitted to the second port (to the next slave). Those are handled by different PHY chips driven from different clock sources. So If we implement this with two ethernet PHY accessory boards they run from a different crystal each. The crystals have 20ppm frequency tolerance so after a complete packet with 1.5kB they should be off no more than 2.4ns which is less than one bit.
But just to be sure I would connect the two clocks together on a custom board. But two accessory boards should work OK for testing.
Anyway, I start with a master implementation which is much easier and should run perfectly with one accessory board and the existing driver software.
Makes sense. Also you could delay the sending routine a few nanoseconds to make sure you never run out of data.
There are dual port PHYs
for example DP83849C
Ah, thanks for the hint. But doesn't really make much sense because
1. one DP83849 is €6/pc, two LAN8720 are $1.40
2. it doesn't save any PCB space, the TQFP80 is bigger than two QFN24
3. The LAN8720 is already in stock and I don't need to change the software
BTW do you know any single-chip ethernet switches with at least 4 ports and 100Mb/s? I need some for a different project where I can't buy an off-the-shelf switch.
Edit: found the KSZ8895, is also quite expensive (€12.50). The cheaper ones seem to have no integrated PHYs but RMII interfaces for each port.
What about max linear GSW140A3MC (6 port with 4 integrated PHYs)
edit: but BGA package
Ah thanks, that one is quite cheap and offers everything I need. The magnetics for GBit are more expensive but I think it should fall back to 100Mb automatically if only two pairs are connected.
Yes that is really nasty. I don't have problems with standard BGA packages (with all-occupied square ball patterns). But that MRQFN package has interleaved balls with 0.25mm offsets. It would take days to teach my old P&P machine the optical centering. Maybe I can just get away with mechanical centering.
I've done some further research on EtherCAT. The problem is that only parts of the information is available publicly. You have to sign contracts to get the full specification and even then some important details of the slave device implementation is secret. Now, I have taken a deeper look into the documents and found out that some of my assumptions were wrong.
There is actually a 4-pin connector for EtherCat but it is different from the standard M8 or M12 connectors used for sensors because it needs a shield.
So it's still quite expensove, around $20 for the cable plug and >$5 for the PCB socket.
My explanation of the Ethernet frame layout was a bit oversimplified.
Actually, it is not sufficient to copy a range of bytes from the packet to local memory and replace it with a different content plus re-calculating the CRC. There is no fixed allocation of the sub-packet ranges to the slave devices. Instead, every sub-packet contains an address and a length field. Like with standard Ethernet addressing there are different modes of adressing, single target, broadcast and auto-numbering (based on location inside the chain). So a relatively complex algorithm is required to decide where the subpackets are and to which destination they belong. This all has to be processed in real-time on the fly. The location, length and addressing of the subpackets can change any time from frame to frame and nothing can be pre-calculated.
The driver for the physical and data link layer of the network can't be separated from the application layer, or in other words it is not possible to process the packet on a simple, abstract low level basis and then interpret its contents later. There is a "working counter" in each of the subpackets which has to be updated depending on wether the operation encoded in the data succeded or not. This requires immediate processing of the command and insertion of the result into the outgoing packet in real-time.
I don't say it would be completely impossible to implement a EtherCAT slave device in a P2 but it's definitely a lot harder than I first thought. My biggest problem is that a subpacket can start on any byte boundary but efficient processing of the RMII data stream requires long word operations. I know there are some ASM instruction for byte access to cog RAM (was it ALTGB, ROLBYTE?) but I haven't looked to closely if this is of any help.
And last but not least...
So I think buying an EtherCAT slave controller IC that already includes the license and implements all the critical protocol stuff is much easier. A LAN9252, for example, can be bought from LCSC for $7 and can easily be interfaced to the P2 via SPI so as long as there is no global chip shortage, again, there is little motivation to do it the hard way.
what if you just cloned parts of the specificiation and called it EtherDOG? would that count as copyright infringement?
IANAL, but in order to achieve sufficient compatibility I think you’d struggle to make an argument that you arrived at your product without violating the T&Cs of the EtherCAT licence.
If you came up with something that competes without being compatible you’ll need something spectacularly better to swing the market in your favour.