I downvoted you for random assumptions and insulting people you never talked to.
> a modern automatic transmission is controlled by firmware, a unikernel
Have you seen the source? If not, how do you know it's a unikernel?
> The shift points and the shifting logic are based on the developers' very dim understanding of economy and of performance driving
"dim understanding"? Do you have a reference for any of that? Why do you think it's developers, not mechanical engineers or engine testing that resulted in the shift threshold?
> there is often a significant latency involved - by the time the unikernel has managed to process all the inputs from all the sensors
Again, that's a heavy assumption unless you have a source for it. Also, from own experience in actually writing control software like that, real world sensors can be read tens/hundreds+ of times per second. But even with tiny 8K microprocessors you can process it more quickly. Mostly you sit in a tight loop and wait for new data. Processing it takes tiny fraction of the wait time.
> On top of that, the developers' opinions of what's acceptable and what makes sense are truly dim and utterly infuriating
Yeah... you're just throwing ad-hominem around. Please come post some sources which support your opinions.
More to the point, the sensors are either wired directly to the controller or data is retrieved over CAN. And there may not even be a spin-lock waiting for that data, data acquisition could very well be interrupt-driven.
The latency claim is totally unfounded, and anyone who has made use of an embedded platform (even as weak as PIC or Arduino) to collect data can see it as totally and utterly wrong.
The latency claim is totally unfounded, and anyone who has made use of an embedded platform (even as weak as PIC or Arduino) to collect data can see it as totally and utterly wrong.
Where is the latency coming from, then? Other than disputing what I wrote, no explanation of where the latency is coming from has so far been offered.
I will gladly accept an explanation where the latency is coming from, and have even listed concrete models, years, and scenarios to facilitate a concrete explanation. Please, have at it.
I have noticed systemic abuse of ad hominem labeling anyone who doesn't lavish high praise and criticizes instead.
Please show some emapthy and think about how the code could be improved instead, so these criticisms can be addressed with a practical solution.
In this particular case, all my criticisms can be addressed by offering a manual transmission option with a dry clutch, not even code optimization is required.
Also, as a firmware writer, you know that all such source code is under strict non-disclosure agreements, and whatever I know or have seen, I wouldn't be at liberty to discuss or cite, or else I risk legal penalties. We're neither anonymous nor protected here.
As for unikernel, any firmware or subsystem concerned with one task - such as running a vehicle - is by definition a unikernel - all firmware is, as its running one single monolithic application image.
Developers versus mechanical engineers - in this context a mechanical engineer is also a developer, just of the transmission, and they often write the software themselves, too.
Finally, as a firmware writer, please explain to me why there is a lag between depressing an accelerator pedal in a 2011 Volkswagen Golf, why the engine will often konk out unless the accelerator pedal is pressed fully when starting on a hill, and why a 2012 Buick LaCrosse will display "shift denied" on the dashboard when I try to upshift from 5th to 6th going at 1,400 RPM, which would put me at 1,200 RPM, well within the engine's ability to continue running efficiently?
Well, doesn't fuel flow need to be increased before acceleration can begin? That causes latency, much more than software would. Perhaps the software is causing a little bit of that, perhaps there's a simple delay loop instead of a sensor there and it's a little too long.
We'll never know, but there are plenty of guesses you could make.
> why the engine will often konk out unless the accelerator pedal is pressed fully when starting on a hill
That doesn't at all sound like a software problem. It sounds like you're conflating "I don't like my car" with "my car software sucks".
> upshift from 5th to 6th [...] 1,400 RPM [...] 1,200 RPM
Are you certain that upshifting like that would only drop you 200 RPM? Not at least 1000? I'm fairly certain that's not correct.
> [...] all my criticisms can be addressed by offering a manual transmission option with a dry clutch [...]
Just buy a manual car if you care so much. Or buy a journal and vent into that rather than the HN comment section. Goodness gracious.
Well, doesn't fuel flow need to be increased before acceleration can begin? That causes latency, much more than software would.
No, because the engine in question is a common rail diesel engine, which means that the fuel is kept under a constant pressure of 2,200 atmospheres, ready to be injected into the cylinders. The only thing that has to happen is for the piezoelectric injectors to open. On a vehicle with a common rail diesel engine without firmware, where the logic is hardwired electronics in the ECU, and the throttle is connected with a cable as opposed to drive-by-wire, such a thing does not occur: zero latency, instant response.
As I owned both types of vehicles, I was in the unique position to observe and experiment. These are vehicles from completely different manufacturers, one German, one Japanese. The Japanese diesel has no issues or problems whatsoever. That's the one I kept.
Not a single stall since going back to a mechanical throttle. And also, I've learned on a manual and have been driving them daily for decades.
And for the record, I had two firmware updates on the drive-by-wire model, and they only helped marginally with throttle response, but never fixed the issue.
> I have noticed systemic abuse of ad hominem labeling
You literally said it's due to developers' dim opinions. Lots of people don't like auto transmissions, and that's fine. Just chill about it.
> you know that all such source code is under strict non-disclosure agreements
Nope. Are you saying that all such code is under strict NDA? Likely, you can still say you signed one and cannot talk about it if that's the case.
> I wouldn't be at liberty to discuss or cite
As in, you cannot link to an existing, public article that supports what you're talking about? I call BS.
> any firmware or subsystem concerned with one task - such as running a vehicle - is by definition a unikernel
That's not a definition of a unikernel. You can easily have embedded systems with no kernel to speak of. It may be a unikernel, but since you're possibly under NDA you're not saying that, are you?
> Finally, as a firmware writer, please explain to me...
I'm not a the author of those systems, therefore I will not make assumptions about them. And I recommend the same to you.
What you're describing is behaviour and sure - they may behave like this for some reason. Blaming that on a specific part of the system, or technology, or developers that are dim and do stuff without a reason, without a good proof is neither useful nor helpful.
You literally said it's due to developers' dim opinions.
I did, and I stand by what I wrote: the product is bad, no matter how you slice it and dice it! But to label a generalized categorization based on anecdotal yet empirical experiments as ad hominem is outrageous. In my view, that is wanton abuse on equal grounds with censorship and other repressive measures, just because someone on the Internet doesn't like what someone else on the Internet wrote.
Lots of people don't like auto transmissions, and that's fine. Just chill about it.
That is a very personal issue for me, because driving is a physical and mental activity that I undertake intensely every day, and take it way more seriously than the average person. If I could chill about it, I would not have commented in the first place. But if one does not report what's broken, it will never get fixed:
"we can't fix it if we don't know it's broken."
Now, I don't mind having that choice, but when it means that it messes with my capability to choose a manual, because none is offered, that is where I have a major problem. If people want to drive automatics, I don't like it, but it's their choice and in general I don't care, as long as I can have my choice available, a manual. Live and let live. However, the situation is not developing in that direction, quite the opposite.
You can easily have embedded systems with no kernel to speak of.
Any firmware is an unikernel unless it is running as a generic operating system with generic processes and running multiple, distinct applications, or capable or running more than one single application. Otherwise, if the firmware is one single image running as one single monolithic body of code, they are one and the same. BIOS firmware, for example, is a unikernel. OpenBoot PROM is a unikernel. ECU firmware is a unikernel.
It may be a unikernel, but since you're possibly under NDA you're not saying that, are you?
Okay, you got me. I may not say anything. Well played, well played, I salute you.
> a modern automatic transmission is controlled by firmware, a unikernel
Have you seen the source? If not, how do you know it's a unikernel?
> The shift points and the shifting logic are based on the developers' very dim understanding of economy and of performance driving
"dim understanding"? Do you have a reference for any of that? Why do you think it's developers, not mechanical engineers or engine testing that resulted in the shift threshold?
> there is often a significant latency involved - by the time the unikernel has managed to process all the inputs from all the sensors
Again, that's a heavy assumption unless you have a source for it. Also, from own experience in actually writing control software like that, real world sensors can be read tens/hundreds+ of times per second. But even with tiny 8K microprocessors you can process it more quickly. Mostly you sit in a tight loop and wait for new data. Processing it takes tiny fraction of the wait time.
> On top of that, the developers' opinions of what's acceptable and what makes sense are truly dim and utterly infuriating
Yeah... you're just throwing ad-hominem around. Please come post some sources which support your opinions.