5 ms·

One of the key differentiators is that most of these standards are point-to-point--they only connect 2 devices. So, it doesn't work very well for replacing thi

by bsder 5y ago

One of the key differentiators is that most of these standards are point-to-point--they only connect 2 devices. So, it doesn't work very well for replacing things like CAN. 10Base-T1S is multidrop on single pair--which is basically a CAN replacement. Unfortunately, I haven't seen much movement at all in the T1S space.

JAlexoid 5y ago
I have yet to see a reasonable case for CAN replacement, as it's good enough. Maybe we'll get more wireless connectivity from the IoT space, but that's probably not immediate. There's really no goal for these to do anything other than PtP with these solutions.
- kevin_thibedeau 5y ago
  CAN doesn't scale to high data rates.
  - gumby 5y ago
    But the underlying RS-485 has nice noise rejection and is dead easy to manage.
    - bonzini 5y ago
      Are you confusing CAN with ModBus-RTU perhaps? The wires are similar, but RS485 uses differential encoding for both 0 and 1 while CAN only uses it for 1. In CAN, 0 is represented by lack of difference between the two wires.
      - bonzini 5y ago
        Correcting myself, actually CAN is the opposite: 1 (recessive state) is lack of difference, 0 (dominant state) is presence.
      - gumby 5y ago
        Yes, I more recently used modbus and lazily conflated them in my memory.
- bsder 5y ago
  CAN is lousy if your messages are larger than 8 bytes. And, invariably, your messages eventually end up larger than 8 bytes. Then you have to deal with CANOpen and your life becomes hell. I also find some of the CAN architecture decisions kind of questionable nowadays. A lot of stuff like ACK and retransmit in the hardware made sense back when microcontrollers were expensive. Nowadays, its just something that chip implementors are likely to screw up that you can't fix with software.
- myself248 5y ago
  Module reflashing. The effective data rate of a 1Mbps CAN network is about 180kbps of payload. Barely faster than dialup. And CanFD doesn't improve as much as you'd think, because all the overhead still runs at 1Mbps. If you've ever moved a few meg of firmware over CAN, you know how agnozingly slow that turns out to be in practice. Which is fine enough in development, okay, go get a coffee and chat with the other engineers for a bit, it'll be done soon enough. But in the field, incentives change: At the dealer, reflashes are usually not paid by the customer, so time is money in the negative sense. Get the car done as fast as possible and go back to work that pays. For over-the-air reflashing, it's even worse. You have to guess that the car is gonna be parked for a while (or get user consent), and perform the reflash before they change their mind and decide to go for a drive again. A 2-minute reboot on a phone is obnoxious enough, a 20-minute reflash for one module is a death knell for OTA, and if you need to update several modules at once in order for their versions to be in sync, that can well take an hour or longer. Absolutely unacceptable. PtP is fine because it's just one pair, and you're running back to a gateway module anyway. The gateway module houses the flash memory lake that stages the OTA update packages. When you get the go-signal, blast those out to all the affected modules, finish in 2 minutes, and the car is driveable again. This is HUGE. Everyone on HN mocks automakers-other-than-tesla for not having OTA figured out yet, and Ethernet is a key enabling technology for it.
- castratikron 5y ago
  The use case for 10BASE-T1S isn't quite clear to me. I get that you can do multidrop ethernet, which would simplify things a lot; no need to add switches or daisy chain anymore. And it's also not too slow, and you only need two wires. But are microcontrollers with ethernet common? How cheap are they? A MAC needs a lot of pins compared to CAN which will increase footprint. And to really take full advantage of ethernet, you need a good networking stack and a solid set of utilities and applications on top. So Linux is the way to go in that case. But then you need a big processor with external RAM, eMMC, PMIC, several layer board, and don't forget a couple of Linux weirdos (speaking as one) who can actually develop in that environment. A lot of embedded guys can understand CAN pretty easily; show them gRPC and their heads may explode. So I guess the use case is: embedded system with a lot of Linux boards that don't need that much bandwidth? Does that accurately reflect the architecture of a modern car?
  - bsder 5y ago
    > But are microcontrollers with ethernet common? How cheap are they? Define "common". However, they are available. I see some right around $4 from ST. > A MAC needs a lot of pins compared to CAN which will increase footprint. Normally the pins on the connector are far more critical than the pins on the microcontroller. RMII takes up 9 pins on the microcontroller. > And to really take full advantage of ethernet, you need a good networking stack and a solid set of utilities and applications on top. So Linux is the way to go in that case. But then you need a big processor with external RAM, eMMC, PMIC, several layer board, and don't forget a couple of Linux weirdos (speaking as one) who can actually develop in that environment. A lot of embedded guys can understand CAN pretty easily; show them gRPC and their heads may explode. You are WAY too high-level. UDP works just fine for a lot of applications and takes next to nothing in terms of resources. And TCP doesn't require as much resource as you think (remember TCP dates back to the 1980s when memory was scarce). Even straight HTTP isn't too bad. The biggest problem is HTTPS. That invokes a whole crapload of overhead.
johnwalkr 5y ago
It's able to supply power over the same two wires (in the point to point case and the multidrop case), IEEE calls it PoDL (power over data line) and I think it supports about 100W in total for one pair. Even in the point to point case, this could offset the demerit of losing multidrop. Multidrop with 100Mbps and 100W of power would be a gamechanger. About 2 years ago I tried to make a prototype using 100baseT1 with PoDL but most of the components weren't on the market yet. I did manage to get samples of some but not all parts, and gave up and kept using this[1] tiny switch. There's also a 1000base-T version. One thing to note about using ethernet in embedded applications, and also the reason why you can't find many small microcontrollers that support it, is ethernet uses a lot of power. About 0.5W per port (meaning 1.0W per line) for 100Mbps, 0.7W per port for 1Gbps, and 4W per port for 10Gbps. There are low-power standards that work by idling when not in use, but I've yet to see any devices that support it. The 2 wire standards are designed for much, much lower power consumption. [1]https://gadgetsmyth.com/product/ethos-lite/ https://gadgetsmyth.com/product/ethos-lite/
mastax 5y ago
Lots of the PHYs I've seen are 2-port switches for daisy-chaining. Cost about 50% more.

by bsder 5y ago

JAlexoid 5y ago

I have yet to see a reasonable case for CAN replacement, as it's good enough. Maybe we'll get more wireless connectivity from the IoT space, but that's probably not immediate. There's really no goal for these to do anything other than PtP with these solutions.

kevin_thibedeau 5y ago
CAN doesn't scale to high data rates.
- gumby 5y ago
  But the underlying RS-485 has nice noise rejection and is dead easy to manage.
  - bonzini 5y ago
    Are you confusing CAN with ModBus-RTU perhaps? The wires are similar, but RS485 uses differential encoding for both 0 and 1 while CAN only uses it for 1. In CAN, 0 is represented by lack of difference between the two wires.
    - bonzini 5y ago
      Correcting myself, actually CAN is the opposite: 1 (recessive state) is lack of difference, 0 (dominant state) is presence.
    - gumby 5y ago
      Yes, I more recently used modbus and lazily conflated them in my memory.
bsder 5y ago
CAN is lousy if your messages are larger than 8 bytes. And, invariably, your messages eventually end up larger than 8 bytes. Then you have to deal with CANOpen and your life becomes hell. I also find some of the CAN architecture decisions kind of questionable nowadays. A lot of stuff like ACK and retransmit in the hardware made sense back when microcontrollers were expensive. Nowadays, its just something that chip implementors are likely to screw up that you can't fix with software.
myself248 5y ago
Module reflashing. The effective data rate of a 1Mbps CAN network is about 180kbps of payload. Barely faster than dialup. And CanFD doesn't improve as much as you'd think, because all the overhead still runs at 1Mbps. If you've ever moved a few meg of firmware over CAN, you know how agnozingly slow that turns out to be in practice. Which is fine enough in development, okay, go get a coffee and chat with the other engineers for a bit, it'll be done soon enough. But in the field, incentives change: At the dealer, reflashes are usually not paid by the customer, so time is money in the negative sense. Get the car done as fast as possible and go back to work that pays. For over-the-air reflashing, it's even worse. You have to guess that the car is gonna be parked for a while (or get user consent), and perform the reflash before they change their mind and decide to go for a drive again. A 2-minute reboot on a phone is obnoxious enough, a 20-minute reflash for one module is a death knell for OTA, and if you need to update several modules at once in order for their versions to be in sync, that can well take an hour or longer. Absolutely unacceptable. PtP is fine because it's just one pair, and you're running back to a gateway module anyway. The gateway module houses the flash memory lake that stages the OTA update packages. When you get the go-signal, blast those out to all the affected modules, finish in 2 minutes, and the car is driveable again. This is HUGE. Everyone on HN mocks automakers-other-than-tesla for not having OTA figured out yet, and Ethernet is a key enabling technology for it.
castratikron 5y ago
The use case for 10BASE-T1S isn't quite clear to me. I get that you can do multidrop ethernet, which would simplify things a lot; no need to add switches or daisy chain anymore. And it's also not too slow, and you only need two wires. But are microcontrollers with ethernet common? How cheap are they? A MAC needs a lot of pins compared to CAN which will increase footprint. And to really take full advantage of ethernet, you need a good networking stack and a solid set of utilities and applications on top. So Linux is the way to go in that case. But then you need a big processor with external RAM, eMMC, PMIC, several layer board, and don't forget a couple of Linux weirdos (speaking as one) who can actually develop in that environment. A lot of embedded guys can understand CAN pretty easily; show them gRPC and their heads may explode. So I guess the use case is: embedded system with a lot of Linux boards that don't need that much bandwidth? Does that accurately reflect the architecture of a modern car?
- bsder 5y ago
  > But are microcontrollers with ethernet common? How cheap are they? Define "common". However, they are available. I see some right around $4 from ST. > A MAC needs a lot of pins compared to CAN which will increase footprint. Normally the pins on the connector are far more critical than the pins on the microcontroller. RMII takes up 9 pins on the microcontroller. > And to really take full advantage of ethernet, you need a good networking stack and a solid set of utilities and applications on top. So Linux is the way to go in that case. But then you need a big processor with external RAM, eMMC, PMIC, several layer board, and don't forget a couple of Linux weirdos (speaking as one) who can actually develop in that environment. A lot of embedded guys can understand CAN pretty easily; show them gRPC and their heads may explode. You are WAY too high-level. UDP works just fine for a lot of applications and takes next to nothing in terms of resources. And TCP doesn't require as much resource as you think (remember TCP dates back to the 1980s when memory was scarce). Even straight HTTP isn't too bad. The biggest problem is HTTPS. That invokes a whole crapload of overhead.

johnwalkr 5y ago

It's able to supply power over the same two wires (in the point to point case and the multidrop case), IEEE calls it PoDL (power over data line) and I think it supports about 100W in total for one pair. Even in the point to point case, this could offset the demerit of losing multidrop. Multidrop with 100Mbps and 100W of power would be a gamechanger. About 2 years ago I tried to make a prototype using 100baseT1 with PoDL but most of the components weren't on the market yet. I did manage to get samples of some but not all parts, and gave up and kept using this[1] tiny switch. There's also a 1000base-T version. One thing to note about using ethernet in embedded applications, and also the reason why you can't find many small microcontrollers that support it, is ethernet uses a lot of power. About 0.5W per port (meaning 1.0W per line) for 100Mbps, 0.7W per port for 1Gbps, and 4W per port for 10Gbps. There are low-power standards that work by idling when not in use, but I've yet to see any devices that support it. The 2 wire standards are designed for much, much lower power consumption. [1]https://gadgetsmyth.com/product/ethos-lite/ https://gadgetsmyth.com/product/ethos-lite/

mastax 5y ago

Lots of the PHYs I've seen are 2-port switches for daisy-chaining. Cost about 50% more.