Microcontroller Programming
Microcontrollers vs. Microprocessors: What's the Deal?
We get this question a lot. So here’s the quick breakdown:
- Microprocessors are the muscle behind your laptop, smartphone, and other multitasking machines.
- Microcontrollers are the brains inside simpler, purpose-built devices such as thermostats, garage door openers, or that motor controller in your industrial rig.
Microcontrollers are cheaper, smaller, and often trickier to program because you’ve got less memory and processing power to play with. But that’s our sweet spot. We’ve worked with everything from dirt-cheap 8-bit chips to full-blown processors running Linux.
Whether you’re building a no-frills sensor node or a complex embedded system with multiple layers, we can help you pick the right processor—and make it do exactly what you need.
Microcontroller Platforms We Work With
We’ve worked with STM32, Nordic nRF52, Microchip PIC, Atmel, and TI parts, among others. The platform you choose is not a huge sticking point for us. That is a choice driven by your product needs, the costs to run at whatever your planned volume is, and it relies heavily on the availability of the chosen platform within a reasonable lead time.
If you already have an idea of which chip you want to work with, let us know, but if you don’t, we are happy to help you figure out the one that works best for your needs.
Custom Microcontroller Programming That Hits the Mark
We’ve worked with everything from bare-metal 8-bit MCUs to beefier chips running complex stacks. Whether you’re building a low-cost sensor node or a more advanced system, we know how to make the firmware fit the hardware—and the budget.
What We Build With Microcontrollers
- Motor Control: Tight, predictable motor behavior. No surprises, no jitter.
- Sensor Integration: We connect your device to the real world. Position, motion, temperature—you name it, we’ve probably worked with it.
- Low-Level Optimization: We squeeze performance out of even the smallest chips. If it needs to run lean, we’re the ones to call.
Common Microcontroller Programming Mistakes We See
The most expensive mistakes happen early, not late. One of the most common expensive mistakes is picking a chip out of habit rather than the one that fits your project. Using a chip that your team has worked with before may be comfortable, but if it’s the wrong size, price, or specs, you will be hurting six months into the project.
Another expensive mistake we often see is treating firmware as an afterthought to hardware. The two should not be designed separately; they work best when designed simultaneously, with decisions made while considering both sides.
These kinds of early tradeoffs are things we look for and flag for your team while they are still easy and cheap to fix.
Why Work With EES?
We don’t just drop in code and call it done. We take time to really understand what your product needs to do and how the firmware fits into that bigger picture. Over the years, we have found that a little extra thought up front saves time and eliminates headaches later.
So whether you’re working on a basic device or a one-of-a-kind system, we’ll help you get the firmware right, and get your product out the door.
Let’s build something solid.
FAQs
When does a project actually need a microcontroller versus a microprocessor?
If your device has one focused job - controlling a motor, reading sensors, managing a display - a microcontroller is almost always the right call. Microcontrollers are cheaper, lower power, and purpose-built for deterministic embedded tasks. Microprocessors make sense when you need a full OS, a rich UI, or heavy data processing. The gray area is where things get interesting: some projects start as simple MCU designs and grow into something that needs more horsepower. We help you make that call early so you're not re-architecting six months in.
What microcontroller platforms does EES work with?
We've worked across the spectrum — from 8-bit PICs and ATmega parts to 32-bit ARM Cortex-M devices from ST, Nordic, Microchip, Texas Instruments, Infineon, and Espressif. We're also comfortable with Linux-capable platforms like Raspberry Pi and the Xilinx Zynq series when a project grows beyond what a bare-metal MCU can handle. If you've already chosen a platform, we work with it. If you haven't, we'll help you pick the right one for your power budget, BOM cost, and timeline.
What is bare-metal firmware and when does it make sense over an RTOS?
Bare-metal means writing firmware without an operating system — you control the hardware directly, manage interrupts yourself, and there's no scheduler overhead. It's the right call for simple, cost-sensitive, or extremely latency-sensitive designs where adding an RTOS would be overkill. An RTOS makes sense when a device needs to handle multiple concurrent tasks — sensor reads, cloud communication, user input — without one blocking another. We've shipped both. If you're not sure which your project needs, that's a question worth answering before you write a line of code. See our RTOS Integration page for more on that side of the work.
How do you approach motor control firmware — what does "tight, predictable behavior" actually mean?
It means the motor does what you tell it, when you tell it, every time — no jitter, no overshoot, no lag that shows up six weeks into field use. In practice that comes down to interrupt timing, PID tuning, encoder handling, and making sure the control loop doesn't get starved by other firmware tasks. We've done brushed DC, BLDC, stepper, and servo applications across industrial and consumer products. The work is in the details — getting the math right, validating on real hardware under load, and testing edge cases before the product ships.
What does low-level optimization look like in practice?
It usually means one of three things: reducing flash and RAM footprint so your code fits on a cheaper part, cutting execution time so critical loops meet their deadlines, or reducing power consumption so a battery lasts the expected product lifetime. The approach depends on where the problem is — sometimes it's algorithmic, sometimes it's peripheral configuration, sometimes it's compiler settings and linker scripts. We start with measurement, not guesswork. Profiling the actual bottleneck before touching the code is what separates a clean optimization pass from one that wastes time on the wrong thing.
Can EES work with an MCU we've already selected, or help us choose one from scratch?
Both. If you've already committed to a platform — either from a previous project, a supplier relationship, or a cost constraint — we work within that choice and make the firmware fit. If you're starting fresh, we'll go through the requirements with you: processing load, peripherals needed, power budget, cost target, supply chain availability, and development toolchain. Picking the wrong MCU early is one of the more expensive mistakes in embedded product development. A short architecture conversation at the start of a project is worth it.
How do I know if my product needs an 8-bit, 16-bit, or 32-bit microcontroller?
This answer comes down to what your firmware is going to need to do, and how much potential for new features you would like to have. You can get away with an 8-bit part for a simple, fixed function device, and you should use a cheap part to keep costs down. But once you move on to anything with a display or wireless connectivity, that more complex logic is likely going to require something with more processing power and memory, like a 32-bit chip. This is why we size our design to your actual requirements, never a default chip.
Do you write firmware in C, or do you use higher-level languages?
Most of our microcontroller work is in C, because it gives us tight control over the hardware without sacrificing the flexibility needed for bigger system integration. Where a project calls for something else, we'll use it.
How involved do we need to be in the hardware if we're only hiring you for firmware?
We can be as involved as little or as much as is necessary for the project needs. We will work from your existing schematics and board design, and flag potential hardware issues as we find them. If it makes the firmware harder or less reliable, we will let you know, but the final decision on what to do about it remains yours.
What's a realistic timeline for microcontroller firmware development?
It depends on the project. Generic estimates are not particularly helpful in firmware development, because the scope of each project can vary so widely. Creating a single motor-control routine is very different from a full sensor-fusion and connectivity stack, and they take vastly different amounts of time to build properly. At EES we give a specific estimate for your project once we understand the requirements you need us to complete, so we can be more accurate from the get-go.
Not sure which microcontroller fits your product, or want a second opinion on firmware that's already underway?
Talk to a senior engineer. Start with a Scope It Right architecture session ($199, creditable toward future work) if you’re still picking hardware, or a Firmware Flaw Finder audit ($499) if code already exists and something isn’t right.