autoconf is in no way, shape or form an "official" build system associated with C. It is a GNU creation and certainly popular, but not to a "monopoly" degree, and it's share is declining. (plain make & meson & cmake being popular alternatives)
You're saying it yourself: it's a target of influence campaigns. The Wikimedia Foundation ìs not a source of them itself.
The non-profit public benefit service they provide is the openly editable encyclopaedia wiki, not its contents or its editors. The same safe harbour provisions as with other content hosters should (and need to) apply as with YouTube hosting questionable videos.
"Oh good, what with being out of engineers to fire and having exhausted all other options, they're finally doing the right thing and fire some management."
(Though this is probably bureaucrats and C-levels at best, not the board which really deserves a firing.)
You're comparing CAN with classic Ethernet. You should be comparing CAN with SPE (Single Pair Ethernet), which was developed to replace CAN (among other things) and is in fact well on its way on doing just that - cars are getting built using it.
Even if we compare CAN to Single Pair Ethernet, most of my points still stand, do they not?
SPE is still more expensive and complicated than CAN, but also much more capable (higher data rates etc.). PHY power consumption is much lower compared to traditional Ethernet, but still on another level compared to CAN.
I’ve seen Ethernet chosen mostly when CAN (or RS485 etc.) is too slow or you want longer distances (cabling).
I mean to clarify my point - not to bicker :) I don’t think I disagree with any of your points
I'm not actually sure 10base-T1S (which is the closest equivalent to CAN) uses more power than CAN. The maximum current rating for some random T1S PHYs is actually lower than that of some random CAN PHYs, but actual power consumption depends on bus usage patterns…
Regarding being expensive and complicated… I'd say that's a question of proliferation. And the non-multidrop SPE variants are actually simpler than CAN in some regards I'd argue.
Okay, interesting! Thanks for enlightening me. I’ll look into SPE.
W.r.t. my point with “complicated and expensive”. Most IP-stacks require low double digit kilobytes of memory, where CAN can be much cheaper (can also be much heavier depending on the “CAN stack”), which rules out the cheapest MCUs.
When I was in embedded, most cheaper MCUs (32bit <100MHz single core, 16kb SRAM etc.) didn’t support Ethernet as a native peripheral. I.e. required a jump from a Cortex M3 to M4 for instance. I haven’t followed things for around a decade though..
It's not about bandwidth; combustion engines used to be massive EMI disasters (due to ignition coils) wrecking electronic communications in their immediate vicinity. Fibre optics are plain noise immune. Not sure how much of this is needed with high power electric motors.
They're also lighter than copper cables, which can in fact matter in a car (though changing interconnect types and topologies also fixes that.)
Electric motors are - almost by definition - giant, fast moving magnets. That will generate current in any nearby wiring, and thus interference.
That said, this kind of interference is much easier to filter than the kind you'd get from 4 to 8 spark plugs firing in sequence. So it's pretty likely that this is easier to deal with.
Are fiber optic cables flexible and tough enough? Fiber optic seems to be good for fixed deployments but not exactly fit for a rough&tumble environment like a car.
Long answer: you need to choose appropriate connectors and fibre types. There's more to fibre than just OM5 and OS2 on LC connectors. Disaster recovery agencies as well as militaries use fibre cabling in temporary camp / communication infrastructure setups too, with ruggedized cables and connectors. There's 50+ years of history and experience to source from.
"Counter" answer: copper cables in cars also break.
Industrial Ethernet uses 100Mb speeds because (and when) those are sufficient for their use cases. There is no technical limitation there. 1000base-T1 (and even 2.5, 5 & 10G SPE¹) show where this is going.
Huh, I didn't know single pair ethernet went up that fast - neat! We're still living in the 100Mbit world at my company - and, yeah, it's fast enough for pretty much everything we need.
If you grab statistics per photo rather than the whole thing, and maybe do rough client geolocation, you can turn this into a sociological study and publish a paper about it…
UPER is extremely compact encoding format. It still makes sense to use UPER, because after all, it is an international standard and telecommunication protocols itself are supposed to add as little overhead on top of actual payload as possible.
For example, if you have ASN.1 UTF-8 string that is constrained to 52 specific characters - UPER encoding can present every character with 6 bits (not bytes).
In modern world you can apply zlib on top of UPER encoding or internal payload, however, depending on the use case.
autoconf is in no way, shape or form an "official" build system associated with C. It is a GNU creation and certainly popular, but not to a "monopoly" degree, and it's share is declining. (plain make & meson & cmake being popular alternatives)
reply