Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #31047 > unrolled thread

4 Bit MCUs, Still Alive and Kicking?

Back to article view | Back to comp.arch.embedded

Contents

  4 Bit MCUs, Still Alive and Kicking? Rick C <gnuarm.deletethisbit@gmail.com> - 2022-06-12 18:44 -0700
    Re: 4 Bit MCUs, Still Alive and Kicking? David Brown <david.brown@hesbynett.no> - 2022-06-13 09:52 +0200
      Re: 4 Bit MCUs, Still Alive and Kicking? Clifford Heath <no.spam@please.net> - 2022-06-13 22:11 +1000
      Re: 4 Bit MCUs, Still Alive and Kicking? Philipp Klaus Krause <pkk@spth.de> - 2022-06-14 07:46 +0200
    Re: 4 Bit MCUs, Still Alive and Kicking? Stef <me@this.is.invalid> - 2022-06-13 14:47 +0200
      Re: 4 Bit MCUs, Still Alive and Kicking? Rick C <gnuarm.deletethisbit@gmail.com> - 2022-06-14 08:34 -0700
        Re: 4 Bit MCUs, Still Alive and Kicking? Stef <me@this.is.invalid> - 2022-06-14 23:29 +0200
          Re: 4 Bit MCUs, Still Alive and Kicking? David Brown <david.brown@hesbynett.no> - 2022-06-15 08:55 +0200
            Re: 4 Bit MCUs, Still Alive and Kicking? Stef <me@this.is.invalid> - 2022-06-15 09:25 +0200
            Re: 4 Bit MCUs, Still Alive and Kicking? pozz <pozzugno@gmail.com> - 2022-06-15 10:38 +0200
              Re: 4 Bit MCUs, Still Alive and Kicking? David Brown <david.brown@hesbynett.no> - 2022-06-15 15:20 +0200
              Re: 4 Bit MCUs, Still Alive and Kicking? Rick C <gnuarm.deletethisbit@gmail.com> - 2022-06-15 06:53 -0700
                Re: 4 Bit MCUs, Still Alive and Kicking? Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> - 2022-06-15 14:12 +0000
                  Re: 4 Bit MCUs, Still Alive and Kicking? pozz <pozzugno@gmail.com> - 2022-06-15 17:11 +0200
                  Re: 4 Bit MCUs, Still Alive and Kicking? David Brown <david.brown@hesbynett.no> - 2022-06-15 17:20 +0200
                  Re: 4 Bit MCUs, Still Alive and Kicking? Rick C <gnuarm.deletethisbit@gmail.com> - 2022-06-15 09:12 -0700
                  Re: 4 Bit MCUs, Still Alive and Kicking? Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2022-06-16 01:35 +0200
                    Re: 4 Bit MCUs, Still Alive and Kicking? Rick C <gnuarm.deletethisbit@gmail.com> - 2022-06-15 23:46 -0700
                      Re: 4 Bit MCUs, Still Alive and Kicking? David Brown <david.brown@hesbynett.no> - 2022-06-16 09:08 +0200
                        Re: 4 Bit MCUs, Still Alive and Kicking? Grant Edwards <invalid@invalid.invalid> - 2022-06-16 13:47 +0000
                          Re: 4 Bit MCUs, Still Alive and Kicking? David Brown <david.brown@hesbynett.no> - 2022-06-17 09:15 +0200
                      Re: 4 Bit MCUs, Still Alive and Kicking? Stef <me@this.is.invalid> - 2022-06-16 09:34 +0200
                        Re: 4 Bit MCUs, Still Alive and Kicking? Rick C <gnuarm.deletethisbit@gmail.com> - 2022-06-16 08:03 -0700
                      Re: 4 Bit MCUs, Still Alive and Kicking? chris <chris-nospam@tridac.net> - 2022-06-17 01:05 +0100
                Re: 4 Bit MCUs, Still Alive and Kicking? pozz <pozzugno@gmail.com> - 2022-06-15 17:16 +0200
    Re: 4 Bit MCUs, Still Alive and Kicking? Philipp Klaus Krause <pkk@spth.de> - 2022-06-14 07:51 +0200
      Re: 4 Bit MCUs, Still Alive and Kicking? Rick C <gnuarm.deletethisbit@gmail.com> - 2022-06-14 08:48 -0700
    Re: 4 Bit MCUs, Still Alive and Kicking? Theo <theom+news@chiark.greenend.org.uk> - 2022-06-14 21:48 +0100
      Re: 4 Bit MCUs, Still Alive and Kicking? Herbert Kleebauer <klee@unibwm.de> - 2022-06-17 13:36 +0200

Page 1 of 2  [1] 2  Next page →

#31047 — 4 Bit MCUs, Still Alive and Kicking?

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

[toc] | [next] | [standalone]

#31048

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!

[toc] | [prev] | [next] | [standalone]

#31049

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!
> 
> 

[toc] | [prev] | [next] | [standalone]

#31051

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

[toc] | [prev] | [next] | [standalone]

#31050

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.

[toc] | [prev] | [next] | [standalone]

#31055

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

[toc] | [prev] | [next] | [standalone]

#31064

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.

[toc] | [prev] | [next] | [standalone]

#31067

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.)

[toc] | [prev] | [next] | [standalone]

#31069

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.

[toc] | [prev] | [next] | [standalone]

#31070

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.)

[toc] | [prev] | [next] | [standalone]

#31071

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.

[toc] | [prev] | [next] | [standalone]

#31072

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

[toc] | [prev] | [next] | [standalone]

#31073

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 ---------

[toc] | [prev] | [next] | [standalone]

#31074

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.

[toc] | [prev] | [next] | [standalone]

#31076

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.

[toc] | [prev] | [next] | [standalone]

#31077

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

[toc] | [prev] | [next] | [standalone]

#31078

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.

[toc] | [prev] | [next] | [standalone]

#31080

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

[toc] | [prev] | [next] | [standalone]

#31081

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.

[toc] | [prev] | [next] | [standalone]

#31083

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web