I'm not sure which group it was in, but someone who designs toys talked about the extremes they would go to for cost reduction, removing useful, but not essential resistors because they were $0.001 each.

I'm trying to find out if there are still 4 bit MCUs used in new products. I see a number of companies who make them, but I have no pricing. I have found 8 bit MCUs that are available for $0.05 each in just moderate quantities at LCSC. But then, maybe LCSC is not a vendor anyone should depend on.

Anyone here design with 4 bit MCUs? Anyone design things that are built in millions? Is there a difference in price that adds up at such high volumes?

How about power levels? 8 bit MCUs are pretty low power these days. Do 4 bit MCUs make a difference in your designs?

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

On 13/06/2022 03:44, Rick C wrote:
> I'm not sure which group it was in, but someone who designs toys
> talked about the extremes they would go to for cost reduction,
> removing useful, but not essential resistors because they were $0.001
> each.
>

I remember that poster (though not his name) - I believe you are in the
correct group. I have no idea if he is still lurking here.

> I'm trying to find out if there are still 4 bit MCUs used in new
> products. I see a number of companies who make them, but I have no
> pricing. I have found 8 bit MCUs that are available for $0.05 each
> in just moderate quantities at LCSC. But then, maybe LCSC is not a
> vendor anyone should depend on.
>
> Anyone here design with 4 bit MCUs? Anyone design things that are
> built in millions? Is there a difference in price that adds up at
> such high volumes?
>
> How about power levels? 8 bit MCUs are pretty low power these days.
> Do 4 bit MCUs make a difference in your designs?
>

As far as I know, there are no longer any 4-bit microcontrollers
available for "normal" customers. The last family was the MARC4, from
Atmel. There are still some manufacturers that make 4-bit
microcontrollers, but they are typically bare-die devices with vast
minimum order quantities and masked ROM programs - there are few
situations where they are economically viable now. If your company
directory does not play golf with the manufacturer's company director,
it's unlikely that you'll ever use these devices.

The cheapest microcontroller family I know of are from Padauk - they get
down to about $0.03 even in quite small quantities, with free toolchains
and available datasheets, appnotes, etc.. (Note that the references I
have seen are pre-Covid and before the current component availability
crisis, so things may have changed.)

<https://jaycarlson.net/2019/09/06/whats-up-with-these-3-cent-microcontrollers/>
<https://cpldcpu.wordpress.com/2019/08/12/the-terrible-3-cent-mcu/>

If you don't need to be quite so obsessive about the price, for $0.50
you should even be able to get 32-bit devices. The choice of
peripherals and configuration is probably more important than the core -
if you can pick a device with the right pin drives, internal pull-ups or
pull-downs, that will save the cost of the device.

The cheapest device I have used personally was an 8-bit AVR Tiny - 2 KB
flash, no ram, 8 bytes eeprom (IIRC). I don't remember the price, but I
believe it was cheaper than the LED on the board. If the tiny coin cell
battery on the board had no self-discharge, the system would have had a
standby lifetime of about 200 years - pretty low power!

On 13/6/22 17:52, David Brown wrote:
> On 13/06/2022 03:44, Rick C wrote:
>> I'm not sure which group it was in, but someone who designs toys
>> talked about the extremes they would go to for cost reduction,
>> removing useful, but not essential resistors because they were $0.001
>> each.
>>
>
> I remember that poster (though not his name) - I believe you are in the
> correct group.  I have no idea if he is still lurking here.

Me too. I think the company was Mattel. You might get search hits if you
include that.

I doubt there is any reason to use such devices these days, even in
markets like that.

CH

>> I'm trying to find out if there are still 4 bit MCUs used in new
>> products.  I see a number of companies who make them, but I have no
>> pricing.  I have found 8 bit MCUs that are available for $0.05 each
>> in just moderate quantities at LCSC.  But then, maybe LCSC is not a
>> vendor anyone should depend on.
>>
>> Anyone here design with 4 bit MCUs?  Anyone design things that are
>> built in millions?  Is there a difference in price that adds up at
>> such high volumes?
>>
>> How about power levels?  8 bit MCUs are pretty low power these days.
>> Do 4 bit MCUs make a difference in your designs?
>>
>
> As far as I know, there are no longer any 4-bit microcontrollers
> available for "normal" customers.  The last family was the MARC4, from
> Atmel.  There are still some manufacturers that make 4-bit
> microcontrollers, but they are typically bare-die devices with vast
> minimum order quantities and masked ROM programs - there are few
> situations where they are economically viable now.  If your company
> directory does not play golf with the manufacturer's company director,
> it's unlikely that you'll ever use these devices.
>
> The cheapest microcontroller family I know of are from Padauk - they get
> down to about $0.03 even in quite small quantities, with free toolchains
> and available datasheets, appnotes, etc..  (Note that the references I
> have seen are pre-Covid and before the current component availability
> crisis, so things may have changed.)
>
> <https://jaycarlson.net/2019/09/06/whats-up-with-these-3-cent-microcontrollers/>
>
> <https://cpldcpu.wordpress.com/2019/08/12/the-terrible-3-cent-mcu/>
>
> If you don't need to be quite so obsessive about the price, for $0.50
> you should even be able to get 32-bit devices.  The choice of
> peripherals and configuration is probably more important than the core -
> if you can pick a device with the right pin drives, internal pull-ups or
> pull-downs, that will save the cost of the device.
>
> The cheapest device I have used personally was an 8-bit AVR Tiny - 2 KB
> flash, no ram, 8 bytes eeprom (IIRC).  I don't remember the price, but I
> believe it was cheaper than the LED on the board.  If the tiny coin cell
> battery on the board had no self-discharge, the system would have had a
> standby lifetime of about 200 years - pretty low power!
>
>

On 2022-06-13 Rick C wrote in comp.arch.embedded:
> I'm not sure which group it was in, but someone who designs toys talked about the extremes they would go to for cost reduction, removing useful, but not essential resistors because they were $0.001 each.
>
> I'm trying to find out if there are still 4 bit MCUs used in new products. I see a number of companies who make them, but I have no pricing. I have found 8 bit MCUs that are available for $0.05 each in just moderate quantities at LCSC. But then, maybe LCSC is not a vendor anyone should depend on.
>
> Anyone here design with 4 bit MCUs? Anyone design things that are built in millions? Is there a difference in price that adds up at such high volumes?
>
> How about power levels? 8 bit MCUs are pretty low power these days. Do 4 bit MCUs make a difference in your designs?
>

EM Microelectronic still makes them, but custom and mask rom stuff only
https://www.emmicroelectronic.com/product/microcontroller-tools-support/ems6500

Not sure this is actually low-cost. They claim ultra low power. For
instance this one:
https://www.emmicroelectronic.com/index.php/product/multi-io/em6607

--
Stef

Never make anything simple and efficient when a way can be found to
make it complex and wonderful.

Am 13.06.22 um 09:52 schrieb David Brown:

>
> The cheapest microcontroller family I know of are from Padauk - they get
> down to about $0.03 even in quite small quantities, with free toolchains
> and available datasheets, appnotes, etc..  (Note that the references I
> have seen are pre-Covid and before the current component availability
> crisis, so things may have changed.)
>

Before Corona, their cheapest, the PMS15A, was below 1 cent even in
small quantitites. That was a device with PROM, though. AFAIR, devices
with Flash started at 5 cent when bought in small quantitites. From
their financial reports one could see that the average (i.e. across
their whole range and all sales) price of their µC was also below 1 cent.
There is the free toolchain based on easypdkprog and SDCC, a full free C
compiler. And there is the vendor supplied non-free but gratis MINI-C,
which, despite the name, is just an IDE with an assembler with a little
bit of C syntax sprinkled on top.

>
> If you don't need to be quite so obsessive about the price, for $0.50
> you should even be able to get 32-bit devices.  The choice of
> peripherals and configuration is probably more important than the core -
> if you can pick a device with the right pin drives, internal pull-ups or
> pull-downs, that will save the cost of the device.

The Padauk approach is that you don't really need most peripherals. Just
emulate them in software. If you need accurate timing, put the emulation
on its own "core". Padauk has µC with hardware multithreading
(implemented as a barrel processor). However, there are severe
limitations that make it hard or unfeasible to have more than one "core"
running C code (and I never implemented support for that in the free
toolchain): https://arxiv.org/abs/2010.04633

Am 13.06.22 um 03:44 schrieb Rick C:

> I'm trying to find out if there are still 4 bit MCUs used in new products.

A few weeks ago, I bought some cyclocomputers. I was surprised to find
that even current products are typically based on 4-bit µC. AFAIR, every
commercial caclocomputer, on which I found the information had a 4-bit µC.

On Monday, June 13, 2022 at 8:47:32 AM UTC-4, Stef wrote:
> On 2022-06-13 Rick C wrote in comp.arch.embedded:
> > I'm not sure which group it was in, but someone who designs toys talked about the extremes they would go to for cost reduction, removing useful, but not essential resistors because they were $0.001 each.
> >
> > I'm trying to find out if there are still 4 bit MCUs used in new products. I see a number of companies who make them, but I have no pricing. I have found 8 bit MCUs that are available for $0.05 each in just moderate quantities at LCSC. But then, maybe LCSC is not a vendor anyone should depend on..
> >
> > Anyone here design with 4 bit MCUs? Anyone design things that are built in millions? Is there a difference in price that adds up at such high volumes?
> >
> > How about power levels? 8 bit MCUs are pretty low power these days. Do 4 bit MCUs make a difference in your designs?
> >
> EM Microelectronic still makes them, but custom and mask rom stuff only
> https://www.emmicroelectronic.com/product/microcontroller-tools-support/ems6500
>
> Not sure this is actually low-cost. They claim ultra low power. For
> instance this one:
> https://www.emmicroelectronic.com/index.php/product/multi-io/em6607

Some have pointed out that 8 bit MCUs are pretty durn low power. I guess the question is if there is enough distinction between 4 and 8 bit MCUs to justify the issues of working with the 4 bit parts. At $0.01 per device, even a million units are only $10,000. That's not a lot of engineering time.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

On Tuesday, June 14, 2022 at 1:51:28 AM UTC-4, Philipp Klaus Krause wrote:
> Am 13.06.22 um 03:44 schrieb Rick C:
> > I'm trying to find out if there are still 4 bit MCUs used in new products.
> A few weeks ago, I bought some cyclocomputers. I was surprised to find
> that even current products are typically based on 4-bit µC. AFAIR, every
> commercial caclocomputer, on which I found the information had a 4-bit µC.

I wonder if this is an example of having the basic design working and sticking with the same device so they don't have to port it? Still, if they are introducing new products using the old MCU design, that's still a new product.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

Rick C <gnuarm.deletethisbit@gmail.com> wrote:
> I'm not sure which group it was in, but someone who designs toys talked about the extremes they would go to for cost reduction, removing useful, but not essential resistors because they were $0.001 each.
>
> I'm trying to find out if there are still 4 bit MCUs used in new products. I see a number of companies who make them, but I have no pricing. I have found 8 bit MCUs that are available for $0.05 each in just moderate quantities at LCSC. But then, maybe LCSC is not a vendor anyone should depend on.
>
> Anyone here design with 4 bit MCUs? Anyone design things that are built
> in millions? Is there a difference in price that adds up at such high
> volumes?

I wonder what process node these MCUs are fabbed on. My understanding is
that a design has a certain number of mm2 as overhead for the pads and I/O
buffers, and that doesn't scale much with process. If your bond wires or
solder bumps are all 100um square and you need X of them, that's a fairly
high fixed cost. Meanwhile the cost of laying down a processor is fairly
negligible in comparison, so you might as well go for at least 8 bits.

About 15 years ago I worked on a project which was building processors on
TFT display technology - the same used for the drive electronics for LCD
panels. There the feature size was O(10um), which is the same as the Intel
4004, and you could physically see the transistors if you held the panel up
to the light. That's the kind of environment where every transistor counts.
Another example is organic electronics, eg inkjet printed transistors.

But apart from those niches, I can't see what a 4 bit CPU buys you over an 8
bit CPU, given you aren't at such huge process nodes.

Theo

On 2022-06-14 Rick C wrote in comp.arch.embedded:
> On Monday, June 13, 2022 at 8:47:32 AM UTC-4, Stef wrote:
>> On 2022-06-13 Rick C wrote in comp.arch.embedded:
>> > I'm not sure which group it was in, but someone who designs toys talked about the extremes they would go to for cost reduction, removing useful, but not essential resistors because they were $0.001 each.
>> >
>> > I'm trying to find out if there are still 4 bit MCUs used in new products. I see a number of companies who make them, but I have no pricing. I have found 8 bit MCUs that are available for $0.05 each in just moderate quantities at LCSC. But then, maybe LCSC is not a vendor anyone should depend on.
>> >
>> > Anyone here design with 4 bit MCUs? Anyone design things that are built in millions? Is there a difference in price that adds up at such high volumes?
>> >
>> > How about power levels? 8 bit MCUs are pretty low power these days. Do 4 bit MCUs make a difference in your designs?
>> >
>> EM Microelectronic still makes them, but custom and mask rom stuff only
>> https://www.emmicroelectronic.com/product/microcontroller-tools-support/ems6500
>>
>> Not sure this is actually low-cost. They claim ultra low power. For
>> instance this one:
>> https://www.emmicroelectronic.com/index.php/product/multi-io/em6607
>
> Some have pointed out that 8 bit MCUs are pretty durn low power. I guess the question is if there is enough distinction between 4 and 8 bit MCUs to justify the issues of working with the 4 bit parts. At $0.01 per device, even a million units are only $10,000. That's not a lot of engineering time.

The fact that EM (and others) still offer 4-bit and have tools available
for them suggests to me that there still is a market for them.

I know we did have a look at (then) EM Microelectronic-Marin 4-bit
processors in the past, but our volumes (and needs) where nowhere near
what was feasable for them, so we stuck to 8051. But that was well over
20 years ago. Oops, just spotted the databook on my bookshelf, it's from
1996. ;-)

Nowadays we use 32-bit (arm) for almost everything. The current
availability issues have made us look into other directions, but that is
all too much trouble. Just hoping things will get better in the not too
distant future.

--
Stef

Friends, n.:
People who borrow your books and set wet glasses on them.

People who know you well, but like you anyway.

On 14/06/2022 23:29, Stef wrote:

> Nowadays we use 32-bit (arm) for almost everything. The current
> availability issues have made us look into other directions, but that is
> all too much trouble. Just hoping things will get better in the not too
> distant future.
>

These days the choice of microcontroller is often determined by what you
can get hold of, not by price, functionality, familiarity or any other
traditional criteria. It is frustrating, to say the least.

Small ARM cores cost the manufacturer a few cents and can have extremely
low power - unless you have strong backwards compatibility reasons or
very specific requirements, it is rare for the "best" choice to be
anything other than an ARM for most boards.

But RISC-V is increasing, and I really hope some big names start using
it in their microcontrollers. It offers more scope than ARM for
differentiation amongst products while keeping a common basis, and it's
not healthy for the market to be so dominated by a single core. (Look
at the PC market - it's all just highly polished turds.)

On 2022-06-15 David Brown wrote in comp.arch.embedded:
> On 14/06/2022 23:29, Stef wrote:
>
>> Nowadays we use 32-bit (arm) for almost everything. The current
>> availability issues have made us look into other directions, but that is
>> all too much trouble. Just hoping things will get better in the not too
>> distant future.
>
> These days the choice of microcontroller is often determined by what you
> can get hold of, not by price, functionality, familiarity or any other
> traditional criteria.

For us familiarity is still a big factor (available software libs etc.),
but it is getting harder. So pick one that is in stock, buy a years (or
more) supply, then design a board. :-(

And that is the easy path for new products. You don't have this 'luxury'
for existing products.

> It is frustrating, to say the least.

Indeed.

--
Stef

The odds are a million to one against your being one in a million.

Il 15/06/2022 08:55, David Brown ha scritto:
> On 14/06/2022 23:29, Stef wrote:
>
>> Nowadays we use 32-bit (arm) for almost everything. The current
>> availability issues have made us look into other directions, but that is
>> all too much trouble. Just hoping things will get better in the not too
>> distant future.
>>
>
> These days the choice of microcontroller is often determined by what you
> can get hold of, not by price, functionality, familiarity or any other
> traditional criteria.  It is frustrating, to say the least.

Yes, it's frustrating. Here we are spending most of the time to redesign
some boards because of MCU shortage.

Two times we ordered the MCU with a long delivery time (around 10
months), purchased another MCU that was available in quantity for
production and started to redesign PCB and software for the new MCU.

We were sure to have the new fully-functional board much before the
delivery of the old MCU, but this wasn't the case.

Patching the firmware for the new MCU, rewriting drivers, fighting with
new errata, different SDK of the manufacturers and so on was a difficult
task. Eventually, we arrived to have the new board a couple of weeks
before the delivery of the old MCU, so decided to start the production
of old boards.

Two times we lost money purchasing new MCUs that we didn't use, and lost
a lot of time working on the new MCU, stopping the reasearch and
development of new things and products.

Do you have similar experience?

> Small ARM cores cost the manufacturer a few cents and can have extremely
> low power - unless you have strong backwards compatibility reasons or
> very specific requirements, it is rare for the "best" choice to be
> anything other than an ARM for most boards.
>
> But RISC-V is increasing, and I really hope some big names start using
> it in their microcontrollers.  It offers more scope than ARM for
> differentiation amongst products while keeping a common basis, and it's
> not healthy for the market to be so dominated by a single core.  (Look
> at the PC market - it's all just highly polished turds.)

On 15/06/2022 10:38, pozz wrote:
> Il 15/06/2022 08:55, David Brown ha scritto:
>> On 14/06/2022 23:29, Stef wrote:
>>
>>> Nowadays we use 32-bit (arm) for almost everything. The current
>>> availability issues have made us look into other directions, but that is
>>> all too much trouble. Just hoping things will get better in the not too
>>> distant future.
>>>
>>
>> These days the choice of microcontroller is often determined by what
>> you can get hold of, not by price, functionality, familiarity or any
>> other traditional criteria.  It is frustrating, to say the least.
>
> Yes, it's frustrating. Here we are spending most of the time to redesign
> some boards because of MCU shortage.
>
> Two times we ordered the MCU with a long delivery time (around 10
> months), purchased another MCU that was available in quantity for
> production and started to redesign PCB and software for the new MCU.
>
> We were sure to have the new fully-functional board much before the
> delivery of the old MCU, but this wasn't the case.
>
> Patching the firmware for the new MCU, rewriting drivers, fighting with
> new errata, different SDK of the manufacturers and so on was a difficult
> task. Eventually, we arrived to have the new board a couple of weeks
> before the delivery of the old MCU, so decided to start the production
> of old boards.
>
> Two times we lost money purchasing new MCUs that we didn't use, and lost
> a lot of time working on the new MCU, stopping the reasearch and
> development of new things and products.
>
> Do you have similar experience?
>

In a word, yes - many similarities.

On Wednesday, June 15, 2022 at 4:38:09 AM UTC-4, pozz wrote:
> Il 15/06/2022 08:55, David Brown ha scritto:
> > On 14/06/2022 23:29, Stef wrote:
> >
> >> Nowadays we use 32-bit (arm) for almost everything. The current
> >> availability issues have made us look into other directions, but that is
> >> all too much trouble. Just hoping things will get better in the not too
> >> distant future.
> >>
> >
> > These days the choice of microcontroller is often determined by what you
> > can get hold of, not by price, functionality, familiarity or any other
> > traditional criteria. It is frustrating, to say the least.
> Yes, it's frustrating. Here we are spending most of the time to redesign
> some boards because of MCU shortage.
>
> Two times we ordered the MCU with a long delivery time (around 10
> months), purchased another MCU that was available in quantity for
> production and started to redesign PCB and software for the new MCU.
>
> We were sure to have the new fully-functional board much before the
> delivery of the old MCU, but this wasn't the case.
>
> Patching the firmware for the new MCU, rewriting drivers, fighting with
> new errata, different SDK of the manufacturers and so on was a difficult
> task. Eventually, we arrived to have the new board a couple of weeks
> before the delivery of the old MCU, so decided to start the production
> of old boards.
>
> Two times we lost money purchasing new MCUs that we didn't use, and lost
> a lot of time working on the new MCU, stopping the reasearch and
> development of new things and products.
>
> Do you have similar experience?

What processors were you switching between that you had so much trouble with the conversion? Typically drivers are provided for peripherals. What sort of "patches" were needed? Why would the SDK be different? Were the two processors not even of the same family? Just kibitzing from the peanut gallery, but it seems like those issues could have been minimized by prudent selection of the new MCU.

--

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209

Rick C <gnuarm.deletethisbit@gmail.com> wrote:
> What processors were you switching between that you had so much trouble with the conversion? Typically drivers are provided for peripherals. What sort of "patches" were needed? Why would the SDK be different? Were the two processors not even of the same family? Just kibitzing from the peanut gallery, but it seems like those issues could have been minimized by prudent selection of the new MCU.
>

In times of allocation and part shortage, a "prudent" selection is not easy!
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------

Il 15/06/2022 16:12, Uwe Bonnes ha scritto:
> Rick C <gnuarm.deletethisbit@gmail.com> wrote:
>
>> What processors were you switching between that you had so much trouble with the conversion? Typically drivers are provided for peripherals. What sort of "patches" were needed? Why would the SDK be different? Were the two processors not even of the same family? Just kibitzing from the peanut gallery, but it seems like those issues could have been minimized by prudent selection of the new MCU.
>>
>
> In times of allocation and part shortage, a "prudent" selection is not easy!

Exactly.

Il 15/06/2022 15:53, Rick C ha scritto:
> On Wednesday, June 15, 2022 at 4:38:09 AM UTC-4, pozz wrote:
>> Il 15/06/2022 08:55, David Brown ha scritto:
>>> On 14/06/2022 23:29, Stef wrote:
>>>
>>>> Nowadays we use 32-bit (arm) for almost everything. The current
>>>> availability issues have made us look into other directions, but that is
>>>> all too much trouble. Just hoping things will get better in the not too
>>>> distant future.
>>>>
>>>
>>> These days the choice of microcontroller is often determined by what you
>>> can get hold of, not by price, functionality, familiarity or any other
>>> traditional criteria. It is frustrating, to say the least.
>> Yes, it's frustrating. Here we are spending most of the time to redesign
>> some boards because of MCU shortage.
>>
>> Two times we ordered the MCU with a long delivery time (around 10
>> months), purchased another MCU that was available in quantity for
>> production and started to redesign PCB and software for the new MCU.
>>
>> We were sure to have the new fully-functional board much before the
>> delivery of the old MCU, but this wasn't the case.
>>
>> Patching the firmware for the new MCU, rewriting drivers, fighting with
>> new errata, different SDK of the manufacturers and so on was a difficult
>> task. Eventually, we arrived to have the new board a couple of weeks
>> before the delivery of the old MCU, so decided to start the production
>> of old boards.
>>
>> Two times we lost money purchasing new MCUs that we didn't use, and lost
>> a lot of time working on the new MCU, stopping the reasearch and
>> development of new things and products.
>>
>> Do you have similar experience?
>
> What processors were you switching between that you had so much trouble with the conversion? Typically drivers are provided for peripherals. What sort of "patches" were needed? Why would the SDK be different? Were the two processors not even of the same family? Just kibitzing from the peanut gallery, but it seems like those issues could have been minimized by prudent selection of the new MCU.
>

I have a board with LPC1788. It's not that simple (at least for me):
external SDRAM, external SPI Flash, TFT LCD display with touch panel,
SDcard, USB and so on.

After receiving new offer from distributor with a leading time of 10
months, I looked around and found 200 pcs of LPC54618. I immediately
purchased them and started reworking the firmware and the PCB.

It wasn't so simple as we expected. Eventually LPC1788 arrived two weeks
later the reworking for lpc54618 finished.

On 15/06/2022 16:12, Uwe Bonnes wrote:
> Rick C <gnuarm.deletethisbit@gmail.com> wrote:
>
>> What processors were you switching between that you had so much
>> trouble with the conversion? Typically drivers are provided for
>> peripherals. What sort of "patches" were needed? Why would the
>> SDK be different? Were the two processors not even of the same
>> family? Just kibitzing from the peanut gallery, but it seems like
>> those issues could have been minimized by prudent selection of the
>> new MCU.
>>
>
> In times of allocation and part shortage, a "prudent" selection is
> not easy!

That has been my experience. I have one card for a customer that went
through the whole process twice - once to a similar microcontroller (a
"cousin" of the original one) that needed only relatively small changes
to the software, and once to a different microcontroller from a
different manufacturer, requiring lots more changes. All sorts of
things had to be changed to make things work.

SDK's can help a bit, if you are not fussy about the efficiency of the
results. (Some SDK's are very poor quality and inefficient code with
useless documentation and little thought to how they can be used in
practice. Most, however, are worse.)

But you still have a lot of work if the original was written for an old
SDK which does not support the new family member - thus forcing many
re-writes. And of course when you change manufacturer, you have a
completely different SDK and API.

It is all a huge waste of time, effort and money to result in a board
and software that is no better than the original - merely because you
could buy a few thousand pieces instead of dealing with year-long lead
times for parts you actually want.

On Wednesday, June 15, 2022 at 10:12:24 AM UTC-4, Uwe Bonnes wrote:
> Rick C <gnuarm.del...@gmail.com> wrote:
>
> > What processors were you switching between that you had so much trouble with the conversion? Typically drivers are provided for peripherals. What sort of "patches" were needed? Why would the SDK be different? Were the two processors not even of the same family? Just kibitzing from the peanut gallery, but it seems like those issues could have been minimized by prudent selection of the new MCU.
> >
> In times of allocation and part shortage, a "prudent" selection is not easy!

That's a separate issue. I've always taken great pains to provide for alternate parts. I have a board that has been in production for 14 years and I've taken advantage of every option I built in for part alternatives. I've even discovered a few I hadn't planned on. It is reaching the end of life as one part has not been made for perhaps eight years and the Arrow inventory is dwindling finally. Another part was made in a Japanese factory that burned down almost two years ago. The company has decided to not respin that part in a different fab, rather to consolidate several parts into one which is not pin compatible with my part. So, I'm building the last 10,000 units. :(

Production should be an easy task after the first thousand. If I get to respin this board, I'm going to address all the manufacturing issues, since they are actually more important than the technical issues. There's no point in designing a great board that is hard to make. Unfortunately, FPGAs are not second sourced. :(

--

Rick C.

+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209

Am 15.06.2022 um 16:12 schrieb Uwe Bonnes:

> In times of allocation and part shortage, a "prudent" selection is not easy!

Amen. Or, as the saying goes:

"All prognoses are hard, even more so those concerning the future."

(Made famous by Niels Bohr, but may have been a widely known in his home
country of Denmark before that).

Let's face it: unless you're a major customer (and no, an order volume
of a million units does not reliably make you one), any and all
expectations about parts availability in the micro controller market
that reach further than a few months into the future are recklessly
optimistic. And that was how it was _before_ the pandemic and all its
side effects.

If you need to be sure you have those chips in quantity x over the run
of a given product, and x has fewer than 7 digits, your only truly safe
bet is to stockpile the whole lot up front. The next-safest plan would
be to stockpile enough of them to tide you over the conservatively
estimated time for a redesign of the board and most of the lower-level
software. Obviously neither of those options is cheap; but the main
alternative is that you may one day have to discontinue your whole
product because that one part suddenly turned into unobtainium.

On Wednesday, June 15, 2022 at 7:35:56 PM UTC-4, Hans-Bernhard Bröker wrote:
> Am 15.06.2022 um 16:12 schrieb Uwe Bonnes:
>
> > In times of allocation and part shortage, a "prudent" selection is not easy!
> Amen. Or, as the saying goes:
>
> "All prognoses are hard, even more so those concerning the future."
>
> (Made famous by Niels Bohr, but may have been a widely known in his home
> country of Denmark before that).
>
> Let's face it: unless you're a major customer (and no, an order volume
> of a million units does not reliably make you one), any and all
> expectations about parts availability in the micro controller market
> that reach further than a few months into the future are recklessly
> optimistic. And that was how it was _before_ the pandemic and all its
> side effects.
>
> If you need to be sure you have those chips in quantity x over the run
> of a given product, and x has fewer than 7 digits, your only truly safe
> bet is to stockpile the whole lot up front. The next-safest plan would
> be to stockpile enough of them to tide you over the conservatively
> estimated time for a redesign of the board and most of the lower-level
> software. Obviously neither of those options is cheap; but the main
> alternative is that you may one day have to discontinue your whole
> product because that one part suddenly turned into unobtainium.

So how do you stockpile inventory for a product when you don't know the ultimate sales volume? I designed a board for a company 14 years ago. I originally sold maybe 100 a year average (100 piece minimum). Volumes grew until I was getting orders for several thousand in one year and none in the next. Now I have an order for 10,000 pieces. The company I sell these to has always refused to commit to any quantity. It's not always feasible to plan for future production, so this idea is clearly not a panacea.

--

Rick C.

++ Get 1,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209

On 16/06/2022 08:46, Rick C wrote:
> On Wednesday, June 15, 2022 at 7:35:56 PM UTC-4, Hans-Bernhard Bröker
> wrote:
>> Am 15.06.2022 um 16:12 schrieb Uwe Bonnes:
>>
>>> In times of allocation and part shortage, a "prudent" selection
>>> is not easy!
>> Amen. Or, as the saying goes:
>>
>> "All prognoses are hard, even more so those concerning the
>> future."
>>
>> (Made famous by Niels Bohr, but may have been a widely known in his
>> home country of Denmark before that).
>>
>> Let's face it: unless you're a major customer (and no, an order
>> volume of a million units does not reliably make you one), any and
>> all expectations about parts availability in the micro controller
>> market that reach further than a few months into the future are
>> recklessly optimistic. And that was how it was _before_ the
>> pandemic and all its side effects.
>>

Major customers are in exactly the same boat. Car manufacturers have
had to pause production, or switch to different models and delay
deliveries, because they can't get the parts. HP can't get parts for
its printers, D-Link can't get components for their switches. Even the
companies that make the electronics for the machines that make
components can't get the parts they need to get new semiconductor plants
online.

>> If you need to be sure you have those chips in quantity x over the
>> run of a given product, and x has fewer than 7 digits, your only
>> truly safe bet is to stockpile the whole lot up front. The
>> next-safest plan would be to stockpile enough of them to tide you
>> over the conservatively estimated time for a redesign of the board
>> and most of the lower-level software. Obviously neither of those
>> options is cheap; but the main alternative is that you may one day
>> have to discontinue your whole product because that one part
>> suddenly turned into unobtainium.
>
> So how do you stockpile inventory for a product when you don't know
> the ultimate sales volume? I designed a board for a company 14 years
> ago. I originally sold maybe 100 a year average (100 piece minimum).
> Volumes grew until I was getting orders for several thousand in one
> year and none in the next. Now I have an order for 10,000 pieces.
> The company I sell these to has always refused to commit to any
> quantity. It's not always feasible to plan for future production, so
> this idea is clearly not a panacea.
>

You do the best you can, adapting as you go. If you can stockpile - you
can get the parts, and you have the cash flow - do so. If not, there's
a lot of luck involved no matter how skilled and hard-working you are.
If you can spread your risks, making a variety of different devices,
that's a good way to lower the overall risk.

Otherwise you make what you can, when you can, and hope your customers
are still around when you are finally able to deliver the boards. At
least there is little risk of them going to your competition in the
meantime, as everyone has the same challenges getting the parts.

On 2022-06-16 Rick C wrote in comp.arch.embedded:
> On Wednesday, June 15, 2022 at 7:35:56 PM UTC-4, Hans-Bernhard Bröker wrote:
>>
>> If you need to be sure you have those chips in quantity x over the run
>> of a given product, and x has fewer than 7 digits, your only truly safe
>> bet is to stockpile the whole lot up front. The next-safest plan would
>> be to stockpile enough of them to tide you over the conservatively
>> estimated time for a redesign of the board and most of the lower-level
>> software. Obviously neither of those options is cheap; but the main
>> alternative is that you may one day have to discontinue your whole
>> product because that one part suddenly turned into unobtainium.
>
> So how do you stockpile inventory for a product when you don't know the ultimate sales volume? I designed a board for a company 14 years ago. I originally sold maybe 100 a year average (100 piece minimum). Volumes grew until I was getting orders for several thousand in one year and none in the next. Now I have an order for 10,000 pieces. The company I sell these to has always refused to commit to any quantity. It's not always feasible to plan for future production, so this idea is clearly not a panacea.

You cannot plan for everything unfortunately. :-(

But talk to your customers. Explain that they need to commit to a
quantity so you can buy parts upfront. And that if they don't, there is
a risk that there will be no parts when needed. At least, that is what
we do. Most customers will be aware of the situation and willing to give
guaranties (and pay for the parts) to make sure they can get their
product in the future. And if not, they have been warned of the risks.

But still, you cannot stockpile everything. So 100% guarantees are not
possible, but they never where.

--
Stef

Never keep up with the Joneses. Drag them down to your level.
-- Quentin Crisp

On 2022-06-16, David Brown <david.brown@hesbynett.no> wrote:

> Major customers are in exactly the same boat. Car manufacturers have
> had to pause production, or switch to different models and delay
> deliveries, because they can't get the parts. HP can't get parts for
> its printers, D-Link can't get components for their switches. Even the
> companies that make the electronics for the machines that make
> components can't get the parts they need to get new semiconductor plants
> online.

It seems that last category do have better luck than "the rest of
us". My employer makes a black box that's designed into some
semiconductor tool or other. We haven't been able to build said boxes
for some time because we can't get FPGAs and Ethernet switch chips.

Our customer (who makes semiconductor tools) asked which parts we
neeed to build more black boxes. A week later they informed us that
5000 of the FPGAs had been shipped to us, and they were about to have
a chat with the manufacturer of the Ethernet switch chips. [I haven't
heard the results of that chat.]

--
Grant