Yes, I understand that. But for industrial and automotive applications 1msec is fast. Automakers can’t afford i7 octo-core processors, especially since they use a distributed processor architechture. Plus, that loop time includes a lot bips within that loop.
On the 9 mph electric forklifts I worked with we prototyped a vision recognition system on a laptop to identify pallets. We could only run it about 3/4s of the lift speed of the forks. My engineer worked for quite a while to code that into a dedicated chip to do those calculations within the forklift’s 35 msec control loop time.
Old Henry Ford was a stickler for vertical integration so that he controlled all of the main processes for his cars-where he could. In Minnesota he had his own power plant and even made his own glass to be used. The current style is bent on out-sourcing as much as they can so all they do is the assembly and sales. Buy all your switches off shore and when there is a disruption for whatever reason, you are in trouble. 101.
GM was strongly vertically integrated as well… until they weren’t and spun their parts divisions off and created Delphi. Ford followed suit and created Visteon. Both spin offs went into bankruptcy.
I think the change was largely a result of labor costs. It became too expensive to keep an all UAW labor force and they had to find a way to cut costs to compete with the not-UAW manufacturers. Wages, primo benefits, work rules, it all adds up. I’m not complaining about labor unions, just suggesting that all the good they did for members had negative ramifications as well.
Visual recognition is demanding. Unless I’m mistaken, running a car driven by a human being uses only sensors that deliver clear signals, not image analysis. Self-driving cars will require as much processing as a good gaming computer.
Gaming requires a lot of processing because it renders so many images, not because of the input it handles.
Still high cost, and that did nothing for work rules that tend to inflate the labor roster. When I worked in the steel mill, we thought that the mill could work efficiently with half the employees. It doesn’t matter what the hourly rate was when twice the employees needed were getting paid. BTW, the hourly guys I worked with in a tiger team agreed with working efficiently with half the crew.
No, they are the cheapest sensors available and not very clean. And much is estimated by software. Plus diagnostics…the stuff that throws the CEL… run all the time.
It isn’t easy to accurately fire spark in a V6 at 4000 rpm with direct fuel injectors that pulse multiple times per intake cycle and properly time the variable intake and exhaust cams while monitoring both throttle pedal sensors, sending the proper signal to the throttle by wire while monitoring its feedback all while collecting and filtering the crappy signals from the sensors you do have, creating signals with software, controlling the evap system and sharing all the signals with other distributed systems.
And that doesn’t even begin to describe what the engine control computer does to control the automatic transmission.
Not to mention the contant monitoring of other controllers that need the engine computer to do things FOR those systems…reduce power for the stability control system for example.
It is easy for someone who drives obsolete techology to think this task is easy. It is not easy.
I7 is used in many distributed architectures. We use them in ours.
But that’s my point…relatively speaking the chips used in Auto’s aren’t that sophisticated. Many chips are analog chips which is much better suited for an automotive application. They usually don’t run an operating system. Strictly dedicated code for the task it’s designed for.
Most of the ecu processors are digital with as many A/D inputs as needed and digital output drivers. PWM drivers are often used because they can be variable current drivers or peak-hold drivers. That allows all the control logic to be digital. Makes it flexible and easily communicated over CAN. Engine ecus need lots of A/D inputs and output drivers these days for engine and transmission control.
Preferably you want then running from the same system. Separating things just makes it more complicated If your rpm graphics are rendering from data received from a separate system you’re going to probably see that the lag is perceptible.
It’s really not that difficult once it’s all set up and you have the hardware in the system it’s simply a matter of inputting the parameters and letting the computer figure it out. And then the system is adaptable to your entire lineup. It’s why manufacturers just make one car and platform and then derive endless variations from it. And then they just tune in the feel that they want electronically rather than the old way.
This probably wouldn’t have to take a lot of processing.
They should run on interrupts.
I don’t see how it takes much processing.
I was thinking about it as a computer engineer. It’s not a lot of data, it doesn’t require a response fast compared to a computer’s processing speed.
It may not be easy, but the hard part won’t be solved in software.
I made a mistake earlier: when I wrote that Linux is fast and small, I compared it to other general purpose operating systems. Someone who’s using no operating system, or some operating system customized to target hardware, should be smaller and faster. The larger point I meant to make with the example, that Linux is hardware-independent, is the important point. Allegedly Tesla wrote hardware-independent software, the other companies didn’t, why they suffered from the current chip shortage while Tesla didn’t. I have to think they’ll follow.