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 2 of 2 — ← Prev page 1 [2]

#31087

On 16/06/2022 15:47, Grant Edwards wrote:
> 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.]
> 

It's nice to hear the occasional success stories of common sense!

I read somewhere about another company who make some kind of boards used 
in the semiconductor manufacturing industry.  They ended up buying some 
400 brand new washing machines, to cannibalise them for a couple of 
components.

It's a tough branch at the moment :-(

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

#31082

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

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

#31084

On Thursday, June 16, 2022 at 3:35:03 AM UTC-4, Stef wrote:
> 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. 

LOL!!!  Oh, I've tried to talk to them.  They are not at all interested.  One of the key components on this board (by "key", I mean irreplaceable without a respin) Went EOL in 2013.  I could still buy them only because Arrow stocked a *bunch*.  When I gave a warning to my customer, they bought 3,000 devices.  However, when it came time to use them, they were missing.  lol   In subsequent situations, anytime I ask them to help with projections, they are silent.  


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

Being warned means nothing to me.  I am the guy who has to deal with the headache.  


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

Exactly my point.  Also, stockpiles carry risk of leaving you stuck with material you can't use... although, these days, excess material is worth money.  

-- 

Rick C.

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

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

#31086

On 06/16/22 07: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.
>>
>> 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.
>

One thing not mentioned is that all design at present should be done
to use only common functions in micros and no use of specialist
devices. If the code is written right, it makes it easier to respin
for a different device if supply becomes difficult...

Chris

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

#31075

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.

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

#31052

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.

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

#31056

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

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

#31063

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

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

#31088

On 14.06.2022 22:48, Theo wrote:

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

https://spectrum.ieee.org/plastic-microprocessor

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web