How do you keep up with the MCU offers ?

[Koen]

Hello,

every time I visit the website of a MCU manufacturer, it seems a revolution happened. New and shiny MCUs everywhere. The last ones to me being 256K embedded RAM STM32s which I wish I had discovered sooner, dual core Cortex-M4F/M0 LPCs and finally Cortex-M7 chips with double precision floating point processing unit. And I feel like I haven't seen 1% of the Cortex-M offers.

Would you have tips on how to keep an eye on the industry new offers ? A journal, a website, an aggregator to recomend ? Thank you !

[dannyf]

Their reps tend to hand out literature and talk about their new products.

Otherwise, new products don't matter unless you actually use them.

[tggzzz]

every time I visit the website of a MCU manufacturer, it seems a revolution happened. New and shiny MCUs everywhere.

"Revolution" is completely the wrong word. "Evolution" is accurate.

I recently returned to using MCUs after a 20 year gap, and was unpleasantly surprised at how little had changed since the early 80s. I was able to use the same design and debugging techniques (because that's what the manufacturers offer), and had exactly the same problems that I experienced in 1982. (Techniques: C, In Circuit Emulation, ADCs/DACs)

All that has changed is that the devices have become much more integrated and much cheaper, and a bit faster. Oh, and it is much easier and cheaper to make PCBs, either using laser toner or by getting them fabbed in China for £15.

Would you have tips on how to keep an eye on the industry new offers ? A journal, a website, an aggregator to recomend ? Thank you !

Multiple versions of all of the above, plus hard work and a desire to remain current - and to branch out into new technology and applications.

There are no short cuts.

[donotdespisethesnake]

I think the M7 has a single precision FPU, but apart from that you seem pretty up to date.

Good point re evolution. The architecture and methods of embedded development have changed little in 30 years. That's good for me, because I don't need to learn many new skills, and can even still claim to be an expert.

[tggzzz]

The architecture and methods of embedded development have changed little in 30 years. That's good for me, because I don't need to learn many new skills, and can even still claim to be an expert.

One technique that every engineer need to develop is ways of determining what is or might be a revolution (the "signal"), and what is mere variations on a theme (the "noise"). Understanding the underlying fundamentals makes that easier, saves a vast amount of time, and allows us to concentrate on the interesting things.

A good starting point is, whenever a manufacturer says something, ask "so what?".

[Howardlong]

There is another factor, and that is I tend to concentrate on the families I have experience with. Jumping to another manufacturer's ecosystem in general is a very significant step, akin to changing your PCB CAD package. Although the fundamentals generally remain the same, they all do things in a different way.

About nine months ago I started using NXP and TI Cortex M4 after being about 95% PIC for the last 20 odd years. This followed a disasterous series of blunders by Microchip over the period of a couple of years, culminating in their PIC32MZ series that were very late in silicon release, and some very buggy silicon. In particular the ADCs turned out to be a crock. Add to that I had to learn their new Harmony framework to do anything more than blink an LED, I thought if I was going to have to learn something new then now's the time, and NXP and TI were offering devices that appeared to fit the bill.

I fear that trying to be an expert across all manufacturers is going to be hard. It's not much different to thirty years ago, when you were either a Z80 or a 6502 person. Sure, I wrote code for both, but I was most comfortable on the Z80.

What's been interesting for me is that the switch to ARM from MIPS hasn't been a big deal, but then these days it's all in C anyway. The big differences are in the implementations such as clocking and the peripheral sets, and in the various manufacturer supported toolchains.

Regarding the difference between now and MCUs of 20 years ago, surely it must be in debugging? 20 years ago I don't think there was any on chip debugging on MCUs. You'd have to blow a grand on an ICE, and they tended to be chip specific too. I can't remember using IDEs either back then for development, it was edit, compile, program without any debug step because ICE was well beyond the reach of the average tinkerer.

[tggzzz]

There is another factor, and that is I tend to concentrate on the families I have experience with. Jumping to another manufacturer's ecosystem in general is a very significant step, akin to changing your PCB CAD package. Although the fundamentals generally remain the same, they all do things in a different way.
...
Regarding the difference between now and MCUs of 20 years ago, surely it must be in debugging? 20 years ago I don't think there was any on chip debugging on MCUs. You'd have to blow a grand on an ICE, and they tended to be chip specific too. I can't remember using IDEs either back then for development, it was edit, compile, program without any debug step because ICE was well beyond the reach of the average tinkerer.

Just so.

"Then", as now, it was usually sensible to choose the CPU/MCU on the basis of the tool support and ecosystem.

(And I did note that "much cheaper" was a major difference )

[Howardlong]

(And I did note that "much cheaper" was a major difference )

Indeed, I remember C cross compilers for the Z80 and 68000 were a serious investment in those days. I was still doing most of it in assembler. I do vaguely remember finding a C compiler for the Z80 that was free in the early 90s, on a BBS somewhere, certainly it was before the internet had found its way into the home or business. How did we ever manage?

[tggzzz]

(And I did note that "much cheaper" was a major difference )

Indeed, I remember C cross compilers for the Z80 and 68000 were a serious investment in those days. I was still doing most of it in assembler. I do vaguely remember finding a C compiler for the Z80 that was free in the early 90s, on a BBS somewhere, certainly it was before the internet had found its way into the home or business. How did we ever manage?

I remember when a 6800 cost a week's wages. And 128 RAM bytes was a single chip; I still have it. And Whitesmiths' C compiler just about fitted into a 64K CPM machine, provide the symbol table was small

[nctnico]

IMHO you can stick to one supplier. They all look what the others are doing and what sells and what does not. All major ARM players (effectively NXP and ST; Freescale and TI hopped onto the ARM bandwagon later and don't have a very wide portfolio) have similar devices.

Back when I had to choose for an ARM vendor I looked at several offerings and checked things like:
- Ease of programming. A serial bootloader is much easier and versatile
- Identical peripherals in devices which make it easier to share code between different devices
- Easy to use peripherals
- Short errata sheets
- Simple to understand datasheets/user manuals
- No hidden fine print/lies about specs (I blacklisted Atmel for having that)
- Simple code examples
- Good availability from Farnell/Element14

[Kjelt]

Yes there are only a few suppliers to choose from, it will take you about 3 minutes per supplier per month to keep up by visiting their websites and to check if there is a new productline or new additions to the family announced. Or go to a embedded fair and let them tell you whats new.

But how it usually works: you get a project (or business assignment), you make the requirements for the uC and max. BOM, you check the major manufacturers or the ones you are aquainted with for their offerings that match your requirements and price and then you go compare. If two weeks later there is this much better uC announced you don't care since it will take some time before you can get decent amounts of silicon anyway. You have made your choice go finish the project and take notes for next project.

[EEVblog]

quote]How do you keep up with the MCU offers ?[/quote]

You don't.
You keep using the part(s) you've always used and are proven.
If you have to re-evaluate your entire micro choice for every design you'd waste an awful lot of design time.

[westfw]

I keep thinking that this sort of thing is why cheap evaluation boards are so important.  Working engineers hardly ever get to do a detailed evaluation of what processor they should use in their next design.   It's always "use the thing you used last time" (perhaps the faster, bigger, more integrated version), "the thing your boss used the last time", "the thing an overeager salesman sold your boss" (watch out for those!), or maybe "the thing most similar to the obsolete thing that you're used to."  If you want to get an engineer interested in a brand new architecture, you pretty much need to catch them while they're in "hobbyist" mode, sell them a cheap eval board that they can fiddle with, and MAYBE they'll start planting the seeds of "Hey.  I've been using an XXX to flash LEDs at home, and it's pretty neat..." so that sometime down the road "XXX" will have some mindshare...

I really like "comparative microcontrollers", but it is pretty amazing how much time it can take.  It's a good thing I retired.

Trade magazines were better than the web has become at getting news of interesting products out. :-(  Something about having a finite number of pages to browse during your coffee break, with "just enough" detail to whet your appetite (rather than the black hole/worm can of a blog or EE News site.)  I suppose that you could structure a blog around this, but I don't think I've seen one that does it successfully (see above about "taking an amazing amount of time.")