Question of the Month: What’s the most frustrating part of working with modern micro-controllers?

I use a lot of Pi Picos, some Arduinos (Pro Mirco, MKR, Uno R4) some ESP32's and sometimes PSoC4's

I'm probably very old lol
But I never used anything more than 8051 and AVR. Stopped using MCUs/ doing embedded systems projects as the newer MCUs got more and more complex with complicated IDEs and difficult to read documentation. I still have a couple of different 8051s with me. 

What is more surprising is projects using ARM, STM32 to make LEDs, 7seg displays, clocks, etc. Most hobby based projects can still be done with AVR /Arduino Uno but even Arduino has ventured into high end MCUs but the applications, more or less remain the same (hobby projects without need of much computational complexity). Bit of an overkill to use ARM for blinking a few LEDs and need to go through lot of pain to get it working. 

I remember my last project was the gesture sensing kit from Maxim Integrated. It used Keil IDE and mbed OS. Spent days and lots of discussions in the forum on how to install mbed OS and get it working.  

It's been interesting to look at the replies so far.

I do design work with small embedded processors both commercially and for entertainment.

Most of my designs are based on ARM Cortex micros from ST.

I sometimes buy dev boards but often don't use them at all because I design my own boards. The dev board is insurance in case my own design won't work and I need a functional board in a hurry as a reference.

While its true that for some purposes I could get away with and 8 bit micro the money saved is trivial compared  with the design time and prototype parts costs. If the design will be made in large numbers a non ARM micro might be a good choice but I haven't had a commercial project where that has been the case for a long time.

I have used ARM micros from Giga Devices and NXP but I much prefer the ST range. 

One of the nicest modern ARM micros is the STM32U575 - floating point, 160MHz clock, 784kRAM, 1 or 2Mbyte FLASH, Cordic Processor, Filter accelerator, 14 bit ADC and loads of other stuff. 48 pin LQFP if you like (bigger packages are available), very low power. About £5 for one.

Having mentioned the STM32U574 family, my current non commercial project is based on an ST32G0B1, slower and cheaper. It has enough 5V tolerant IO to be able to interface with a 5V LCD display while the rest of the logic and the processor use 3.3V.

The board plugs onto the back of the display. This is one I used to check the 5V LCD interface so it didn't get a fancy audio chip to blow up - although as things turned out it would have been OK. It can work with either a 4 x 40 or a 4 x 20 character LCD.

My toolchain gripe is that although ST's documentation and support is about as good as it gets (and way, way ahead of Giga Devices, Espressif or RPie Pico (IMHO of course)) they no longer supply a nice simple set of header files in standard C - so you have to use the Cube thing to generate a project which you can then edit into something decent.

The tool thing lock in works for suppliers because it increases the cost of changing to another brand quite significantly - so they won't stop doing it.

So I voted 

cstanton said:

Proprietary toolchains and IDE

as my pet gripe.

MK

michaelkellett said:

I much prefer the ST range

for the (good) hardware, or for their (good) API?

michaelkellett said:

So I voted 

cstanton said:

Proprietary toolchains and IDE

as my pet gripe.

I get that. I don't mind it that much. I prefer to adapt to the manufacturer's development environments. I knows you prefer to use controllers in your (very good) single IDE.
I think that both options are viable. And neither of them is an easy choice.

Also a reason why companies tend to stick to one family. But that has its dangers too.

Both - but mainly the hardware.!

I don't much like the API (HAL in ST speak) but the basic hardware documentation is good.

MK

My answer to this one is a bit complex.  There are many factors effecting my processor choices. Through the years I have been in a position to select processors for a wide variety of products over a wide variety of fields.  I have worked in the development of electronics and software for military, consumer, medical, security, avionics and several other fields.  Each of these fields stress unique selection criteria for these processors.  I have selected processors of widely different classes, including RISC, DSP and small, medium and large microcontrollers.  Here are a few of the issues that I have faced in selecting and working with processors.

1. Poor or inconsistent documentation - Many of the most difficult issues were based on the quality of the available documents. I have had issues with overly complex, missing or incorrect or a total lack of documentation.
2. Proprietary toolchains and IDES - This to has been a difficult area to deal with for me. There have been cases when the necessary tools were so expensive that we were forced to move to a different processor or make do with poor tools and difficult development and debug processes.
3. Supply chain issues / availability - This has been a more recent issue for me lately, and not just due to the Covid problems. Some vendors have had issues were a processor just pain is not available as they change their fabrication processes or plants.  In recent years the former Atmel part, Atmega328PB processor was not available due to issues with MicroChip processes or priorities.  I needed to acquire processors for other than normal vendors, including some vendors of old or excess stock.  As scary as that was for me, in the end it all worked out.
4. Not enough functionality - There have been times when a processor became overwhelmed by ever increasing requirements, due to software updates and added features. I tend to be a bit of a snob in this area, taking the standpoint that there are no bad processors, just bad programmers.  I have taken many underperforming processors and brought them back into compliance by optimizing the code and fixing bottlenecks or poor programming practices.
5. Configuration complexity - This is area that continues to make it difficult to adopt some newer processors into some of my designs. There have been processors that are so complex, that I am not able to fully understand a path forward with them.  Some of this just might be my own issues with "way too many choices" and poor documentation or tools don't that allow for a quick and simple setup, which could then be later changed as needed to take advantage of some of the more complex features.

Given these issues, and many others, I have chosen to stay behind the bleeding edge of new processors.  I also have chosen to work almost exclusively within the offerings of single vendor.  I find that I can share code and hardware designs across a large variety of projects, by using a single processor vendor.

I currently have several active designs based on MicroChip's AtMega and AtTiny parts.  I used the AtMega328PB chip in most of designs and the AtTiny (either 16xx or 32xx parts) as co-processors or standalone processors in some of my smaller designs (either boards smaller than 1 sq in or in designs that are not that complex).

The rapid pace of change. When one becomes familiar with one microcontroller family another pops up!

PSoC Rocks! (Although I'd like them to have many more programmable digital blocks)

Zilog Z8 Encore XP is cool!

Zilog eZ80 Acclaim for those Z80 diehards.

Rockwell R6511AQ for those 6502 diehards.

What I find the most difficult is just the learning curve.

I have been programming microprocessors since they came out and have worked with some really primitive development capabilities.

The new environments have too much complexity.

Keep it simple, keep all of the options in the background for the power users to dig into.

Most of us just want a clean and easy way to go from an idea to testable code.