5 ms·

The interfaces with devices over SPI/I2C etc is interesting. There's actually some other interesting developments in this area - 10Base-T1S and 10Base-T1L are r

The interfaces with devices over SPI/I2C etc is interesting. There's actually some other interesting developments in this area - 10Base-T1S and 10Base-T1L are recent standards that are designed to allow ethernet packet communication over much more lightweight multi-drop networks - basically allowing a small network of interconnected devices to talk ethernet to each other (and the outside world, via a bridge) without the requirement for bulky and expensive traditional ethernet transformers. https://www.microchip.com/en-us/solutions/ethernet-technology/single-pair-ethernet/10base-t1s https://www.microchip.com/en-us/solutions/ethernet-technolog... I don't think there's wide silicon support yet - but the prospect of a small network of sensors which communicate over ethernet, which can be effortlessly bridged to a standard network is quite nice.

amluto 4y ago
Not just sensors — entire devices and ecosystems of devices could use this, internally and for expandability. Anything that currently uses an RS-485-based protocol or even CAN could potentially switch.
- ilyt 4y ago
  But..why ? Surely just having some IP-over-CAN and using all of the existing CAN-equipped micros would be easier/cheaper?
  - ooterness 4y ago
    IP over CAN is fine, but the useful throughput is limited. Overhead is very high because the frames are so short--64 useful bits in every 108-bit frame--so you end up repeating the headers many times. That limits effective throughput to about 600 kbps on a 1 Mbps shared bus. (And the nature of the shared bus means that's a single throughput budget for all attached devices.)
  - danielheath 4y ago
    Being able to sell a sensor that plugs into the existing network?
    - ilyt 4y ago
      They can already do that ? ...do you think CAN bus is some unpopular thing you can't get anything off the shelf on ?
      - danielheath 4y ago
        It's not a connector that's _already_ available on 99.9% of the planets network installs. Customers have to buy additional hardware to use your thing.
  - bsder 4y ago
    CAN kinda sucks. It's limited to 8 bytes per transaction and the baud rates are generally pretty slow (<1Mbps). There's no good reason to use CAN anymore now that 10Base-T1S exists.
    - ilyt 4y ago
      It seems like overkill in the other direction, CAN bus uses don't need the overhead of ethernet+IP
      - 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
ilyt 4y ago
> without the requirement for bulky and expensive traditional ethernet transformers. Not that expensive or bulky. You can also run ethernet reasonably well after replacing inductors with caps: https://www.ti.com/lit/an/snla088a/snla088a.pdf https://www.ti.com/lit/an/snla088a/snla088a.pdf

amluto 4y ago

Not just sensors — entire devices and ecosystems of devices could use this, internally and for expandability. Anything that currently uses an RS-485-based protocol or even CAN could potentially switch.

ilyt 4y ago
But..why ? Surely just having some IP-over-CAN and using all of the existing CAN-equipped micros would be easier/cheaper?
- ooterness 4y ago
  IP over CAN is fine, but the useful throughput is limited. Overhead is very high because the frames are so short--64 useful bits in every 108-bit frame--so you end up repeating the headers many times. That limits effective throughput to about 600 kbps on a 1 Mbps shared bus. (And the nature of the shared bus means that's a single throughput budget for all attached devices.)
- danielheath 4y ago
  Being able to sell a sensor that plugs into the existing network?
  - ilyt 4y ago
    They can already do that ? ...do you think CAN bus is some unpopular thing you can't get anything off the shelf on ?
    - danielheath 4y ago
      It's not a connector that's _already_ available on 99.9% of the planets network installs. Customers have to buy additional hardware to use your thing.
- bsder 4y ago
  CAN kinda sucks. It's limited to 8 bytes per transaction and the baud rates are generally pretty slow (<1Mbps). There's no good reason to use CAN anymore now that 10Base-T1S exists.
  - ilyt 4y ago
    It seems like overkill in the other direction, CAN bus uses don't need the overhead of ethernet+IP
    - 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

ilyt 4y ago

> without the requirement for bulky and expensive traditional ethernet transformers. Not that expensive or bulky. You can also run ethernet reasonably well after replacing inductors with caps: https://www.ti.com/lit/an/snla088a/snla088a.pdf https://www.ti.com/lit/an/snla088a/snla088a.pdf