4 ms·

It seems like overkill in the other direction, CAN bus uses don't need the overhead of ethernet+IP

by ilyt 4y ago

bsder 4y ago
Except ... that they always wind up there eventually. CAN is primarily useful if you have a broadcast node that only has a small amount of data to send at periodic intervals. The problem is that as soon as you start adding round trips, CAN starts not looking so good. Which message are you referring to? How are you validating that you aren't getting duplicate messages? etc. Finally, when you need more than 8 bytes, everything falls into a heap. You have to start putting in sequence numbers (which take up parts of your 8 byte packets), holding things for reassembly, etc. Once you reach that point, you might as well just use Ethernet. The main issue back when it was developed was that CAN was way cheaper than Ethernet when CAN was released in 1986. The problem is that Moore's Law is a thing. There have been about 25 iterations of Moore's Law since then decreasing the cost differential. CAN MACs are not really more expensive than Ethernet MACs, and Ethernet MACs get WAY more testing. CAN PHYs are only really cheaper than the 10Base-T1S Ethernet PHYs (which are faster) and are comparable to standard Ethernet PHYs in cost (which are WAY faster). At this point, you're just better off using Ethernet. It's about the same price, significantly faster, and far better tested.
- ilyt 4y ago
  I guess when we get demand we will also get microcontrollers that integrate more and more of it. Still it feels like replacing outdated solution with ill-fitting one. >Finally, when you need more than 8 bytes, everything falls into a heap. You have to start putting in sequence numbers (which take up parts of your 8 byte packets), holding things for reassembly, etc. Once you reach that point, you might as well just use Ethernet. But on other side ethernet overhead on just sensors is huge. The minimum payload is 46 bytes (in 64 byte frame), so sending say just a 2 byte temperature sensor data is 32x of overhead vs CANs 4x (IIRC 8 byte packet for 2 byte value. For 8 byte CAN only have 1.75x overhead while ethernet frame still has 8x overhead. So in sensor-filled device like car you'd be getting far lower real throughput than the 10Mbit/s. And the sensors will want to broadcast to whoever listens anyway so a good part of the frame is wasted. Some kind of ethernet light where say: * frames can be as short as few bytes * destination address can be skipped and receiving devices treat it as broadcast would double or triple the throughtput. > CAN MACs are not really more expensive than Ethernet MACs, and Ethernet MACs get WAY more testing. Average car have dozens, I'm pretty sure CAN MACs are tested well enough lmao, what a non-argument
  - ooterness 4y ago
    > Some kind of ethernet light where say: frames can be as short as few bytes... On that note: To keep overhead low for sensors, SatCat5 does not impose a minimum frame length on SPI or UART interfaces. i.e., The minimum payload length is zero bytes. You still have 18 bytes of overhead (destination, source, EtherType, FCS) per Ethernet frame, but that is still a huge win for the low-speed interfaces that need it most. For compatibility's sake, runt-frames are zero-padded (and FCS updated) before transmission on conventional Ethernet interfaces (*MII). But typically those are running at 100+ Mbps so the impact is acceptable.
ooterness 4y ago
It's worth noting that you can use Ethernet without a full IP stack. Protocols like CoAP are specifically designed to run on a UDP-only stack (ARP/ICMP/IP/UDP) to save on code-space for tiny microcontrollers. If you only need local connectivity, raw-Ethernet messages have even less overhead.

It seems like overkill in the other direction, CAN bus uses don't need the overhead of ethernet+IP

by ilyt 4y ago

It seems like overkill in the other direction, CAN bus uses don't need the overhead of ethernet+IP

Except ... that they always wind up there eventually. CAN is primarily useful if you have a broadcast node that only has a small amount of data to send at periodic intervals. The problem is that as soon as you start adding round trips, CAN starts not looking so good. Which message are you referring to? How are you validating that you aren't getting duplicate messages? etc. Finally, when you need more than 8 bytes, everything falls into a heap. You have to start putting in sequence numbers (which take up parts of your 8 byte packets), holding things for reassembly, etc. Once you reach that point, you might as well just use Ethernet. The main issue back when it was developed was that CAN was way cheaper than Ethernet when CAN was released in 1986. The problem is that Moore's Law is a thing. There have been about 25 iterations of Moore's Law since then decreasing the cost differential. CAN MACs are not really more expensive than Ethernet MACs, and Ethernet MACs get WAY more testing. CAN PHYs are only really cheaper than the 10Base-T1S Ethernet PHYs (which are faster) and are comparable to standard Ethernet PHYs in cost (which are WAY faster). At this point, you're just better off using Ethernet. It's about the same price, significantly faster, and far better tested.

ilyt 4y ago
I guess when we get demand we will also get microcontrollers that integrate more and more of it. Still it feels like replacing outdated solution with ill-fitting one. >Finally, when you need more than 8 bytes, everything falls into a heap. You have to start putting in sequence numbers (which take up parts of your 8 byte packets), holding things for reassembly, etc. Once you reach that point, you might as well just use Ethernet. But on other side ethernet overhead on just sensors is huge. The minimum payload is 46 bytes (in 64 byte frame), so sending say just a 2 byte temperature sensor data is 32x of overhead vs CANs 4x (IIRC 8 byte packet for 2 byte value. For 8 byte CAN only have 1.75x overhead while ethernet frame still has 8x overhead. So in sensor-filled device like car you'd be getting far lower real throughput than the 10Mbit/s. And the sensors will want to broadcast to whoever listens anyway so a good part of the frame is wasted. Some kind of ethernet light where say: * frames can be as short as few bytes * destination address can be skipped and receiving devices treat it as broadcast would double or triple the throughtput. > CAN MACs are not really more expensive than Ethernet MACs, and Ethernet MACs get WAY more testing. Average car have dozens, I'm pretty sure CAN MACs are tested well enough lmao, what a non-argument
- ooterness 4y ago
  > Some kind of ethernet light where say: frames can be as short as few bytes... On that note: To keep overhead low for sensors, SatCat5 does not impose a minimum frame length on SPI or UART interfaces. i.e., The minimum payload length is zero bytes. You still have 18 bytes of overhead (destination, source, EtherType, FCS) per Ethernet frame, but that is still a huge win for the low-speed interfaces that need it most. For compatibility's sake, runt-frames are zero-padded (and FCS updated) before transmission on conventional Ethernet interfaces (*MII). But typically those are running at 100+ Mbps so the impact is acceptable.

ooterness 4y ago

It's worth noting that you can use Ethernet without a full IP stack. Protocols like CoAP are specifically designed to run on a UDP-only stack (ARP/ICMP/IP/UDP) to save on code-space for tiny microcontrollers. If you only need local connectivity, raw-Ethernet messages have even less overhead.