4 ms·

I'm surprised from this checklist because this checked almost none of what I would be looking for in a as a professional embedded developer. What I would like

I'm surprised from this checklist because this checked almost none of what I would be looking for in a as a professional embedded developer. What I would like to see: How easy to push the software from the computer to the microcontroller? Preferably you should be able to push the firmware over USB or something like that in a few seconds. Don't mind whether that's a command line tool or a button in the IDE but there has to be something and it MUST work. Is the tool friendly to source control? I had very bad experiences with embedded tools automatically creating hundreds of files all over the project and editing them on every build, causing a massive headache to store the project in source control. Note that software developers expect their development tools to support source control natively but I have no illusion of that happening in embedded IDE. How easy to make a simple software and how is the documentation? For reference the basic in EE is to blink a LED, the microcontroller should provide API with documentation and examples to do that (and much more). It's shocking how many MCU have zero doc and the little there is doesn't work. Personal note: It's funny the author wants to compile a hello world because that's not a thing in embedded, there's no screen on a microcontroller so printf("hello world") does nothing. Last. I'd like to know about debug capabilities? Can you connect the computer to the MCU and debug directly on the device? Ideally there should be a full debugger including breakpoint support and step by step execution and displaying all local variables. The debugger should also be able to show debug output from the microcontroller (output from printf or equivalent).

ls65536 6y ago
> 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.
emilfihlman 6y ago
>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.
- vvanders 6y ago
  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.
  - sgtnoodle 6y ago
    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.
    - vvanders 6y ago
      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.
Rebelgecko 6y ago
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

ls65536 6y ago

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

emilfihlman 6y ago

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

vvanders 6y ago
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.
- sgtnoodle 6y ago
  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.
  - vvanders 6y ago
    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.

Rebelgecko 6y ago

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