There's really no goal for these to do anything other than PtP with these solutions.
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.
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.
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?
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.