Hacker News Reader

Comment by ls65536 | 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.

View on HN

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.

>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.

>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.

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.

Reply on news.ycombinator.com