I'm not sure which group it was in, but someone who designs toys talked abo ut the extremes they would go to for cost reduction, removing useful, but n ot 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 quantit ies 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 volume s?
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
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.
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.)
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!
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
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.
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
(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):
about the extremes they would go to for cost reduction, removing useful, b ut not essential resistors because they were $0.001 each.
ts. I see a number of companies who make them, but I have no pricing. I hav e found 8 bit MCUs that are available for $0.05 each in just moderate quant ities at LCSC. But then, maybe LCSC is not a vendor anyone should depend on .
in millions? Is there a difference in price that adds up at such high volu mes?
4 bit MCUs make a difference in your designs?
ms6500
Some have pointed out that 8 bit MCUs are pretty durn low power. I guess t he question is if there is enough distinction between 4 and 8 bit MCUs to j ustify the issues of working with the 4 bit parts. At $0.01 per device, ev en 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
I wonder if this is an example of having the basic design working and stick ing 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 prod uct.
--
Rick C.
-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209
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.
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.
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.)
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.
Indeed.
--
Stef
The odds are a million to one against your being one in a million.
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.
What processors were you switching between that you had so much trouble wit h the conversion? Typically drivers are provided for peripherals. What so rt 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 ga llery, 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
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.
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.
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 gal lery, but it seems like those issues could have been minimized by prudent s election of the new MCU.
sy!
That's a separate issue. I've always taken great pains to provide for alte rnate 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 invent ory 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 t hat part in a different fab, rather to consolidate several parts into one w hich 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 re spin this board, I'm going to address all the manufacturing issues, since t hey are actually more important than the technical issues. There's no poin t in designing a great board that is hard to make. Unfortunately, FPGAs ar e not second sourced. :(
--
Rick C.
+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.