Hacker News Reader

> there's no screen on a microcontroller so printf("hello world") does nothing

Unless printf() is ultimately hooked up to some text-capable interface, like a UART with a terminal on the other end. :) Although I will agree that in general this isn't a typical use case for embedded microcontrollers in the real world.

I'd say a lot of UARTs are running debug consoles, but you don't want that for a hello world typically because it can be pretty complex to initialize when the whole point of a hello world is to get something happening with the minimum of setup.

The UART will have pin config, the clock tree, and the UART itself that all need to be initialized, and can be finicky when setup incorrectly (particularly the clock tree).

Blinking an LED with a busy wait loop square wave is way simpler and gives you externally visible code execution with less that can go wrong than printing to the UART.

>Blinking an LED with a busy wait loop square wave is way simpler and gives you externally visible code execution with less that can go wrong than printing to the UART.

Yeah, but everyone doing professional embedded work uses a proper debugging tool to load that LED code. "Externally visible code execution" is just when the code hits the reset breakpoint and you start stepping through the code.

You'd be surprised how often there's a difference between the debug load tooling and boot from regular flash. That leaves you with code that loads just fine over JTAG, but can't boot just from poweron. Stuff like if your code runs out of SRAM, maybe the clock tree looks totally different depending on how it loaded the code.

Once you get much past that point you want your team to use an OTA update mechanism as much as possible during normal development so that it has a ton of cycles on it by the time it ships.

>I'd say a lot of UARTs are running debug consoles

You are already assuming RTOS/Linux with this.

UART is easy to initialise on about all platforms. On an AVR you you don't even have to think about configs or clock trees.

UART is one of the best ways to debug and vastly superior to just blinking a led.

> You are already assuming RTOS/Linux with this.

> UART is easy to initialise on about all platforms. On an AVR you you don't even have to think about configs or clock trees.

I'm assuming fairly standard microcontrollers, but yes, from my experience as a lead for a proprietary RTOS that I ported to dozens of boards.

I'd say that AVR is the outlier here. Nearly every more complicated core has clock configuration that's finicky and needs to happen to bring the UART up. Blinking an LED just needs a couple writes to PINCONFIG and GPIO blocks and a busy wait loop that isn't optimized out.

> UART is one of the best ways to debug and vastly superior to just blinking a led.

It is once you've validated that code execution is actually occurring.

> UART is one of the best ways to debug and vastly superior to just blinking a led.

A proper debugger, and if the platform allows, a tracer are the best ways to debug/profile code on an MCU.

It's been a long time since I was in embedded. At the time, logic analyzers were expensive and we only had a few that were permanently housed on the Grey Beards desks. I used to read UART off an Oscope for debugging. Learned a lot in that job.

>as a professional embedded developer.

>there's no screen on a microcontroller so printf("hello world") does nothing.

I'm going to take a very straight jab at you here and say that even if you are working professionally, it's in a very specific and not general way and you have been doing the same thing for quite some time.

As another commenter already mentioned, it is the most basic of things to have printf go to UART and to your monitoring terminal, and actually it tells us a lot that you are assuming that printf goes to a display on the device of all places! And that there can't be a screen on a device.

>>there's no screen on a microcontroller so printf("hello world") does nothing.

The article is specifically about ARM Cortex-M4s, which support semihosting. So most of the tools listed in the article will just automatically spit printf out to the semihosting console without any effort.

Even if there isn't semihosting on a platform, the first thing I almost always do with board bring-up is pipe printf to some debug port (uart, ethernet, usb, etc).

I think there's been one project I worked on that had a UART hooked up to printf, usually the pin+code overhead didn't make sense.

LED or Logic Analyzer are usually where I lean before reaching for printf.

A robust console-like system to capture when "interesting things" happen is an incredibly valuable tool to have for any complex embedded project. When you have hundreds or thousands of something in the wild, you can't rely on always having a logic analyzer connected when something anomolous happens.

Often times, a UART is just one of many sinks for console-like data. You might direct messages to nonvolatile memory for logging purposes, over a network link for remote diagnostics, or a display if you have one.

If you're running Linux, then you get that for free more or less. If you're running bare metal, then you usually have to build it yourself. It's always worth it.

Look, I'm not knocking printf, for larger systems it's great.

However you're just not gonna spin up a UART debug console for an ATTiny, I've seen printf take ~2k of flash which would be 1/4 of your total storage gone.

If you're reaching for Linux you're already on the edge of the domain space that most microcontrollers occupy.

I used to spend so many off-work hours on my custom printf functions to try so desperately to find optimizations to save on space. I got it down to, IIRC, ~1300 bytes on a PIC8 and ~1500 on an MSP430. I left embedded because the pay:work ratio was shit (compared to backend / web development) but damn do I ever miss that work.

> pay:work ratio was shit (compared to backend / web development)

This is my current dilemma. Does this fact still hold? And will it hold in near future?

In terms of pay/work ratio, it might always hold true that it trends lower for embedded work. For individuals, though, I think the variation is a lot higher.

In my personal experience, there's a huge demand for experienced embedded software engineers in the bay area, and companies are willing to pay competitively. The team at my current company has grown from just me to a dozen embedded engineers, and we have several open positions for more. When I worked at Google, I'm pretty sure the embedded software folk had above average total compensation compared to general software engineers.

I think a big part of it, though, is that embedded engineers in silicon valley tend to get pulled into longer term high capital expense projects. The compensation packages tend to be more equity than salary, and so the salary component is below average. You need to be willing to take the risk to get the upside.

From what I hear from friends in the midwest, the compensation is significantly lower than the difference in cost of living, which is unfortunate. Salaries may be above average, but without much if any equity.

Another part of it, I think, is the sheer amount of interdisciplinary and domain specific knowledge required to be a truly strong embedded software engineer. The demand curve is very heavily biased toward senior level engineers. The companies with the money to spend want the best, and with such high capital expenditure projects, they can't really afford not to.

I don't think it ever held as a fact, it's really dependent on location.

If you compare web developer at FAANG to a random embedded developer, of course embedded is a joke. (A better comparison might be workers at Intel/AMD and I don't think they are terribly treated).

If you compare jobs in another city/country, maybe a city that has a bit of defense or aerospace industry, embedded is not necessarily that bad compared to other tech jobs available.

Yes, but this is true for many fields. Work that is 'more fun' tends to be payed worse since people actually like to do it.

> just not gonna spin up a UART debug console for an ATTiny

That's really an argument to design a dev system with more resources than the final target and do most development on that.

Well yeah, if you're using such a simple MCU that you're basically writing assembly whether or not you have a C compiler, you aren't going to end up with something complex enough to need console-like logging. At that scale, you can more or less exhaustively test every code path and input to prove correctness.

You don't have to go too far from there to benefit from a debugging console, though. There's tons of design space between 8-bit 8-pin MCUs and full featured processors with MMUs and megabytes of memory. You don't even have to leave 8-bit to benefit from a "printf" mechanism.

Tangentially, you don't necessarily need to implement "printf" within an embedded firmware to benefit from it. It's entirely possible to offload the fmt string expansion, instead capturing the raw fmt string and arguments as data and expanding it at point of consumption.

I don't believe I said at any point that printf isn't useful, there's just reasons why you don't use it.

Heck, even on the PSP which had a fair amount of horsepower console logging was a blocking read and we avoided it unless necessary because it would throw off all sorts of timings(and drive the frame rate in the toilet).

In the microcontroller space, 2/3rds of what I'm debugging is cycle timing sensitive. I2C or SPI sequencing and there having a logic analyzer that I can cross-correlate with actual external signals is so much more useful. They've gotten cheap enough these days that it is sometimes just easier to connect one to a spare pin and toggle that pin based in the internal state I want to track.

I don't think the author explicitly said it until the end of the article, but this comparison is only looking at the setup process. I thought it was a wellwritten article so hopefully he continues on with the series and hits some of the points you mentioned