5 ms·

>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

>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.
    - scruple 6y ago
      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.
      - ducktective 6y ago
        > 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?
        pantalaimon 6y ago
        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.
        user5994461 6y ago
        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.
        sgtnoodle 6y ago
        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.
jotux 6y ago
>>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).
deleted 6y ago
[deleted]

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.
  - scruple 6y ago
    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.
    - ducktective 6y ago
      > 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?
      - pantalaimon 6y ago
        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.
      - user5994461 6y ago
        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.
      - sgtnoodle 6y ago
        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.

jotux 6y ago

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

deleted 6y ago

[deleted]