Yeah.. which micro?

[tszaboo]

Wow, I would never've imagined the world would run out of atmega328s.
I think the same thing happened like with many other components. The chinese bought the entire stock and are hoarding them, with scalping the prices.
When I look at octopart, I see many on stock at not authorized distributors.

[Siwastaja]

I can see it happening like this:

Designer can't buy the STM32 they originally used.
Pick another STM32.
Can't get any STM32.
Panic.
Try other ARM vendors.
Not much better.
"Hey, there was this popular Arduino thing, I tried it a decade ago, wasn't it ATMega328P? While underperforming and lacking peripherals, it was quite simple to use and it worked. I'm sure I can make it work. Is it still available?"
Hit order button in panic.

[fchk]

So, before I get to board layout I wondered what might be a good MC choice in this time where parts are like gold dust? Is the ATMEL328 a good choice?

I left the AVR family a decade ago. Too expensive for the features available. The 328 is a typical hobbyist choice because of Arduino. For a business I'd think different.

• 5V is athing of the past. Most current devices use 3.3V today. Using lower voltages decrases power, and this relation goes with a power of 2. Imported if you plan for mobile devices.
• Use SMD parts whereever possible. The cost of manufacturing per part is much higher for through-hole parts (*5...*10)
• The CPU core is not that important any more. In a business settimng noone will code in assembly any more since it is too expensive. Unless you have 6 figure quantities.
• The available peripherals are important. Many PICs for example have numerical controlled oscillators or configurable logic blocks etc. If your application can benefit from special hardware blocks, choose your MCU accordingly.

I'm tempted to make the MC on a daughter board so I can change it easily. Is this a good idea or is there a range of MC that are pin compatible anyway?

Too expensive. Connectors cost money, PCBs const money, assembly cost money, and the reliability decreases. If necessary, just do a new board design.

For small projects I often use PICs. Microchip has own fabs for them, so the long-term avialability usually is not a problem. AVRs are manufactured elsewhere as Atmel sold their fabs long ago. The newer PICs have better peripherials then the classic AVRs, and they usually run at full speed even at lower voltages.

[Siwastaja]

The biggest issue in those large, expensive AVRs is that while they grow in number of IOs and available flash and RAM, the peripherals remain the same, quite stone-age actually.

There was one special AVR which included CAN peripheral and some special AVRs with motor controller timers, but these were all "special snowflake" parts, even more expensive, and pretty old otherwise.

In the meantime, even the crappiest, lowest cost ARM MCUs come with 3-phase motor control timers, USB, often CAN, even ethernet on "mid class" devices, still cheaper than some ATMega640 (which I did use in a few projects. A nice chip when you just need a lot of simple IO.)

I didn't go into ARM for CPU processing power or memory. That was secondary, a side effect, or "nice to have". Better peripherals is the real reason. It's also the reason not to go back to the AVR devices except for the simplest projects. Sadly, nothing prevented Atmel from implementing more and better peripherals, but they trusted their successful product lineup from early 2000's so much they didn't want to change it at all. PIC had more variety in peripherals all the time.

[Psi]

still cheaper than some ATMega640 (which I did use in a few projects. A nice chip when you just need a lot of simple IO.)

Or if you need 4 hardware UARTS    
That why i used it.

[Kleinstein]

The old AVRs got expensive with large memory.  The newer ones (Xmega related like DA, DB series or the xx09 ones) have also more capable periphery and are cheap also with 64 K or 128 K.
They however need a new programmer.

If it is for 4 UARTS, the new  AVRxxDA48 comes with 5 and the 64 pin version with 6.

[ssashton]

I'll use JLC PCB to assemble my boards and the model number they have most stock and lowest price is STM32G030F6P6TR and the datasheet shows some variations based on memory. However I realise now this is called the STM32 G0 series:




There are also Arduino compatible STM32 boards based on what I thought was STM32 F10, but it is actually STM32 F1 series:

https://www.instructables.com/Getting-Started-With-Stm32-Using-Arduino-IDE/

A lot of you are talking about knowing the peripheral registers, but having only  worked with Arduino IDE I don't think I've dealt with this. I guess that is all part of the Arduino library. So I think I need to take a step back and ask; even if I used the ATMEL 328 which the Uno is based on, what would I need to do to use the bare chip in my project? Can I not simply connect an FT232 to the RX / TX pins and program it via Arduino IDE? I do kind of remeber hearing something about AVR chips not having the embedded bootloader installed?

P.S. I don't need clever peripherals, I've already got this working on the Arduino Uno and I programmed it in Arduino IDE (C++). All the MCU does is take input from a rotary encoder, display some text on OLED (128x64, but I might go bigger) and spit out I2C writes directly to specific registers on the DSP chip.  Although I would be nice to add an SD card, USB file transfer or other way for the user to drop a text file with custom filter coefficients on the MCU that can then be written to the DSP.

In reality though, I'm not paying bloody $6 for a bare ATMEL328 when an STM32 is $1. So I better start learning how to move this project over to the STM32 G0. ESP32-C3 is another sensibly priced and stocked option.

[Siwastaja]

Oh, if you have zero experience working with microcontrollers and only have worked with Arduino Uno and Arduino libraries, I very strongly suggest you get Arduino Uno or compatible boards and work with these. Even from iffy sources. Trying to start learning microcontrollers now, from scratch, would be very time-consuming and would kill your actual project.

Sure, I have worked that way in the past, promise something in 3 months then start learning how the heck I do that. And then it takes 6-9 months and the customer is not happy. In the end, it always worked out but it's a stressful situation.

Really, unless you are really experienced, the best advice is to keep using what you are comfortable with. Unless you know that Arduino libraries are available on some other MCU, and you know they work exactly (or very close to) the same, assuming this and just buying something is a huge risk. You'll learn, sure, but you'll fail to deliver the project as well.

When you are more experienced and worked with many different microcontroller families, you get better at finding the relevant things in the documentation and have seen many of the traps, so it's much faster to develop even on an unknown microcontroller. And if you have worked on 8-bit PIC or AVR before the Arduino era, that's a really good start to build on, but if you have only worked with Arduino libraries and your projects have been simple enough so that you didn't need anything else, then you have quite some road ahead. You may be able to cope with libraries of whatever MCU vendor (such as STM32 HAL) but the problem is, they are all different, they are not similar to Arduino libraries at all, and look much more complex and bloaty, compared to the simple Arduino interfaces.

Arduino sure does good job getting people motivated, but it's really like those training wheels. The next step is to remove the training wheels and keep going (this includes falling sometimes), not buying a Harley Davidson motorcycle.

[Kleinstein]

The step from the Arduino libraries to the STM HAL libraries may not be so bad. It is some change, but at least one would not complain about the limitation of the HAL libaries.  HAL produes quite some overhead ( in my case (depends on the periphery used, more in debug mode) some 14 kBytes - which is a bit much to use a 16 kByte µC) for the start, but it is not so bad with a larger µC. The Arduino libs also add some overhead and some init code is needed anyway.

The STM32 are at least a µC worth looking at them and maybe have a look at the HAL documentation. Everybody learns different and maybe you like (or hate it) that style. I personally do not like HAL very much, but I came from the AVRs programming very close to the HW, paritally in ASM and some hate towards bloated documatation. It only got better with the PDF search function.

[SiliconWizard]

Whatever you do, sticking to a good old part forever just because it's your comfort zone eventually leads to panic once the part is not available anymore. It's a very non-resilient approach. So exploring new MCUs and new things in general is a GOOD thing. The later you do it, the more painful it will be.

[NorthGuy]

Really, unless you are really experienced, the best advice is to keep using what you are comfortable with.

But if you do that, how do you become really experienced?

[Kleinstein]

Onece you know 1 µC pretty well and understand the principles, it is usually not that complicated to learn to use a different one.  It is still convenient to still limit to a few types, not to have too many IDEs on the computer.  Besides learning about the µCs one may also need new hardware for programming / debugging with a new µC type.

Some µCs are also relatively similar, like the STM8 and STM32 series. Different CPU, but similar periphery. When programming in C the CPU part does not really matter - there can be speed differences, but most programms don't need the full speed anyway.  Switching to a new µC family is mainly learning about the IDE and periphery, not much about the CPU. Chances are one would anyway look up the periphery details when programming the parts close to the HW - so the quality of documentation can be a big point.

[james_s]

Whatever you do, sticking to a good old part forever just because it's your comfort zone eventually leads to panic once the part is not available anymore. It's a very non-resilient approach. So exploring new MCUs and new things in general is a GOOD thing. The later you do it, the more painful it will be.

I don't think the entire 8 bit AVR series is going to vanish overnight, even if they go out of production I'll still be able to find enough of them for my personal projects. If I really have to move up to ARM some day I will, but I have no compelling reason to do so at the current time.

[Siwastaja]

Really, unless you are really experienced, the best advice is to keep using what you are comfortable with.

But if you do that, how do you become really experienced?

Yeah, excellent question, my comment assumed project is already in a crisis due to lack of parts, and job needs to be done. In bigger picture, you should really find projects where you get some leeway for experimenting and widening your skills. Best projects are such where the whole team learns. But sometimes you just need the Job Done ASAP. If all projects you do are that way, you never learn much. You just learn to do the same projects tiny bit quicker every time.

[Siwastaja]

Onece you know 1 µC pretty well and understand the principles, it is usually not that complicated to learn to use a different one.  It is still convenient to still limit to a few types, not to have too many IDEs on the computer.

ARM finally ended this era. Not only the same tools (such as compilers) work for all ARM controllers, there is a certain "culture" in how the peripherals are organized. Even the CPU cores and tools standardized, this is already quite an improvement even when the peripherals are different.

Sadly, many people opt to continue the mess of "one tool for each manufacturer", or even worse, "one tool for each manufacturer per each 3-4 years" for no reason other than wrong impressions, bad documentation or lack of good tutorials.

[nctnico]

Onece you know 1 µC pretty well and understand the principles, it is usually not that complicated to learn to use a different one.  It is still convenient to still limit to a few types, not to have too many IDEs on the computer.

ARM finally ended this era. Not only the same tools (such as compilers) work for all ARM controllers, there is a certain "culture" in how the peripherals are organized. Even the CPU cores and tools standardized, this is already quite an improvement even when the peripherals are different.

Sadly, many people opt to continue the mess of "one tool for each manufacturer", or even worse, "one tool for each manufacturer per each 3-4 years" for no reason other than wrong impressions, bad documentation or lack of good tutorials.

Standarisation of your tools is key indeed. IMHO Eclipse (on which many of the ARM IDEs are based) or Visual Studio code are good choices nowadays with support for many languages so they also work far beyond the embedded microcontroller world (think VHDL, Verilog, Python, C / C++, Java, Lua, etc).

[NorthGuy]

Standarisation of your tools is key indeed. IMHO Eclipse (on which many of the ARM IDEs are based) or Visual Studio code are good choices nowadays with support for many languages so they also work far beyond the embedded microcontroller world (think VHDL, Verilog, Python, C / C++, Java, Lua, etc).

Text editor. It's lightweight, fast, and universal, and will stay universal for the rest of my days.

[ssashton]

It seems that Arduino IDE have support for a number of ESP32 types, so I think that sounds nice. In addition I've read that ESP32 have a pre-loaded bootloader that allows programming of the chip directly over UART or USB. The WROOM modules with antenna, crystal, and ROM is also attractive.

https://randomnerdtutorials.com/installing-the-esp32-board-in-arduino-ide-windows-instructions/

I ordered a ESP32 C3 dev kit so I'll see how I get on with that.

I do not have a deadline and I am the whole team. So that's an advantage in some ways, but obviously I'm also very inexperienced.

[nctnico]

Standarisation of your tools is key indeed. IMHO Eclipse (on which many of the ARM IDEs are based) or Visual Studio code are good choices nowadays with support for many languages so they also work far beyond the embedded microcontroller world (think VHDL, Verilog, Python, C / C++, Java, Lua, etc).

Text editor. It's lightweight, fast, and universal, and will stay universal for the rest of my days.

But no syntax highlighting, realtime error indicators, function outline, call hierarchy, etc, etc. No thanks!

[james_s]

But no syntax highlighting, realtime error indicators, function outline, call hierarchy, etc, etc. No thanks!

I use Notepad++ on my Windows machine, Pluma on my Linux machines and Atom on Mac, all three of these have most of these features.

I've had to use Eclipse on a number of occasions and it is a steaming turd. It's practically the poster child for software bloat.

[ssashton]

Alright, well I got Arduino IDE to install support for numerous ESP32 modules! It returns no errors when compiling for the RISC-V ESP32 C3 dev board (except when I tried to manually include avr/pgmspace.h). Now I just need to wait for the dev board to arrive.

https://docs.espressif.com/projects/esp-idf/en/latest/esp32c3/hw-reference/esp32c3/user-guide-devkitm-1.html

I do wonder - since the ESP32 C3 has built in UART and is USB compatible AFAIK, why do they need to include a Silicon Labs USB to UART chip on the dev board?

[westfw]

since the ESP32 C3 has built in UART and is USB compatible AFAIK, why do they need to include a Silicon Labs USB to UART chip on the dev board?

Probably for Arduino compatibility?  The Serial port can be coerced into supporting "automatic reset and upload", while USB ports tend to be more problematic in that regard.  I believe that the board uses the ROM bootloaders, and the USB bootloader might be "tricky" to run, cross platform.

(I'm not sure I'd have picked a ESP32-C3.  The RISC-V version is relatively new, and there isn't a lot of community experience, AFAIK.  OTOH, it's less obscure to actually use, than the Tensilica core.  Good Luck.)

[PCB.Wiz]

I do wonder - since the ESP32 C3 has built in UART and is USB compatible AFAIK, why do they need to include a Silicon Labs USB to UART chip on the dev board?

Maybe to also cover bugs or other possible issues ?
It sounds like 'USB' a dedicated block, I wonder what BAUD rates it supports or does it skip a 'baud' idea if the connections are fully internal ?
I'd expect some firmware needed for this to function ?  Does the ROM have enough ?

3.4.9 USB Serial/JTAG Controller
ESP32-C3 integrates a USB Serial/JTAG controller. This controller has the following features:
• USB 2.0 full speed compliant, capable of up to 12 Mbit/s transfer speed (Note that this controller does not
support the faster 480 Mbit/s high-speed transfer mode)
• CDC-ACM virtual serial port and JTAG adapter functionality
• programming embedded/external flash
• CPU debugging with compact JTAG instructions
• a full-speed USB PHY integrated in the chip

[brucehoult]

Just from a quick look on Mouser a few minutes ago, it appears the cheapest and in stock MCUs at the moment, at least on Mouser, are the PIC32MM. I would probably take that if I had no choice.

At least that's MIPS, not the awful PIC 8 bit ISA(s).

I assume the peripherals are similar. A lot of people seem to say "sure the PIC instruction set is rubbish, but they have better peripherals than Atmel" (back when they weren't the same company anyway).

[james_s]

I don't really blame the PIC for its faults, it was one of the first products of its kind on the market. I certainly think the AVR was a large step up though, more than 20 years ago when I first started out with microcontrollers I tried PIC and AVR and it didn't take me long to settle on AVR.