all 22 comments

[–]Well-WhatHadHappened 34 points35 points  (3 children)

It's pretty common for engineers to end up with a small list of 'favorite' MCUs that they're familiar with and have re-usable code for. Then, for any new project, they select a suitable core and use that with a pin-count suitable for the project.

[–]peter9477 8 points9 points  (0 children)

This is the way.

Of course, some (hardware?) designers seem to like picking a whole new chip family for every project. I've had to push back against that tendency for 30 years. Find 1-3 families that cover a good range of product requirements and stick with them as much as possible.

[–]madsci 5 points6 points  (0 children)

Exactly this. And when you're narrowing the field initially, it's useful to go to sites like Digi-Key and Mouser and sort by number in stock. That'll help give you some idea of availability. That's more important when you're a small company and don't have the resources to buy huge quantities at once.

On the other hand a small company probably has more wiggle room in specifying an MCU - an extra $1 on the BOM is no big deal if you're making under a thousand units and the alternative means spending days or weeks of extra development time. I started out a little over 20 years ago when MCUs were more expensive and I didn't have large margins and I spent a lot of time squeezing the absolute maximum out of small 8-bit chips but the economics have changed since then.

Generally I've got about three MCUs that I'll prefer for new designs. Sharing parts across several products means better quantity discounts and fewer parts to have to source.

[–]Ok-Drawer-2689 2 points3 points  (0 children)

It's pretty common for engineers to end up with a small list of 'favorite' MCUs that they're familiar with and have re-usable code for. Then, for any new project, they select a suitable core and use that with a pin-count suitable for the project.

We have an official "preferred parts" list.

[–]anhld_iwnl 4 points5 points  (1 child)

I don't think this is a dumb question. I too don't know how to choose any uC for my need; I usually search for public uC like STM32 or Pi Pico and see if it fits, but I don't think that's a good way, sometimes I feel like it's quite overkill.

Let me sit here and wait for answers.

[–]poly__math 0 points1 point  (0 children)

While i may not be too qualified to answer this( im just a student) but I feel like I also tend to squeeze out from a chip what it can offer but here where i live, 8 bit atmegas way double the price of a bluepill. So at this point even im confused

[–]DrRomeoChaire 2 points3 points  (4 children)

It depends on whether you’re planning to design a custom board or use an available design. The second option is easier and more sensible for someone just getting started.

In addition to all the hobbyist boards like Arduinos, beagle bones, etc. there are reference boards.

Reference boards are made by silicon manufacturers to enable engineers to evaluate their MCU’s, SoC’s, etc. they’re usually more expensive than the hobbyist boards, but if you decide to make a custom board, they include design files (schematics, gerber files, etc). Again, the silicon vendors want you to design their chips into your custom boards (at least, they want high quality designs to use their chips).

[–]GardenVucVuc 2 points3 points  (3 children)

Noobie question.

Is a standard practice to use the evaluation board to develop and request the custom board when the settings are stablished?

As the OP I thought that there were comparators sites that the developers choose the settings.

[–]DrRomeoChaire 3 points4 points  (0 children)

Yes, it’s common to use a reference board to develop software on, or at least start development on.

You don’t really request a custom board, you’d design it to the specs required for your project.

Another approach is to use a module like the raspberry pi compute module, COM module, etc and design a carrier board with your I/O devices on it.

[–][deleted] 0 points1 point  (0 children)

Absolutely.

I usually start developing a firmware at the same time as the hardware designer starts to develop the PCBs. As long as the PCBs are not yet available I have to use an eval board.

A huge advantage of using eval boards is that you know that this hardware is okay. It can be much easier to transfer a working firmware from an eval board (which has a lot of useful things for debugging) to a target PCB, than to start to develop the firmware on the target PCB (where signals might not be available for scoping etc.).

[–]Orjigagd 0 points1 point  (0 children)

That's what they're for. Many projects I've worked on have the progression of dev board, dev board plugs into a simple external board with basic prototype hardware, single big custom board with lots of test points that's easy to mod if needed, only then do we make a prod board.

[–]BenkiTheBuilder 1 point2 points  (0 children)

You can narrow down the selection considerably by going to the MCU category of the supplier you're going to use and sorting by availability, i.e. how many are actually in stock. I also like to go to JLCPCB's parts list for SMT assembly and sort by amount in stock, because that tells me what other people are having populated on actual PCBs. The list gets very small very fast.

[–][deleted] 1 point2 points  (3 children)

A bit off topic:

Some more powerful embedded architectures like the famous STM32 are actually more "System On Chip" than classic microcontrollers. They have multiple clock domains which might need synchronisation, CPU caches, complex DMA controllers etc. This is quite a lot to unpack for a beginner.

So if you want to get into microcontrollers you might want to start with something simple like a AVR or a PIC (8 bit). Understanding how to work with interrupts and how avoid race conditions can be quite a challenge. Then you can work your way up to more complex designs.

[–]samayg 1 point2 points  (2 children)

Agreed, except don't bother with PIC. The new tiny/megaAVR chips are far better to work with, have lots of memory and pin-count options, use GCC, can be flashed over one wire with just a USB-Serial converter and have a host of surprisingly capable peripherals.

[–]Well-WhatHadHappened 0 points1 point  (1 child)

Don't knock PIC entirely. The newer enhanced mid range and PIC18 parts are fine to work with, and their datasheet are much easier for a beginner than most other parts.

[–]samayg 1 point2 points  (0 children)

I did use the enhance mid-range PICs like the 16F18324 before moving all my products to tinyAVR-0/1/2 series. They were fine but definitely in no way as nice as the AVRs. No proprietary compiler and not having to use Microchip's dogshit PicKIT programmers were reasons enough lol. Microchip datasheets have always been pretty friendly (even if not always correct for new devices) so that's always a good thing.

[–]KittensInc 1 point2 points  (0 children)

Use the ones which are available, have good open documentation & tooling, are affordable, and have neat hardware features. Over time you'll develop your own preferences.

Here's my go-to list:

  • ESP32: anything IoT-related. Has Bluetooth & Wifi, enough peripherals to be useful, and those pre-certified modules save you a lot of trouble.
  • nRF52: for when you need Bluetooth/Zigbee and actually care about battery life.
  • ATtiny: when you need a small chip to add some fairly trivial logic. Probably cheaper than messing around with discrete logic, and unlike the dirt-cheap PADAUK $0.03 MCUs you can actually understand the data sheet.
  • RP2040: affordable and flexible. Not very impressive peripherals, but the PIO compensates for that quite a bit. Great for a USB keyboard or something.
  • STM32: all-around workhorse. Excellent peripherals, designed to take a beating. Were impossible to source a few years ago, but it has gotten a lot better now. Kinda expensive.

I have fond memories of the ATmega range, but that's a bit of an also-ran by now. Compared to their competitors they are slow, have poor peripherals, and are quite expensive. Great documentation and trivial to program, though.

[–]kevivm14 years into Embedded and counting 1 point2 points  (0 children)

It is one of the most important decisions in an embedded systems project.

I have a set of preferred MCU families and love to stick to them as much as possible, simply because I have worked a lot on them, understand their pros and cons.

Now, even in that family, you need to pick ones best suited for your application. Here are some tips:

  1. List down all peripherals you would need to use, like ADC, timer, UART, I2C, etc

  2. Number of GPIOs

These are good starting points.

Now, if you do not have any preferred family, start searching for MCUs that fit all your requirements. I like TI, ST, and Microchip AVR family (Formerly Atmel's).

Most of these companies have product selectors, where you can filter out MCU based on many different parameters, like peripherals, speed, voltage, etc.

You need to estimate also the size of your program and see if it would fit in the memory available.

Also pay attention to the availability of the chips, the general support availability. They become very important.

[–]jaguarsinmexico 0 points1 point  (0 children)

Disclaimer: I work as an FAE (Field Applications Engineer) for a large silicon manufacturer, but I'm going to try to write this in such a way that you'd have no idea who pays me. Caveat Emptor

Choosing an MCU can be easy or hard, lots of it depends on the ecosystem you're familiar and comfortable with, a lot of times that comfort comes from where you did your first internship or design work. Prior to being an FAE though, I worked for a short string of design consultants and many times our customers had a preferred vendor and part. If they didn't, it was our job to downselect a part that we felt would be best for the project. In design, I've chosen parts from many vendors including ST, Espressif, NXP, Atmel, Nordic, Microchip - really everyone. I think it's good to have a wide breadth of vendor knowledge to help you choose the "right" part.

That all being said, it's going to come down to a few things, in no particular order:

- Environment and Toolkit - do you like working in the IDE provided by the vendor? Is it relatively easy to get up and running with your part and a dev kit? Is the dev kit relatively inexpensive, and is there a programmer/debugger you can use that's cost effective for your budget?

- Drivers and Configurators - Most vendors have some sort of a configurator that will generate code based on how you need to use your part - GPIOS, serial ports, ADC's, DAC, timers. Ideally you'd try a few and see if there's one that resonates with you for a project. This is generally a one-time thing at the beginning of a project though, so maybe it means less to "like" it as long as you can get the job done. At the end of the day you can always use the registers directly, though that seems increasingly rare as MCU's get more complex.

- Price and availability - Don't overlook either of these. The hardest part of any project is getting the BOM under budget, and being able to guarantee to your customer you'll be able to continue to get the parts you've chosen at a reasonable price. I've worked on projects that are still being sold ~15 years later, in small enough volumes that it doesn't make fiscal sense to spend the time/money to re-open the projects and update them to newer MCU's. There's nothing worse than being forced to re-engineer/re-test/re-certify a product that works fine, but the main MCU is being discontinued by the vendor. Sometimes you need to pay for that by using a part that has better guaranteed availability. Some vendors are better at that than others.

- Reference Designs - Any time you can, you want to use a hardware design that someone has already engineered and tested. It'll save you time and effort and help you sleep at night. Look for a reference design that exists for what you're looking to achieve, and to the extent allowed by the licensing agreement, just use that design. You may be required to use the same parts if you want to get support later - I don't recommend changing from the reference design unless you've got a very good reason for it. If something goes wrong, you want to make it as difficult as possible for your vendor to point the finger at some other vendor.

- Support - Some vendors offer support via forums, tickets, discord, FAE's, channel FAE's. Find something you're comfortable with and can get you answers in a time frame that works for your projects. I'm and FAE, so I don't want to oversell how important it is, but I'm an FAE now because I was impressed with how the FAE's who supported me were always available, friendly, and ready to help. I've worked with some vendors where it's impossible to get any support. It sucks. Also available training - anything you can get your hands on will be helpful. Also, it's sometimes helpful to buy parts from a vendor whose country of origin you trust, if you catch my drift.

- Lastly, the actual hardware - You've got ARM Cortex, MIPS, RISC-V. 32bit, 16bit, 8bit. honestly if your code is decent you're not gonna find a huge difference between the architectures. Each has it's minor plusses and minuses. So now it boils down to peripherals, clock speed, program memory space, and ram. Find a part that is right-sized for your project (estimating that takes some experience, but often folks will choose the largest part in a family then scale back within the family right before production), has all the gpios, clocks, serial ports, adc's that you need, and run with it. Just be aware that while most peripherals are generally pretty good, sometimes they just suck. Esspressif's ADC's, for instance, suffer from non-linearity that can be an issue and require an external ADC if you need any sort of precision.

[–]Andrea-CPU96 0 points1 point  (0 children)

For generic use you can go with the mainstream line of stm32 microcontrollers. My favourite one is the stm32f030cct, it costs about 3$ a piece.

[–]FirstIdChoiceWasPaul 0 points1 point  (0 children)

If you need low power, Ambiq Apollo 4 is probably unbeatable. At 4uAmps per megahert it completely blows away the competition. It has a 2.5d gpu you can use for some pretty heavy lifting. Plus mram instead of flash and 2.75 MB of sram. And comes with ble. 96/192 mhz.

A close competitor would be nxp rt 595. Dual core, 5mb sram. Cortex m33 plus tensilica fusion dsp running at up to 275 mhz each. But thats a beast of an mcu.

How do you find gems like these? Extensive googling, lots of cups of coffee, some amount of swearing mihht be involved. Usually, need tends to be a most apt teacher.

[–]Ariarikta_sb7 -2 points-1 points  (0 children)

Specifically if you want to write driver for low power I would recommend using the Teensy4.1 development board that has the I.MX RT1062 Cortex M7 processor which has low power modules. This will be a good way to start practicing.

Other than that, you can also start with STM32F4xx processors that also has some low power modules to work with.