General > General Technical Chat
Resilience of semiconductor supply chains
<< < (6/7) > >>
hans:

--- Quote from: coppice on April 21, 2021, 11:27:39 am ---
--- Quote from: profdc9 on March 11, 2021, 04:14:28 am ---
--- Quote ---The 38 microcontrollers in an Audi Q7 come from eight companies, highlighting the complexity of auto supply chains, according to research firm IHS Markit.

--- End quote ---

--- End quote ---
I think that must be 38 models of MCU. In a car as complex as a Q7 there should be a lot more MCUs than that. Even low end cars generally have more than 38 MCUs.

--- End quote ---

I agree. Many sensors can be digital nowadays and each have their own little microcontroller. NXP even makes Cortex-m0 (IIRC) chips that have integrated CAN transceivers. You can hook them straight up to the bus. They are small 48 pin devices, not intended for large ECU's.

How many sensors are there on a modern petrol or diesel engine again? How many cilinders does it have? (each coil may have a uC) What if you need hybrid systems? (charger, motor drive, battery, coupling to transmission systems, + more for redundancy). Mikeselectricstuff did a teardown of a headlamp unit of a BMW. Each headlight unit has a microcontroller :scared: .

38 models then starts makes sense.. it quickly adds up.  I would not be surprised in a Mercedes S or Q7 class vehicle, the qty of uCs in the interior already exceeds 38.


--- Quote from: profdc9 on March 11, 2021, 05:47:17 pm ---Could there be a model like is used for software development with long-term support releases and incremental improvement releases that retain compatibility with the long term support releases? 

For example, would it be possible to have it so that a microcontroller was engineered and steadily improved, but would retain compatibility with earlier models for the lifetime of a microcontroller family?  More advanced microcontrollers would act like earlier models unless their special instructions or registers were invoked to unlock the new behavior.  This is of course done in software, for example, 16-bit real mode on 32-bit and 64-bit Intel processors, for example.

Why can't there be generic pinouts for power converters, where some of the pins would be configured, for example grounded, for the basic model, and as improvements are made, the configurations pins would be changed to enable the new functionality.  Leaving such options in hardware might be a lifesaver at some point because one could substitute a newer part for an older one.

If manufacturers are so eager to have their customers adopt newer silicon, maybe doing it this way would encourage that.

--- End quote ---

I think this is one of the major selling points of ARM eco-system; if you have coded your software algorithm to run a NXP Cortex-m4 chip, it will also work on a ST or Microchip Cortex-m4. You 'only' need to replace the board support package of your firmware, however, that is usually substantial effort, or not even possible if manufacturer A has an unique (patented) feature in their uC's. This is even less trivial for automotive or medical, which needs everything automotive certified, reviewed and commissioned..

In addition, the adoption of embedded systems is the race towards smaller designs, lower cost and often also time-to-market. A chip that has more features than necessary is excess luggage that will slow it down. Like @ataradov said; manufacturers are so occupied with low power consumption.

And then I think,  that manufacturers don't like making pin compatible products of their competitors. Namely that can work both ways: you may receive clients from your competitor, but if your company performs badly then chances are that you will directly lose clients. In other words: manufacturers like cash flow and protect it. Preferably you want to keep your clients in your self-designed product prison, often referred to as "the ecosystem". Once in, it must be very hard to break out, as that ensures that the cash flow stays with you. There is no 2nd supplier. There is no drop-in replacement from vendor A or C. Can anybody explain to me how that is an ecosystem? It's not like a bird only eat 1 type of seed. Then it really sounds more like a prison to me..

In similar terms, I really don't understand how manufacturers like Wurth or Samtec can make money. I think their 'ecosystem' are the niche industrial products and/or custom tailored products, which indeed have their place in the market. However, I have also received several consultants over the years and on each occasion they were asking about volume and if we used their connectors/passives. Well.. a 1k resistor stays 1k across all manufacturers. Same for an inductor, LED, pin header, etc. Half of those parts I don't even spec a MPN for. My assembler probably has their own stock.

Going back to the power consumption race of embedded systems: I've heard of a story in which a heart rate sensor for a popular brand smartwatch was redesigned. The digital processing was based on a 8-bit microcontroller design, however, the quiescent power consumption was far too high. They redesigned the firmware and ASIC implementation of said microarchitecture. They went as far as checking which instructions were not used by the firmware and removing those from the ASIC hardware. Those extra instructions may increase switching activity (=power consumption) with 0 extra functionality added. It can then make sense to strip half the ALU if you don't need those operations. In the story I've been told this was a PIC-based microcontroller. I'm not sure where this was produced, but if it was a licensed design then chances are it is also manufactured by Microchip or on the same technology fab/node. Since this was a very high volume product, that could easily add more supply chain pressure.
nctnico:

--- Quote from: hans on April 22, 2021, 01:18:17 pm ---I think this is one of the major selling points of ARM eco-system; if you have coded your software algorithm to run a NXP Cortex-m4 chip, it will also work on a ST or Microchip Cortex-m4.

--- End quote ---
No. Not by a long shot. Actually, it is complete and utter BS. Embedded software is written in C nowadays which is portable by design. The processor doesn't matter at all. However, switching from an NXP MCU to an ST MCU will be a major pain in the ass. Where NXP has compatible peripherals across the entire range, you'll likely need ST's HAL instead of your own (portable) hardware driver layer. Even if the peripherals are somewhat functionally compatible at all. In the end you'll need to rewrite huge chunks of code either to follow the way ST's HAL works (think about process scheduling!) OR write a huge amount of code to support the various peripherals from ST.
station240:

--- Quote from: Syntax Error on April 22, 2021, 12:03:02 pm ---Chipageddon strikes: "Jaguar Land Rover to suspend [UK] output due to chip shortage" https://www.bbc.co.uk/news/business-56841946

--- End quote ---

From above BBC news article

--- Quote ---On Wednesday, carmaker Stellantis, which owns the UK Vauxhall brand, said it would replace digital speedometers with more old-fashioned analogue ones in one of its Peugeot models, as the fallout continues.
--- End quote ---

:-DD Well that's one way to solve supply issues.
coppice:

--- Quote from: hans on April 22, 2021, 01:18:17 pm ---I think this is one of the major selling points of ARM eco-system; if you have coded your software algorithm to run a NXP Cortex-m4 chip, it will also work on a ST or Microchip Cortex-m4. You 'only' need to replace the board support package of your firmware, however, that is usually substantial effort, or not even possible if manufacturer A has an unique (patented) feature in their uC's. This is even less trivial for automotive or medical, which needs everything automotive certified, reviewed and commissioned..

--- End quote ---
I assume you've never worked with an MCU. The thing that makes someone choose a particular MCU is very very seldom the CPU. The CPU is irrelevant in most cases. People write most code in C now, so a change of CPU usually just requires a recompile. Its the peripherals which make one MCU interesting over another in any particular case. Very few MCUs are designed to be general purpose. They are mostly designed with one or two particular applications in mind. If you don't work in those applications you won't spot this. When you do work in those applications you will quickly spot that the MCU was made to keep you happy. Peripheral code, apart from the most basic, is not portable. You will do some extensive recoding if you change them.

The above is really not understood by far too many people in positions of influence, who make a big deal about how wonderfully portable ARM cores can make MCU applications.
Marco:

--- Quote from: floobydust on March 11, 2021, 06:07:45 am ---I know people in the automotive industry furious at NXP because they cannot fulfill orders for their 32bit MCU's - that were signed contracts well beyond a year in advance.

--- End quote ---
But what delivery delay are they experiencing? A couple month delivery delay is simply force majeure given disruptions due to severe weather and corona.

If those couple months of force majeure cripple them, that's on them ... shit can happen.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod