5 ms·

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 ~

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

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.

sgtnoodle 6y ago

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.

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

Gibbon1 6y ago

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