Discussing the differences between a conservative and a liberal he used an analogy of a fence, where a liberal would want to take it down and a conservative would want to leave it up.
It got me thinking if this was true or not.
A little digging and I found this page:
https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
"Although the purpose of this fence is not obvious, there may be valid reasons for its presence."
(I'd like to think I'm in the mindful middle somewhere)
I don't know this space, but depending it may be there are more messages going to and fro, and so perhaps more bandwidth is desired? IEEE 1394 ("FireWire") seems to have a bunch of 'industrial' uses:
* https://en.wikipedia.org/wiki/IEEE_1394#Common_applications
The marine folks went from a CAN-like NMEA 0183, to a more bus-like NMEA 2000, and are not looking at an Ethernet-based system:
* https://en.wikipedia.org/wiki/NMEA_2000
* https://en.wikipedia.org/wiki/NMEA_OneNet
If all you're doing is getting sensor values at a few Hertz, then CANbus is probably fine, but if you need to distribute the images of a read-view camera, a bunch sonars, a bunch of radars, etc, then the 500 kbit/s in J1939/14 may not be enough.
Even the 'CAN folks' recognize this:
Navigation and playing music? Both are done by other systems as CAN already.
Imagine something more complicated where you need specialized knowledge to troubleshoot things.
It’s like they want to complicate things so the average person can’t fix things themselves. They look at John Deere not in askance but in admiration for making things irreparable by ordinary folks.
Traditionalists like to point to its latency guarantees, but you can do just as well with a thoughtful Ethernet implementation. And there are single pair PHYs. Others argue in favor of the multidrop topology, but I see it as a common failure point. Plus it erodes the utility of the bandwidth.
For multiple drops I like CAN a lot better.
I mean, HTTP is quite old.
and CAN is a solid piece of tech. Ultra reliable, fast and low wire count. It's controllers are cheap and reliable.
I think the author is pointing at that concept, with the idea that CAN hasn't evolved over time in the same way as HTTP. Ideally there'd be a CAN2.0 for the cars that want it, that's backwards-compatible with CAN1.0 readers/etc.
If he works in this space, I would think he'd know that there are new things being worked on:
* https://en.wikipedia.org/wiki/CAN_FD
* https://en.wikipedia.org/wiki/FlexRay
Not that these seem to work differently at the OSI Layer 1/2 layer, so while older messages can be sent over the newer transport, it is not wire compatible.
As long as the new version of the protocol is still formatted on the higher OSI layers in terms of reusing the core messages from the old version, and then adding new messages that are optional to the understanding of what's going on from a CAN1.0 perspective, then a change in the PHY layer still isn't really throwing the baby out with the bath-water.
The cynic in me believes that Apple is so bought-in to its own hype that they have a need to change it for change's sake alone. Just like their pathological desire for thinner laptops with no practical benefit, they'll rail on about how this unnecessary churn is progress.
I think the Apple Car will be a buggy, unreliable, unrepairable mess that the buyers won't ever truly own.
I don't understand why the author keeps banging on about CAN bus being an old standard. So what?
CAN bus is used in the automotive industry because of it reliability and low wire count. Why should it be changed?