#stm32

Building an electronics project often starts with a simple question:

Which microcontroller should I use?

Choosing a microcontroller is one of the first decisions you need to make when starting an electronics project. Whether you are building a simple LED controller, a robotic system, an IoT device, a battery-powered sensor, or a more advanced embedded product, the microcontroller sits at the center of the system and determines what your project can and cannot do.

The challenge is that there are hundreds of microcontrollers and development boards available today. Arduino, ESP32, Raspberry Pi, STM32, and many other platforms all have their own advantages. Some focus on simplicity, some on wireless connectivity, some on low power consumption, while others are designed for high-performance embedded applications.

So how do you know which one is right for your project?

The answer isn't to choose the most powerful board.

The right microcontroller is the one that matches your project's actual requirements.

Start With Your Project, Not the Microcontroller

One of the most common mistakes beginners make is choosing a microcontroller first and then trying to design the project around it.

A better approach is to start by understanding what the project actually needs.

Consider a simple temperature monitoring system. It may need to read a temperature sensor, display the measurement on an OLED, and occasionally store the data. Such a project doesn’t require a powerful processor or a large amount of memory. A simple microcontroller can handle the job comfortably.

Processing power matters, but more isn't always better.

A simple automation project doesn't need a high-performance processor. On the other hand, applications involving networking, audio, graphics, complex calculations, or advanced motor control may require a more capable MCU.

For example, the classic Arduino Uno is built around the ATmega328P and operates at 16 MHz. That's more than enough for countless beginner and embedded projects.

If your project requires considerably more processing power, platforms such as ESP32, Raspberry Pi Pico 2, or STM32 provide more capable options.

Don't Forget GPIO Pins

GPIO pins connect your microcontroller to the rest of your circuit.

Every sensor, LED, button, motor-control signal, display, and communication device can consume one or more pins.

A project may look simple initially, but once several peripherals are added, you can quickly run out of available GPIOs.

And remember: the number of pins on a development board isn't always equal to the number of pins that are freely available. Some pins may have special functions or hardware limitations.

It's always worth checking the pinout before choosing a board.

What About Wi-Fi and Bluetooth?

If you're building an IoT or wireless project, connectivity can be one of the biggest factors in your decision.

An ESP32 is a popular choice because it combines microcontroller capabilities with Wi-Fi and Bluetooth/Bluetooth Low Energy.

That makes it useful for projects such as:

Smart-home devices

Wireless sensors

Remote monitoring

IoT systems

Bluetooth controllers

Connected robotics

But if your project doesn't need wireless connectivity, there's no reason to choose a more complicated MCU simply because it has Wi-Fi.

Memory Matters Too

Two specifications that are easy to overlook are Flash memory and RAM.

Flash is primarily used for storing your firmware, while RAM is used while the program is running.

Simple projects may work perfectly with a small amount of memory. But applications involving displays, networking, large data buffers, audio, or complex software can quickly require more RAM and Flash.

Don't just ask whether your program fits into Flash. Make sure there is enough RAM for everything your application needs to do while running.

Consider Communication Interfaces

Your microcontroller will probably need to communicate with other components.

I²C is commonly used for sensors, OLED displays, RTC modules, and similar peripherals. SPI is useful for faster devices such as TFT displays, SD cards, and Flash memory. UART is widely used for serial communication, debugging, GPS modules, and communication modules.

Some projects may also require USB, CAN, Ethernet, or wireless communication.

If your project depends on a specific interface, check that the MCU actually supports it before designing around the board.

Power Consumption Can Be Critical

For a project powered from a wall adapter, power consumption may not be a major concern.

For a battery-powered device, it's a completely different story.

If you're building a wireless sensor, wearable device, portable data logger, or remote monitoring system, you need to consider active current, sleep modes, wake-up capabilities, and the power consumption of the entire system.

The microcontroller is only one part of the equation. Sensors, displays, regulators, LEDs, and communication modules also consume power.

Arduino vs ESP32 vs Pico vs STM32

There isn't a universal winner.

Arduino is an excellent choice when simplicity, learning, and rapid prototyping are priorities. Its huge community and library ecosystem make it especially beginner-friendly.

ESP32 is a strong option for IoT and wireless applications where Wi-Fi or Bluetooth is required.

Raspberry Pi Pico and Pico 2 are compact and capable platforms for embedded control, robotics, sensor projects, and other microcontroller applications.

STM32 covers a huge range of microcontrollers and is particularly attractive for more advanced embedded systems, industrial applications, motor control, and applications requiring sophisticated peripherals.

The best choice depends entirely on what you're building.

Don't Choose Only by Specifications

It's tempting to compare clock speed, RAM, Flash, GPIO count, and price and simply choose the board with the biggest numbers.

But real-world development involves much more than specifications.

Consider the development environment, libraries, documentation, debugging tools, community support, component availability, and long-term supply.

A microcontroller that is slightly less powerful but easier to develop with and readily available can be a much better choice than a technically superior MCU that creates unnecessary complexity.

A Simple Rule to Remember

When choosing a microcontroller, ask yourself:

What does my project actually need?

How many GPIOs?

How much memory?

What communication interfaces?

How much processing power?

Does it need Wi-Fi or Bluetooth?

What voltage does it operate at?

Does it run from a battery?

How important are cost and availability?

Answer these questions first, and the right microcontroller will usually become much easier to identify.

You don't need the most powerful microcontroller. You need the right one for the job.

I wrote some code, the way i usually like by making references to datasheet chapters etc. Everything was going well but the card did not work. I knew it was ok since it worked when plugged to my PC, but it was not responding to my init commands over SPI.

I googled and googled but nothing seemed to work. I tried my no-name logic analyzer but for some reason linux didnt recognise it - it used to work a few years ago but no more i guess.

Eventually i decided to check all the data that is being transmitted to the STM32 chip by changing all the writes into read/writes. Turns out MISO line was high all the time, non stop. This activated some alarm bell in me since it looked like an electrical error.

Eventually i found some random thread about arduino with what seemed to be a similar problem. What i did not mention is that SD cards work with 3.3v (afaik) which is not a big deal since stm32 also works on 3.3v. Sometimes one might want to plug them into a 5v circuit though and to accommodate that, the board i bought contained a voltage level regulator type of chip forgot the name. Essentially converter between 3.3. and 5v signals.

Apparently, in some cheaper no name modules like mine, this type of chip bugs out and keeps on holding the MISO line high despite the fact that SD card has let it go long time ago. This sounds like exactly what is happening to me.

Solution? Glorious:

Bypass the voltage converter. 3.3v should still be considered high state even by 5v circuits, so it should work.

I appreciate the random person who just bumped into a random thread after 2 years of inactivity and just dropped this knowledge. These folks are the backbone of the internet and im glad to have been in his position once or twice myself.

I myself did not feel like soldering that wire, especially since the pad on the socket is super small and these modules are very cheap. Since STM32 works on 3.3v anyways, and atmegas also have low voltage versions nowadays i decided to just buy another module which has no additional ICs on it - no voltage regulators, converters etc, just plain SD card socket and routed connections, maybe a resistor or two.

Funny thing in the end, but also kind of irritating, since it took me long enough to finally sit down and start tinkering with this stuff. Also it might turn out there's a different problem at play and i just bought some more electrojunk for no reason. But then again, i put some more sensors and SPI fun stuff into the basket when i was orderign the new module, so there's always new stuff to look forward to.

Don’t use the Raspberry Pi 2040 to build a DCC decoder.

It’s not really wrong, of course, and it gives you ridiculous amounts of computing power, but to get that you need miles and miles of extra components. Like a dozen of decoupling capacitors, an external oscillator, and of course an external flash memory. You can maybe do that sort of thing in H0, but for real model trains, it’s just not ideal. Pick something like an ATTiny or STM32C0 (I’ve done both for different projects): Cheap, just one or two decoupling capacitors, no external oscillator required and no external flash memory needed either.

The versions of the RP2350 with built in memory may be a better idea, once they fix the GPIO issues anyway, but still, there’s the oscillator and just way too many capacitors.

(Some of these concerns may be different if you want to add sound support, which requires more memory anyway. But I’d argue that sound in model railroads is a mistake anyway. I’ve never seen an N scale locomotive that sounds good, it’s all just an annoying expensive gimmick.)

Also while we’re at it, don’t use a cheap standard bridge rectifier. The steep slopes of the DCC signal mandate a really fast rectifier, typically Schottky diodes. This is particularly important when you have RailCom on your layout. You may need four individual diodes instead of one rectifier, but since you won’t need all the capacitors of the RP2040, you still win out in the end (it’s also typically smaller than the rather large SMD standard rectifiers).