4 Bit MCUs, Still Alive and Kicking?

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