Automotive Chip Shortage is as much about the "type of chips" as it is about overall capacity

[Dracarris]

40 minutes ago, leadeater said:

This is either done through an angled worm gear or a belt connection, basically the steering wheel to steering rack is a lose connection until the electric assist fails then it's a tight connection.

Interesting. The only thing that left me wondering: When adjusting the turn angle steering wheel vs. turn angle actual wheels relation depending on speed there must be some "slipping through" or a continuous gearbox in between said mechanical link.

[leadeater]

9 minutes ago, Dracarris said:

Interesting. The only thing that left me wondering: When adjusting the turn angle steering wheel vs. turn angle actual wheels relation depending on speed there must be some "slipping through" or a continuous gearbox in between said mechanical link.

Only some have dynamic turn rates, those have clutches in them and connection between the wheel and steering pinion slips so they can turn at different rates.

 

Edit:

Also I think it only activates at really low speeds for parking

[RedRound2]

3 hours ago, CarlBar said:

Kind of irrelevant point. It is in no way not acceptable for the companies to meet those protections and tolerances even if no one's checking, (unless of course something goes wrong and then they will check in excruciating detail).

My point was, no one does extreme validation on these things because its not all that common for things like this to go wrong. The question brought here initally is not about rewriting softwares or logic, but whether the new processors would undergo bit flips that messes up the calculation thereby causing problems. That is unlikey. As long as the new processor node can do assembly level operations as reliably as the old one, there should not be any problems

3 hours ago, CarlBar said:

An i3-10300 doesn't meet the temperature range spec, let alone the rest of it. And thats before we get into packaging it to meet all of the vibration, shock loading, grime exposure, dirty power, RF noise, e.t.c. factors. one of thats trivial or easy. Could it be done. Sure. But it's not quick or cheap to do. it takes time and effort to do.

This was just an example

I didnt actually mean they were using an i3 processor. Just update whatever processor they were using to newwer version. It's probably an ARM chip, so update the ARM chip to its newer version on the newer node

[RedRound2]

6 hours ago, leadeater said:

No it doesn't, that's just another assumption. You do know the all cars, even basic ones have O2 sensors, sometimes EGT sensors, and fuel flow and fuel type adjustments that happen in real time. Also spark timing as well, crank position sensors, value timing and position. Other stuff I've either forgotten or don't even know about.

 

Even if we go with the assumption an Arduino could run in a sterile lab type environment you have no idea in what way it would fault and create senor read errors at high temperatures, low temperatures or shock vibration and just because you've got some basic error handling code does not mean when the hardware itself it faulting that it'll get handled correctly.

Again you're talking about the environement. Do you have any issues with comprehension. Do you not understand that drawing parallels like "Mango and watermelon grows in tropical climates" does not mean that mangoes and watermelons are the same

 

The software logic is simple. There isnt any machine learning algorithms, or AI, rather finely tuned and timed (timing done with crystal oscillator) software that shouldnt really care on what processor or what device it is running on as long as it gets the data from where needs and is able to send data where it needs. Yes, an Arduino could do that. No Arduino is not supposed to be used anywhere where you need reliability.

Quote

Wrong. I like how you are so sure of yourself that you didn't even bother to look at what IATF 16949 is.

This is an inspection. What makes you think that newer nodes wouldnt pass this inspection?

Quote

Do you even know what any of the computer systems in cars look like and how they are designed?

Good god. Did you not see "or whatever part is"? It was again drawing comparisons. Just use the updated version of the ARM chip or whatever they use, that will most likely be in a newer node

Quote

Tesla has almost never done a full platform update of any of their vehicles, they introduced knew ones. I don't think you know what a vehicle platform is.

 

BMW E30, E36, E46, E93, those are vehicle platforms. How many of these has Tesla done for any of their models of cars?

Platform here meant software platform. Context is important. Can you please read properly before going into a tantrum whenver you reply to me with whatever preconcieved notion you have of me

Tesla frequnetly updates their software. They've changed their software and autopilot AI stack many times, including the recent vision only update. A bug from the software is more likely to cause issues then tried and tested processor node flipping bits.

 

So it's a bit stupid when you dont inspect the foundation layout of the building but rather go inspect if the metals used have the exact composition of alloys to 4 decimal marks (Again, if this went over your head, its a comparison).

Quote

We have extremely close to that, only breaks are not this. We have electric throttle control and electric power steering. Electric power steering uses torque input from your steering inputs and relays this to an electric motor, your steering wheel output is not directly connecting to the steering rack anymore which is where the primary complaints from lack of car feel come from. Further to this many types of electric power steering systems have dynamic input adjustment at different driving speeds so the turn rate is not a fixed amount. While there is fallback to manual steering wheel control there is still the danger that the electric motors not operating correctly or doing erroneous steering control.

Throttle is electrical. Never claimed it wasnt so I have no idea why you mentioned it. Steering is hydrallic assisted (power steering), but it can be turned mechanically as well. Next time, go to a car that turned off and try turning the steering. The wheels actually turn (it's mindblowing) - until it auto locks. The hydrallic and motor does the work in assistance in parallel with mechanical linkage while driving the car.

 

So in an emergency, brakes and steering will still work

Quote

There is no mechanical fall back for electronic throttle control however.

Never claimed for it to have.

Quote

Your post is full of so many assumptions and so little understanding. Electric motor control is actually simpler than a combustion engine as well, comparing the engine management between the two isn't even worth the effort.

You dont seem to able to grasp or understand what I am writing here. 

I'm not talking about software revamp, im not talking about entire architecture or platform revamp. Just replacing the damn processor with a newer node. You dont need to change anything else all that much and even any changes that might be required are very simple to do. As long as the newer chip doesnt randomly bit flip or can't add 1+1 (and all the basic operations) reliably, there's literally nothing to so grandeous in this task

Quote

I don't even know why you think I'm even slightly anti Tesla, just addressing your wildly misinformed assumptions about ECU complexity and testing. There's really good reason manufacturers use the same ECU across multiple car platform updates because there can often be no reason to update that component. Toyota does this the most, Honda as well and which two car brands are most know for reliability? I wonder why that is.

I never said you are anti Tesla. Is english not your first or even second language?

 

No, all you did was try to sound smart by throwing in all car terms to make it seem complicated when this we've been doing this shit with 90s technology (I'm damn sure today's Arduino is more capable than those chips). You dont seem to grasp what I'm trying to say. And all the new high end cars, after Tesla, especially the EV version do have competant infortainment systems. All these things can easily be implemented in all vehicles as well. If Apple's iPad with A13 costs $329 (which includes their massive profit margins as well) there's no excuse for a car over $10,000 to have a half something half as good as an iPad. ECUs are even more basic.

 

Car relaibility includes hundreds of other things as well. So whatever argument you tried to make with Toyota and honda literally hold zero water

 

And dont you dare quote cherry pick lines to and twist the narratives in your own way to cause a pointless argument like you usually do. Address the entire paragraph like a real person. Otherwise I'll just deem this conversation with you as a waste of my time and ignore everything else

[Kisai]

15 hours ago, GDRRiley said:

I'm use to non powered steering. Its not that bad and I'm 20

One time, I had a dealership loaner car for a day, and the steering on the (compact) car was so stiff, it was worse than the lawn tractor. I could not understand how anyone could drive that car unless it was something they've been driving the entire time and have the muscles built up for it.

 

15 hours ago, GDRRiley said:

for some products it doesn't make senses to shrink as you gets no real benefits.

but when it comes to infotainment and the such yeah they need to update the back end.
I get why though they struggle to update the computer parts on the mechanical side. I assume its mostly 10 year product cycles

 

Since the 80's, pretty much all cars have been "platform"'s, like Product X from GM, Product Y from Buick, Product Z from Cadillac, etc are exactly the same car other than the actual materials and engine choice. One classic example of this is the difference between a Lexus and a Toyota, where counterfeit Lexus LS/ES cars are literately just the Toyota Camry model rebadged (you can literately buy kits to do this.)

 

Not only that, but there is also China, where there are outright lifted western car designs.

https://driving.ca/lexus/auto-news/entertainment/top-10-chinese-rip-off-cars-vs-their-original-designs

They look similar, but it's almost a certainty that the computer parts and the materials (such as fabric choices) are different.

 

Anyway, my guess with, at least western car manufactures (eg GM and Ford) is that they are guilty of doing the same thing Intel was doing with their 14nm process, and sticking to a platform for longer than reasonable, where the low cost to manufacture the older parts was dependent on a supply chain commitment. 

 

And to be fair, it's largely the shipping of parts from Asia that has screwed North America, I'm sure it's not just Intel producing chips.

[leadeater]

31 minutes ago, RedRound2 said:

Again you're talking about the environement. Do you have any issues with comprehension.

No I'm talking about environmental conditions not the environment. Can you please stop and think. Environmental conditions are the conditions under which equipment operates not environmental emissions controls. These are totally different things.

 

Take an Arduino and put it in a freezer, that's an environmental condition. Did you know Arduino are not designed for this and the device itself can fault in ways you have no idea and in ways it would be impossible to code protect from because of the way an Arduino works. As such an Arduino cannot do what an ECU can.

 

31 minutes ago, RedRound2 said:

Yes, an Arduino could do that. No Arduino is not supposed to be used anywhere where you need reliability.

No it really probably cannot. You have absolutely no idea the type of logic design is required for a processor to efficiently take in sensor data of these types, general purpose processors are actually very bad at this, even high end desktop CPUs.

 

But even this is irrelevant to the point, one you keep missing. If an Arduino cannot operate without error at freezing and below, extreme heat and vibration then it CAN NOT do the job. No amount of ifs and buts apply here, it cannot do it.

 

31 minutes ago, RedRound2 said:

This is an inspection. What makes you think that newer nodes wouldnt pass this inspection?

When and where did I say they wouldn't or couldn't. Again this is only a conversation about your flaw understanding or regulation compliance and testing for components of vehicles, nothing more nothing less.

 

This testing is not uncomplicated and non timing consuming like you keep trying to say.

 

31 minutes ago, RedRound2 said:

You dont seem to able to grasp or understand what I am writing here. 

I'm not talking about software revamp, im not talking about entire architecture or platform revamp.

No you don't, you replied to me about my point on how traditional car manufactures update their vehicle platforms. Don't try and pass off your lack of understand of my point by saying I do not understand. Go back and read the original post now that you actually understand what an vehicle platform actually is then you won't be confused and post non relevant points.

 

You have near zero understanding of this point, why are you persisting with this, it's actually painful.

 

All car manufactures update car component during platform updates, never any other time unless it's due to a fault and product recall that necessitates a design or component change. An ECU is simply never going to be updated in the same way Tesla does because that's not how the other car companies work, my original point.

 

52 minutes ago, RedRound2 said:

I didnt actually mean they were using an i3 processor. Just update whatever processor they were using to newwer version. It's probably an ARM chip, so update the ARM chip to its newer version on the newer node

Nicely demonstrated with this. No they are not ARM processors.

[StDragon]

12 minutes ago, Kisai said:

One time, I had a dealership loaner car for a day, and the steering on the (compact) car was so stiff, it was worse than the lawn tractor. I could not understand how anyone could drive that car unless it was something they've been driving the entire time and have the muscles built up for it.

I've owned an 80's hatchback without power steering. So basic that it had a manual transmission with hand-cranks for the windows.... Anyways, it's not a bad experience, you get used it. You'll quickly learn to not turn the wheel before getting some movement. The movement of the vehicle will aid in turning the wheel for you. For example: If you're needing to turn right at an intersection and you're approaching the red light, you point the car in the direction before coming to a complete stop. When proceeding, you don't grunt the wheel right first, you get the car moving first, then turn the wheel. After while it become second nature and it really is a non-issue.

That all said, I'd rather have power steering with a heavier vehicle.

[igormp]

7 hours ago, RedRound2 said:

The code you write should be typically not for one specific processor.

Except it is. You more often than not code for bare metal in those cases, and hardly ever deal with abstraction layers that you're used to, like a web browser or even a proper operating system.

7 hours ago, RedRound2 said:

All of you are justifying car manufacturers with shitty systems, but you know ever since Tesla entered the race and lit a fire under their butts about acutally having a good EV and software experience, these people are starting to come out with cars with massively improved systems running on the roads today that they definitely have not tested for more than a year at max)

Tesla only came out with a fancy infotainment system that coordinates the other sub-systems. Your other subsystems are still pretty similar to what's found in common cars. Even if manufacturers went with the latest and greatest for their infotainment systems (which is often the case, you want a smooth experience with lots of apps on android auto/apple car/whatever else), the remaining of the subsystems is still pretty "archaic", even for a tesla.

 

7 hours ago, RedRound2 said:

And all im saying is replace that 13-950 with an i3-10300 or whatever it is.

We're talking about real time systems, even a microcontroller swap from another of the same family, same pin count with with slightly different clock speeds would required tons of validation and testing for frame timing and whatnot.

 

18 minutes ago, RedRound2 said:

Good god. Did you not see "or whatever part is"? It was again drawing comparisons. Just use the updated version of the ARM chip or whatever they use, that will most likely be in a newer node

 

7 minutes ago, Kisai said:

Anyway, my guess with, at least western car manufactures (eg GM and Ford) is that they are guilty of doing the same thing Intel was doing with their 14nm process, and sticking to a platform for longer than reasonable, where the low cost to manufacture the older parts was dependent on a supply chain commitment. 

Uhhhh, I see that the article didn't make something clear.

 

It's not the manufacturers themselves who want to stay on older nodes, but most microcontrollers are fabbed on older process nodes because there's no financial reason to go with newer ones. For most manufacturers (and embedded use cases in general) there's no reason to go with the latest and greatest, you just want the cheapest thing that can do the task at hand properly. There's a reason the 8051 is still being sold at large, even if intel doesn't even care about it anymore.

 

The same microcontroller can be fabbed in a different process node, sure, but that requires both new validation from the IC manufacturer (because you'll have different electrical characteristics), from the car manufacturer, and a price revision that you'll need to negotiate. There's usually not much of a problem swapping out some microcontrollers during a platform change, but the pandemics happened during the middle of existing platforms, and building a new one takes many years anyway.

 

Also, infotainment systems usually use newer CPUs, much like phone SoCs but hardened for longer lifespan and wider temperature range, in somewhat newer nodes, and yet there's a lack of those anyway. Some manufacturers (at least here in my country) are swapping out fancy infotainment systems for simple radio ones due to availability.

 

8 minutes ago, leadeater said:

No they are not ARM processors.

Some are! I worked on some RKE systems using ARM-based microcontrollers from nordic. You find all kinds of weird archs inside a single car, be it a 8051, avr, or even one of those weird archs from Infineon.

[RedRound2]

It's quite flattering that you ignored everything else I said because you understood something this time. But obviously, I cant expect you to admit that, can I. If you take a look at my post history, I at least admit when I am proven wrong

1 minute ago, leadeater said:

No I', talking about environmental conditions not the environment. Can you please stop and think. Environmental conditions are the conditions under which equipment operates not environmental emissions controls. These are totally different things.

 

Take an Arduino and put it in a freezer, that's an environmental condition. Did you know Arduino are not designed for this and the device itself can fault in ways you have no idea and in ways it would be impossible to code protect from because of the way an Arduino works.

 

No it' really probably cannot. You have absolutely no idea the type of logic design is required for a processor to efficient take in sensor data of these types, general purpose processors are actually very bad at this, even high end desktop CPUs.

 

But even this is irrelevant to the point, one you keep missing. If an Arduino cannot operate with error at freezing and below, extreme heat and vibration then it CAN NOT do the job. No amount of ifs and buts apply here, it cannot do it.

Oh my goodness. Like I literally cant dumb this down further. What the hell did you think the word environement meant in my reply? 

 

I have not even at any instance in time said that an Arduino should be used in an actual vehicle. NO.

 

I said the calculations and logics performed by an ECU can be done with an Arduino.

 

IF YOU STILL DONT UNDERSTAND, I'll try one more time

 

Disclaimer: This is a comparison

 

The computation perseverance mars rover can do can be easily performed by a smartphone processor from 2015. Should it be used? NO. Those chips are not made to withstand the radiation and temperature. But nonethless the "complex calculations" that you mentioned can be done on Arduino. Implication being, the software isn't too complicated for it to just go wrong. 

1 minute ago, leadeater said:

When and where did I say they wouldn't or couldn't. Again this is only a conversation about you flaw understanding or regulation compliance and testing for components of vehicles, nothing more nothing less.

So basically you still couldnt prove to me my original claim on why a newer processor would be such a headache to pass these tests

1 minute ago, leadeater said:

This testing is not uncomplicated not not timing consuming like you keep trying to say.

Sure, when many cars have software platforms rewritten overnight, you go inspecting the metals. I had a added another comparison for you in my previous reply, which ill copy below since you probbaly didnt see it

30 minutes ago, RedRound2 said:

So it's a bit stupid when you dont inspect the foundation layout of the building but rather go inspect if the metals used have the exact composition of alloys to 4 decimal marks (Again, if this went over your head, its a comparison).

1 minute ago, leadeater said:

No you don't you replied to me about my point on how traditional car manufactures update their vehicle platforms. Don't try and pass off your lack of understand of my point by saying I do not understand. Go back and read the original post now that you actually understand what an vehicle platform actually is then you won't be confused and post non relevant points.

 

You have near zero understanding of this point, why are you persisting with this, it's actually painful.

The funny thing is i never even talked about upgrading vehicle platforms. I just said modernize the mucroprocessors they use. That shouldn't change anything all that much to even warrant a platform upgrade. But whatever, twist my words to whatever you want

[leadeater]

2 minutes ago, igormp said:

Some are! I worked on some RKE systems using ARM-based microcontrollers from nordic

Huh interesting, RKE = Remote Key Entry? Guess I can see why it can be used there.

[RedRound2]

2 minutes ago, igormp said:

Except it is. You more often than not code for bare metal in those cases, and hardly ever deal with abstraction layers that you're used to, like a web browser or even a proper operating system.

Why is it so? I can't really think of any reason why it needs to be bare metal code. Can you also provide any sources that corroborates the same?

2 minutes ago, igormp said:

Tesla only came out with a fancy infotainment system that coordinates the other sub-systems. Your other subsystems are still pretty similar to what's found in common cars. Even if manufacturers went with the latest and greatest for their infotainment systems (which is often the case, you want a smooth experience with lots of apps on android auto/apple car/whatever else), the remaining of the subsystems is still pretty "archaic", even for a tesla.

Are you sure about that? Again I need something to ensure that your assumption about ECUs tesla uses are old and that there is a reason apart from financial reason to stick with it. 

And my whole point of people arguing about that everyhting in a car needs to go through thorough testing is that, the main software of today's car changes without all that much testing. All the testing protocols would be next to pointless, if the main software isn't validated as much (and would be much more complex in comparison as well).

2 minutes ago, igormp said:

We're talking about real time systems, even a microcontroller swap from another of the same family, same pin count with with slightly different clock speeds would required tons of validation and testing for frame timing and whatnot.

Yup, I know. But some people claim its 4+ years for those. I never said that it shouldn't be tested. I just said that probably a 100 protptypes for 1 year is more than enough validation to catch any sort of random bit flips

 

[CarlBar]

17 minutes ago, RedRound2 said:

Oh my goodness. Like I literally cant dumb this down further. What the hell did you think the word environement meant in my reply? 

 

I have not even at any instance in time said that an Arduino should be used in an actual vehicle. NO.

 

I said the calculations and logics performed by an ECU can be done with an Arduino.

 

IF YOU STILL DONT UNDERSTAND, I'll try one more time

 

Disclaimer: This is a comparison

 

The computation perseverance mars rover can do can be easily performed by a smartphone processor from 2015. Should it be used? NO. Those chips are not made to withstand the radiation and temperature. But nonethless the "complex calculations" that you mentioned can be done on Arduino. Implication being, the software isn't too complicated for it to just go wrong. 

 

So what exactly was your point. Because at this point i have absolutely no clue whatsoever what point your trying to make here. I'm genuinely completely and utterly confused.

 

The whole thing me and @leadeater are discussing is about the specifics of the the hardware, not the software. Having great software means nothing if your hardware is unstable in the operating environment it has to exist in, because at that point it will start outputting garbage data. 

[leadeater]

27 minutes ago, RedRound2 said:

So basically you still couldnt prove to me my original claim on why a newer processor would be such a headache to pass these tests

Well there is your problem with is entire conversation from the start then. I in fact have. The problem is you still think a processor (these are not just processors but ok) can't just be updated but that itself demonstrates a fundamental lack of understanding of how ECUs are actually built.

 

You claimed that the testing for it isn't complex and hard yet it is, I've given you one industry standard all vehicle parts suppliers must adhere to as a business to even be allowed to be put in to any car at all. This requires consistent auditing to prove they are meeting the quality control standards required of them, so that includes auditing the test and compliance reports for all parts.

 

As for parts that go anywhere near engines, engine control and fuel systems then they will be certified and tested to ISO 8846, will not be the only one and I'm not expert but I'm also not the one claiming and assuming this stuff is simple to do. On the basis that the vehicle industry is very heavily regulated I assert that it is unlikely.

 

How about instead you explain how and why you think it is such a simple process to test and certify these devices? You've claimed that it's not hard, shouldn't take long so lets hear what you think the process is.

[igormp]

7 minutes ago, RedRound2 said:

The funny thing is i never even talked about upgrading vehicle platforms. I just said modernize the mucroprocessors they use. That shouldn't change anything all that much to even warrant a platform upgrade. But whatever, twist my words to whatever you want

It does, but it's more related to logistics and business contracts. Again, why would you waste your time testing for a silly small microcontroller (out of 100s) inside a car when you can just revamp most of the platform in the next gen?

 

6 minutes ago, leadeater said:

Huh interesting, RKE = Remote Key Entry? Guess I can see why it can be used there.

Yep. ARM has a lot of traction on embedded, even in automotive. ISA is not that important when compared to peripherals, pricing and availability, so it's not surprising that most µC manufacturers are buying already made cores from ARM (M0s and whatnot) and slapping their peripherals out there. The fact that you can work with most compilers is a big plus too.

 

1 minute ago, RedRound2 said:

Why is it so? I can't really think of any reason why it needs to be bare metal code. Can you also provide any sources that corroborates the same?

Why should it not be? When you're dealing with something in such scale, spending 6 months more of dev time is worth it when you can shave a couple cents on a microcontroller that will be bought by the millions.

 

Also, most simpler microcontrollers don't even make sense to use a RTOS to begin with. Take for example the rpm sensor or the actuator from an ABS, it's something simple that even an arduino could do, as you said.

 

I can't find a proper source, but I guess this gives a glimpse on the whole idea: https://semiengineering.com/bare-metal-programming/

 

5 minutes ago, RedRound2 said:

Are you sure about that? Again I need something to ensure that your assumption about ECUs tesla uses are old and that there is a reason apart from financial reason to stick with it. 

Some ECUs are new, sure, but remember that there are hundreds of those, and there's no reason to get an all powerful SoC for the ABS system I mentioned above, those are still made with simpler microcontrollers, and those are old and simple because there's no reason to update them.

 

Anyway, tesla did update ~19 of their microcontrollers to avoid the issue some manufacturers are facing:

https://electrek.co/2021/05/03/how-tesla-pivoted-avoid-global-chip-shortage/

https://insideevs.com/news/522749/tesla-replaced-semiconductors-with-microcontrollers/

 

Testing out 19 new systems is not an easy feat, and tesla is also not widely known for reliability anyway.

 

9 minutes ago, RedRound2 said:

And my whole point of people arguing about that everyhting in a car needs to go through thorough testing is that, the main software of today's car changes without all that much testing. All the testing protocols would be next to pointless, if the main software isn't validated as much (and would be much more complex in comparison as well).

There isn't a "main" software (well, maybe in teslas). It's more like a distributed mess akin to a large k8s deployment. Have a nice slide from a presentation from volvo:

 

12 minutes ago, RedRound2 said:

Yup, I know. But some people claim its 4+ years for those. I never said that it shouldn't be tested. I just said that probably a 100 protptypes for 1 year is more than enough validation to catch any sort of random bit flips

Eh, might be, but doing such testing and changing the whole production line and whatnot for a single chip sounds cumbersome. Better wait for the new platform anyway.

 

I'm not sure, but I believe tesla only has a single platform for each of their models, and maybe even some models even share the same platform (which is pretty much the same platform since the model was launched), so that's why they're eager to update small components instead of changing the whole platform (who knows when)

[CarlBar]

6 minutes ago, igormp said:

Why should it not be? When you're dealing with something in such scale, spending 6 months more of dev time is worth it when you can shave a couple cents on a microcontroller that will be bought by the millions.

 

Also, most simpler microcontrollers don't even make sense to use a RTOS to begin with. Take for example the rpm sensor or the actuator from an ABS, it's something simple that even an arduino could do, as you said.

 

TBh I imagine for a lot of it it's probably built in at the silicon level, there's not software as such, just a series of sufficiently complex fixed function elements that interact to produce a dynamic output based on expected input parameters with maybe an error state output for warning and diagnostic purposes if the inputs fall outside what it can cope with.

[leadeater]

32 minutes ago, RedRound2 said:

The funny thing is i never even talked about upgrading vehicle platforms. I just said modernize the mucroprocessors they use. That shouldn't change anything all that much to even warrant a platform upgrade. But whatever, twist my words to whatever you want

Because for everyone not Tesla this is done during a platform update 

 

This isn't your opinion of if that could be done this is a fact of how other car companies operate. It's not going to happen any other time, it could, it's not going to though which was my point.

[igormp]

5 minutes ago, CarlBar said:

TBh I imagine for a lot of it it's probably built in at the silicon level, there's not software as such, just a series of sufficiently complex fixed function elements that interact to produce a dynamic output based on expected input parameters with maybe an error state output for warning and diagnostic purposes if the inputs fall outside what it can cope with.

Fixed function hardware is expensive, microcontrollers are cheap. I guess those "dynamic outputs" you mean are just regular analog signals from some sensors, those still need to be read by a microcontroller and sent to the bus.

[Tenelia]

On 9/20/2021 at 9:41 PM, RedRound2 said:

-snip- mentioned anywhere that any new tech needs to be tested for a minimum of 4 years before it hits the road? That's what I wanted to know. I get the temperature, durability, reliability aspect of the certifications. -snip-

if that's the case, 4 years of testing might mean it'd be better for them to prep for something like 7nm, since the rest of the industry would have moved on by then... Right? That'd make it more worthwhile once automakers are ready for production.

[igormp]

2 minutes ago, Tenelia said:

if that's the case, 4 years of testing might mean it'd be better for them to prep for something like 7nm, since the rest of the industry would have moved on by then... Right? That'd make it more worthwhile once automakers are ready for production.

No, having everything at 7nm is expensive, and isn't even needed. Also, the amount of manufacturers available for such small nodes is minimal, while for processes at 45nm+ are vast and wide: https://en.wikipedia.org/wiki/List_of_semiconductor_fabrication_plants

 

Most simpler µCs are made on such thicc nodes, while only the most advanced ones are made at 28nm. You people need to stop thinking everything is a intel, amd or other consumer, high performance parts.

[leadeater]

1 minute ago, igormp said:

Fixed function hardware is expensive, microcontrollers are cheap. I guess those "dynamic outputs" you mean are just regular analog signals from some sensors, those still need to be read by a microcontroller and sent to the bus.

Not sure what is actually used in relation to engine ECUs but the biggest problem talked about for those is the timing and precision required. When you've got things rotating at 5000+ RPM and you have different events triggered at different degrees of rotation and these themselves are dynamic based on other sensor parameters and configured offsets variance in timing matters quite a bit.

 

And this extends to the sensor data types, communications protocols and conversions as well as the ability of the processing unit being able to do all the calculations in the required time. The end to end process needs to be done in very small amounts of time with very little variance in timings.

 

I can't be bothered to math it out but someone else already has thankfully.

 

Quote

7000RPM is 116.6667 revs/sec; x360 degrees/rev gives 42000 degrees/sec. This is 23.81uS/degree or 2.381uS/tenth-degree.

Therefore to do a cycle-by-cycle update to the ignition timing you have 720-degrees of time or 17.14mS. That's a fair chunk of time to do a spark advance calculation.

 So if you want to adjust the spark advance by 0.5 degrees the accuracy required to actually achieve that level of control is really tight. It's actually quite amazing we can do these things.

 

Throw in variable timings across the RPM range as well. It's not "hard" coding just a nice feat of engineering that we have these levels of precision.

[igormp]

1 minute ago, leadeater said:

Not sure what is actually used in relation to engine ECUs but the biggest problem talked about for those is the timing and precision required. When you've got things rotating at 5000+ RPM and you have different events triggered at different degrees of rotation and these themselves are dynamic based on other sensor parameters and configured offsets variance in timing matters quite a bit.

That's actually the easy part, 5000+ rpm is less than 90 rotations per second (or 90hz), even the most simple microcontroller nowadays runs at well over 1MHz, so doing such math and achieving that precision is quite simple.

 

2 minutes ago, leadeater said:

And this extends to the sensor data types, communications protocols and conversions as well as the ability of the processing unit being able to do all the calculations in the required time. The end to end process needs to be done in very small amounts of time with very little variance in timings.

Now communication and message passing through a bus with limited bandwidth and capacity is where it gets hard. I even started to work on a model that could try to allocate CAN messages in a fixed way meeting some constraints, but shit is hard, it's easier to just add a new bus when one gets saturated 

 

4 minutes ago, leadeater said:

So if you want to adjust the spark advance by 0.5 degrees the accuracy required to actually achieve that level of control is really tight. It's actually quite amazing we can do these things.

Even the most dumb computer is pretty fast, even an arduino uno (which became really used as an example in this thread haha) runs at 16MHz, meaning it can do something every 62.5 NANOsecond, so i can adjust the spark advance and stay idle 99% of the time (I know it's exactly not like that, but should still be within the same order of magnitude). It really puts into perspective how powerful our desktops/phones are haha

 

6 minutes ago, leadeater said:

Throw in variable timings across the RPM range as well. It's not "hard" coding just a nice feat of engineering that we have these levels of precision.

The precision itself is kinda overestimated IMO, as shown above, but the whole coordination and communication required between all of the components is what amazes me.

[Dracarris]

21 minutes ago, leadeater said:

 So if you want to adjust the spark advance by 0.5 degrees the accuracy required to actually achieve that level of control is really tight. It's actually quite amazing we can do these things.

 

Throw in variable timings across the RPM range as well. It's not "hard" coding just a nice feat of engineering that we have these levels of precision.

Well that is achieved by fixed-function hardware that is connected as a peripheral within the MCU - called timers. They can generate waveforms down to 1/f granularity with f being their clock frequency. With a 1MHz timer clock you already achieve 1 us granularity. The CPU doesn't synchronously toggle GPIOs or such to trigger spark gaps etc. It asynchronously reprograms the timers, meaning there will be 1 or 2 revolutions where the engine runs with suboptimal timing but giving the CPU ample time to do complex calculations for optimal timing.

 

If you want to optimize every single revolution with such fine resolution there is no way around very high clocks (100s of MHz) and basically disabling all but emergency interrupts.

[leadeater]

8 minutes ago, igormp said:

That's actually the easy part, 5000+ rpm is less than 90 rotations per second (or 90hz), even the most simple microcontroller nowadays runs at well over 1MHz, so doing such math and achieving that precision is quite simple.

Oh I don't mean the speed of the processor required, just the times itself involved. 

 

8 minutes ago, igormp said:

Now communication and message passing through a bus with limited bandwidth and capacity is where it gets hard. I even started to work on a model that could try to allocate CAN messages in a fixed way meeting some constraints, but shit is hard, it's easier to just add a new bus when one gets saturated 

For the above I mean it's with this that is the problem and also in the variance in the clock timings that things operate which causes time drift.

 

8 minutes ago, igormp said:

The precision itself is kinda overestimated IMO, as shown above, but the whole coordination and communication required between all of the components is what amazes me.

Like above I mean the precision in lets say "true" time itself. Because time itself drifts in these systems. Like it's annoying enough for a regular computer if it comes with a system clock that drifts a lot, had a few servers do that and it's quite annoying even with NTP. One was bad enough we had to RMA it, it was drifting more than 0.05s that Ceph allows for in only a few hours.

[Dracarris]

8 minutes ago, igormp said:

Even the most dumb computer is pretty fast, even an arduino uno (which became really used as an example in this thread haha) runs at 16MHz, meaning it can do something every 62.5 NANOsecond, so i can adjust the spark advance and stay idle 99% of the time (I know it's exactly not like that, but should still be within the same order of magnitude). It really puts into perspective how powerful our desktops/phones are haha

You are way off. Even doing simple calculations takes 100s or 1000s of cycles. Even achieving 5us of precision with a 50MHz clock is very challenging, unless you literally run exactly one task/thread that is not interrupted by anything, which is basically impossible since it needs to handle at least one bus in order to know what to do. Achieving real-time, guaranteed execution on an MCU even at ms granularity is a very challenging task.

[leadeater]

16 minutes ago, Dracarris said:

Well that is achieved by fixed-function hardware that is connected as a peripheral within the MCU - called timers. They can generate waveforms down to 1/f granularity with f being their clock frequency. With a 1MHz timer clock you already achieve 1 us granularity. The CPU doesn't synchronously toggle GPIOs or such to trigger spark gaps etc. It asynchronously reprograms the timers, meaning there will be 1 or 2 revolutions where the engine runs with suboptimal timing but giving the CPU ample time to do complex calculations for optimal timing.

Thanks, really good explanation. Is there just a single timer for this and things are referenced off the waveform timing or are there multiple timers?