PIC versus Atmel/ESP/STM/etc.

[barshatriplee]

The choice can come out differently for different applications. But considering the cost, people are inclined to STM32 more. Here are some articles that you may find helpful.

https://www.wellpcb.com/pic32-vs-stm32.html
https://titoma.com/blog/stm32-pic32-manufacturing

[0xFFF0]

Development cycles are extremely fast these days. I don't want to deal with data sheets and registers for months. What every developer needs, are powerful libraries and a large number of sample applications. Almost all MCUs that are not in the Ardunio environment have lost.

[voltsandjolts]

I don't think the OP wanted an answer, they just started this thread to express their (blinkered, misguided) opinion.

[JPortici]

I don't think the OP wanted an answer, they just started this thread to express their (blinkered, misguided) opinion.

Which, IIRC, i not their first time

Development cycles are extremely fast these days. I don't want to deal with data sheets and registers for months. What every developer needs, are powerful libraries and a large number of sample applications. Almost all MCUs that are not in the Ardunio environment have lost.

You have the right to your opinion 

[newbrain]

Almost all MCUs that are not in the Ardunio environment have lost.

You might have misspelled lots.

[peter-h]

I would answer this a bit differently. Most applications can be done by most CPUs, within broad limits. But some companies discontinue parts much more readily than others. I used an Atmel part, it went OEL, I started a design with a replacement from Atmel, that got dropped even before I got around to doing the PCB (we had a fair stock of the old part). So, no more Atmel for me.

I would trust ST and (from many years ago; not sure about present) Hitachi/Renesas.

[NorthGuy]

Development cycles are extremely fast these days. I don't want to deal with data sheets and registers for months. What every developer needs, are powerful libraries and a large number of sample applications.

No need. Just use ChatGPT and it'll write the program for you instantly and much better than you ever could.

[SiliconWizard]

Almost all MCUs that are not in the Ardunio environment have lost.

Really!

[james_s]

The best microcontroller for a project is usually the one you are familiar with and know how to develop for. If I were starting out today I'd probably go with STM32 but since I know AVR I've stuck with the 8 bit AVRs, they're adequate for most of my needs. For other stuff there is the ESP8266 and ESP32, I use the Arduino framework on those, but Arduino is really only good for hobby projects.

[voltsandjolts]

^ Yeh. I think AVR MCUs + avr-gcc is the best 8-bit development experience.

[westfw]

AVR MCUs + avr-gcc is the best 8-bit development experience

how about 8051 with Keil (say, using the SiLabs advanced 8051 chips and their free version of the compiler/IDE)?
(Has someone used both enough to compare them?  I'm not interested in "8051 isn't really designed for use with C" arguments...)


Keil IDE and compiler have a good reputation, except for the price, and the SiLabs deal negates that...

[SiliconWizard]

You can't beat a Z80 with Turbo Pascal 3.0!

[brucehoult]

You can't beat a Z80 with Turbo Pascal 3.0!

I never used TP3, but from memory I could beat Turbo Pascal 1.0 with my eyes closed. On suitably small functions, with enough time to spend.

It was massively better than any compiler for 6502 at the time though. Maybe even now.

[nigelwright7557]

I have sort of got bogged down in PIC.
I have been programming then since mid 1980's.
I have so many projects I can draw on for functions like USB, FFT etc.
Why reinvent what I already have in abundance ?

The current chip shortage is a nuisance, I have to buy what Microchip have in stock then convert my code to that.

[peter-h]

Big mistake of Zilog to not bring out a Z80 based microcontroller. They owned the world, and gave it away.

They had all the peripherals anybody might want.

The chip shortage is over, but the distis are desperately trying to prop up the cliff before it breaks off completely.

[westfw]

Big mistake of Zilog to not bring out a Z80 based microcontroller.

They did, eventually.  The whole EZ80Acclaim series, apparently introduced in 2001.
But it was too little, too late.  Or perhaps too much, too late - the smallest current chip is a 100pin QFP for $10; I don't remember them ever doing a low pin count or low-priced uC, and those seem to have been what captured peoples' imaginations...


In the early days, companies without a flash process were at a significant disadvantage.  And Z80 programmers expected RAM-rich systems by then.

[mikerj]

AVR MCUs + avr-gcc is the best 8-bit development experience

how about 8051 with Keil (say, using the SiLabs advanced 8051 chips and their free version of the compiler/IDE)?
(Has someone used both enough to compare them?  I'm not interested in "8051 isn't really designed for use with C" arguments...)


Keil IDE and compiler have a good reputation, except for the price, and the SiLabs deal negates that...

The 8051 was the first microcontroller I ever used, though that was back when C compilers were available only to companies with deep pockets so it was assembler all the way.  The memory model of the 8051 architecture is rather awkward though (even compared to the 8 bit PICs) so I wouldn't say they are the ideal introduction to micros these days.  IME AVRs are in a different league in terms of ease of use for a noob.

[mikeselectricstuff]

I have sort of got bogged down in PIC.
I have been programming then since mid 1980's.
I have so many projects I can draw on for functions like USB, FFT etc.
Why reinvent what I already have in abundance ?

The current chip shortage is a nuisance, I have to buy what Microchip have in stock then convert my code to that.

At least Microchip have had some stock of some parts through the shortage, whearas STM32 people have been mostly screwed.

[mikeselectricstuff]

Big mistake of Zilog to not bring out a Z80 based microcontroller.

They did, eventually.  The whole EZ80Acclaim series, apparently introduced in 2001.
But it was too little, too late.  Or perhaps too much, too late - the smallest current chip is a 100pin QFP for $10; I don't remember them ever doing a low pin count or low-priced uC, and those seem to have been what captured peoples' imaginations...


In the early days, companies without a flash process were at a significant disadvantage.  And Z80 programmers expected RAM-rich systems by then.

Zilog did bring out a range of low-end MCUs, Z86 series, intended to compete with PIC16C5x - the pinout was compatible if you turned it upside down. ISTR it was used a lot for universe remote controls as they had licensed a library of IR codes.

[brucehoult]

The memory model of the 8051 architecture is rather awkward though (even compared to the 8 bit PICs) so I wouldn't say they are the ideal introduction to micros these days.  IME AVRs are in a different league in terms of ease of use for a noob.

They are, though they are not without warts.

• Only three pointer register pairs
• weird register that must always be 0 -- except when a mul just overwrote it
• limitations on registers for many instructions
• different instructions to access data in flash (fixed on the latest ones I think?)

RISC-V has got 6800-level simplicity and orthogonality, but with registers to burn. RV32I is as sparse and easy to learn as any 8 bitter, and they now start from $0.10 (in qty 50) for a C-friendly, gdb-friendly, flash-based microcontroller (CH32V003).

[Kleinstein]

Most µC programming is today done in C or a similar languish. So the ASM details and memory layout does not matter that much, if there is a well working compiler.
The 8051 and PIC16 memory organization is a bit awkward and does not make it easy to the compiler, e.g. with larger structures in RAM.
In most areas the AVRs are easier, but they have the problem with seprate adress ranges for RAM and Flash, e.g. causing the separaet prog_mem pointers in GCC.
Making it easy for the compiler got them a relatively good GCC suport and this helped a lot.
AFAIK the is "fixed" to some degree with newer models (mapping some of the ROM to RAM space)

The NUL register with the AVR GCC is not a fault of the AVRs, but a fault if GCC's default register use, tha uses register 0 for the "fixed" 0 value - they should have changed this when the mega chips with HW muliplier came out. One could still change this , if one recompiles as the libraries.  Though late this could still be changed. The resoring of the zero value is handled by the compiler and the normal programmer does not have to care (maybe with inline ASM that used the MUL commands) - so I would consider this more like a missed optimization.

For a beginner the quality of the manuals / data-seets and the quality of the available tools is more important than the actual µC. With lacking of buggy decumentation or compiler a µC is pretty much useless.

[peter-h]

But it was too little, too late

Yes, in a world where most code (in that sector) was done in assembler, the mfg had to carve the market for any new CPU out of solid rock.

The small chips (of any mfg) are still mostly programmed in asm.

[voltsandjolts]

The 8051 and PIC16 memory organization is a bit awkward and does not make it easy to the compiler, e.g. with larger structures in RAM

The AVR memory layout is more pleasant to both the compiler and programmer.
Keil C51 is impressive and has extended 8051 architecture lifetime by decades, but data/idata/pdata/xdata qualifiers are a nuisance.
A linear RAM space is oh so nice.

[mikeselectricstuff]

The small chips (of any mfg) are still mostly programmed in asm.

I doubt that - it's perfectly feasible to (carefully) use C on tiny parts. I've done various designs with both application code and a bootloader on a 512-word 10F322, all in C

[westfw]

Zilog did bring out a range of low-end MCUs, Z86 series

Those were Z8, not Z80, so they had no chance of winning the Z80-user market.

[AVR] are not without warts.
Only three pointer register pairs

Three pointers, four pairs for use with ADIW/SBIW instructions, and all 32 for MOVW.  Not all AVRs, BTW.

weird register that must always be 0 -- except when a mul just overwrote it

A compiler convention, not architecture.  avr-gcc chose R1 before there was a multiply instruction, which was a mistake. (RISC-V does something similar - An "always 0" register, right?  Although that IS at the ISA level, and doesn't have any weird exceptions.)

limitations on registers for many instructions

Mostly, the "immediate operand" instructions only work on the upper 16 registers (of 32 total.)
And the weird (newer) instructions like SPM, MUL, etc.

different instructions to access data in flash (fixed on the latest ones I think?)

only "fixed" on new chips with 48k or less of flash.