Triggers a memory about a story floating on (or sunk deep into) the 'net.

It was about a uC occasionallly losing bits in it's I/O configuration registers. The whole uC (or FPGA?) kept running happily, just some outputs stopped outputting the right signals untill the uC got a hardware reset. Then it worked all perfectly for a while, so no hardware pins blown, but the problem kept recurring.

It took several months of on- and off-again work, but I got through all 21 parts I selected.

I'd like to thank everyone on this thread for their help --- I got steered in the right direction toward the new tinyAVR 1-Series (which pulled in some impressive performance), and I also got some suggestions for other parts that ended up getting included, too.

If there are things you think need to be mentioned that I'm forgetting, please drop a line on this thread (or, shamelessly plugging my blog, as a comment on this post )

Jay, a stunning roundup of the chips and the oft ignored tools. This must have taken you some time. I'm glad you investigated some of the more obscure parts that, whilst I'd heard of, have never really appeared on my radar.

A couple of comments - the PIC16 series aren't RISC - they are accumulator based, not single cycle and not load/store. Microchip grabbed the moniker and repurposed it for their own ends.
One thing I found missing was the voltage range of the various devices - the M051 and XMC1100 for example are 5 volt parts which for ARM ('arm') based parts sorta sets them apart.

As for using Arduino shields, I have used the prototype ones ( the ones with lots of holes) to build up some test hardware for the XMC1100 and STM32 parts. I've even used used one with a small solderless breadboard on top for some quick prototyping.

the PIC16 series aren't RISC - they are accumulator based, not single cycle and not load/store. Microchip grabbed the moniker and repurposed it for their own ends.

Thanks for the comment --- RISC is a loaded term (as you can imagine), so I've added additional clarity to explain that while it is RISC in the sense that each instruction is precisely one word long and executes in a single cycle (unlike CISC parts like the 8051), it is *also* an accumulator-based architecture, which is quite different than most RISC parts. I hope you think this change makes the information more useful.

Just thought I'd let you know: Your navigation pane does not behave well on smallish screens. The bottom of it is off the screen and it is not scroll'able. Only if I zoom out to about 70% can I see the whole navigation pane. At 100% the last visible entry is "Dev Tools".

Chromium Version 59.0.3071.109 , display is 1366 x 768.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Just thought I'd let you know: Your navigation pane does not behave well on smallish screens. The bottom of it is off the screen and it is not scroll'able. Only if I zoom out to about 70% can I see the whole navigation pane. At 100% the last visible entry is "Dev Tools".

Good call — I will fix this as soon as traffic calms down (I can't even get a login page).

EDIT: No quick fix, other than removing content, unfortunately. I'll look at some core CSS changes I can make long-term to shrink that down, but there's a lot of dependencies I'll have to work through. Sorry about the inconvenience!

By the way, for people who tried visiting earlier and got 503'd, I've made some changes to my network configuration, and I think the site should be back up for most users.

Atmel Studio
"The excellent IntelliSense engine that Microsoft spent years perfecting has been replaced by some sort of Atmel-proprietary “Visual Assist” technology that ..."
1. IntelliSense and AVR is available from third party(ies)
2. Visual Assist from Whole Tomato Software

Microchip Customizations
"As these compilers [XC] are quite expensive and ..."
About 1USD/day though the dongle is 1495USD

Discussion
megaAVR
"While the megaAVR has a perplexing debugging experience that requires two completely different interfaces and protocols to work with the part, ..."
fyi, once debugWIRE is enabled then stay with it until done.
"... low-cost, open-source programmers (which don’t support the UPDI interface)."
pyupdi is Python UPDI programming via an inexpensive USB UART; debug via UPDI is currently only Atmel-ICE or Power Debugger

------------------------------------
Notes
1. IntelliSense with most AVR is available from VisualGDB
2. IntelliSense is in Visual Studio Code and AVR might be available via the Native Debug extension
3. The next release of PlatformIO may restore AVR debugging; Visual Studio(s) are some of the IDE that integrate PlatformIO
4. LLVM AVR may be a current or future alternate to AVR GCC
5. ATmega328PB is approaching 1USD each for 100 though it has a supply and demand problem that's easing 17Q4 (should be resolved 18Q1)
6. 32KB tinyAVR 1-series is likely for '18 and probably under the price limit

"And interrupts are one of the weak points of the AVR core: there’s only one interrupt priority, ..."

All things considered, I much prefer the AVR "one priority but lots of vectors (separate vectors for uart rx and tx, even!)" over something like the PIC "two priorities = two vectors" scheme. Or even the 68k "7 priorities with one vector per priority."

I see that Jack Ganssle has linked to the survey in his latest newsletter...

Quote:

Many readers sent this link, which explores 21 different microcontrollers, pondering the strengths and weaknesses of each. Some vendors will not be pleased...

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

Just saw an announcement, yesterday (Nov 21, 2017) for a 0.25 USD MSP430. Did not note details

It's a chip with 0.5kB of FRAM program memory, and ... more peripherals and RAM (also 512b) than you'd expect to see on a chip with that little memory. (Essentially, I guess you get to get to do a "little bit of stuff" with "your choice" of one or two peripherals.) An interesting strategy? (Also, TI seems to be following through with their "FRAM is the way" opinions. Also interesting.) 256 instructions is ... not much.

The new chips are the FR20xx, even smaller and cheaper than the 21xx series. Alas, like many of the chips advertised as meeting a particular price point, the "small quantity" price isn't that great. Lots of chips are similarly priced, including a bunch of the new AVRtinys.

The "25 functions" is apparently a set of build-able, app-notes with downloadable code, designed to be "easily customizable." They have a fancy "flipbook" in annoying format (heh. Rather like the old Microchip "tips&Tricks"?)

Wow. Paraphrasing: "Arduino makes things too easy and obscures what I'm trying to teach, but most modern chips are too complicated (especially the initialization that has to be done before you start.)" He does an OK job justifying his choice, but it's such a "legacy" architecture...

Other MCUs often don’t have dev environments for macOS or Linux. [and the school doesn't require students to have PCs.]

That's sort-of fair. I wonder if another year will improve AVR's standing (also supported by MPLAB-X these days. Almost.) And PlatformIO/VSCode is all free...

I tend to believe that a microcontroller class should introduce a second, different CPU architecture. Because "compare and contrast" teaches you a lot.

>> I tend to believe that a microcontroller class should introduce a second, different CPU architecture.

My experience is yes for mid-80s, no for mid-90s.

Ah. I misspoke, slightly. In the mid-80s I would have compared "cpus." Now, I'd compare microcontrollers more at the chip level: "we've studied the PIC16 for a while, now let's see what a PIC32 looks like. Look at the huge address space! Look how they've used that to allow LOTS of registers for the peripherals! Look how everything is treated as memory." Any 8bit CPU vs any 32bit CPU should be "interesting." (well, perhaps not x86 or those Renesas super-Z80s.)

[only] 140 semester-hours [in a class]

I dunno. My (late 70s) Assembly Language class was mostly IBM360, but spent a short time on the PDP11 (2 weeks of a semester-long class? One assignment, using a simulator, looking at the results in memory). I think it was still useful...

The UTexas Online Microcontroller class bypassed the initialization complexity (of TI Tiva ARM CM3) by using instructor-provided initialization code and "starter projects." That worked OK, I think. We never did learn how to set up a project from scratch. (and they used Keil - Windows Only...)