4 ms·

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

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

monocasa 6y ago
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.
- emilfihlman 6y ago
  >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.
  - monocasa 6y ago
    > 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.
  - IndrekR 6y ago
    > 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.
- jotux 6y ago
  >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.
  - monocasa 6y ago
    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.
scruple 6y ago
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.

monocasa 6y ago

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.

emilfihlman 6y ago
>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.
- monocasa 6y ago
  > 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.
- IndrekR 6y ago
  > 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.
jotux 6y ago
>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.
- monocasa 6y ago
  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.

scruple 6y ago

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.