7 ms·

Having spent a decade building embedded C, its refreshing to see that I'm not the only one who sees the value in doing things well. Every single one of the ste

Having spent a decade building embedded C, its refreshing to see that I'm not the only one who sees the value in doing things well. Every single one of the steps here, though they may seem excessive provide immense value, not at first, but as the project grows, matures, and needs to exist for decades. I am rather surprised at all the negativity here. I assume that it's either few of the people commenting have worked on embedded systems, or the few that do do not have an appreciation for maintaining a large project for the long term. Attitudes like I'm seeing expressed here are reinforcing my desire to get away from embedded, or at last work with people that don't wish to stay stuck in the stone age. I'm not intending to argue here, just surprised and a bit sad at the reactions, and happy that some people, at least at memfault share my values.

randmeerkat 3y ago
> Attitudes like I'm seeing expressed here are reinforcing my desire to get away from embedded, or at last work with people that don't wish to stay stuck in the stone age. I hate to break it to you, but there’s the same problems on the SWE side too. The problem is never the stack, it’s the culture. If you’re tired of embedded, that’s fine, but remember to ask culture questions for your next position.
- manofmanysmiles 3y ago
  That’s disheartening, but not surprising. > remember to ask culture questions for your next position. I will definitely take that under advisement. Any places you recommend I look into?
  - randmeerkat 3y ago
    > That’s disheartening, but not surprising. Don’t be discouraged, it’s just life. > I will definitely take that under advisement. Any places you recommend I look into? Ask yourself what you want? What do you want in a leader? What do you want in a company? Be picky, be patient, if you can, maybe start something yourself. I wish I could tell you what would be the right fit for you, but I can’t. All I can say is don’t lose hope, but at the same time don’t expect too much either. We’re all just trying to figure out this thing called life, whether we’re embedded engineers, SWEs, or even sales for that matter.
Sakos 3y ago
I think the article is great too. There's a complete dearth of decent guides for how to setup a C/C++ environment with dependencies, including some sort of build system, and it's often been my biggest stumbling block. Everybody assumes you know how all this works and most guides are either way too basic ("just do make" like the comment below) or it's highly technical documentation that overwhelms anybody who isn't already familiar with C development.
- P_I_Staker 3y ago
  > There's a complete dearth of decent guides for how to setup a C/C++ environment with dependencies, including some sort of build system, and it's often been my biggest stumbling block. Disagree. I had to learn make for my first job. I found two ways to manage dependencies that are probably the most common, and the limitations. There really isn't a method that is perfect; I don't know if dependencies can be done (even outside of C) without occasionally rebuilding. The methods that I've seen rely on using the compiler to generate .h dependencies via the preprocess command. This can be done with gcc / cygwin for cross compilation, or with the native compiler. I'll explain. Method 1: the "better" method. Generate dependencies for your header files at make invocation, before compile step. This is more robust, but outside of very small projects, this can add a ton of time to the build. Method 2: the faster, more common method. Generate dependencies as a side effect of the build. When you compile, you use the previous dependencies. A new dependency file is generated for next time. They both have limitations. Method 2 can detect changes in the header files included from C files, but not headers included from H files. Method 2 can detect changes in header chain, but not all the time. I think it's the files that the headers include, those includes from that file don't get updated, but it's been a while since I've read the paper. Anyway neither method is that hard. You use gcc to generate dependencies for each file, then combine into one file (or you may create .d files, but for some reason a single file is common). That's it. Otherwise, add a step to compilation (some compilers may have a build in "byproduct" command). Every time you generate .c there's also .d. When you compile, you use the previous *.d file. Yes you need to know make, and this is an intermediate-to-advanced make task, but this is true for any build system! Entry level is a user that usually just adapts a build from the engineer experienced with the build system.
astrobe_ 3y ago
I spent more than a decade building embedded C/C++, never felt the need for any of that. But I was always able to keep things under my control; that is a GCC-based cross-compilation toolchain, my own makefiles do build stuff, and an editor I understand inside and out. When you are forced to use a proprietary IDE/SDK/compiler ball of mud, certainly that's a different story. I'd say if one has the sort of problems TFA says it addresses, then go for their solution. But if one does not see any problem a priori, then they should go for the simplest thing that could possibly work. One can always reconsider things later; but if one goes for that more sophisticated solution first, and then realize that it was actually not need, they've wasted their time - and perhaps introduced problems that would never had happened without. Don't be fooled by "modern" anything - too often it introduces new problems while solving old problems. "Stone age" can also mean battle-tested and rock-solid solutions.
crabbone 3y ago
> appreciation for maintaining a large project for the long term. Nothing author describes is applicable for a large project or a long-term project or both. He chose one of the worst editors available, and decided to incorporate it into environment setup. Any long-term or large project will have multiple people working on it. A fraction will find the crappy editor the author decided to use useful, but most will want something better. Most people with development experience will want to set up their environment in the way comfortable for them, this setup is asking you to jump through too many hoops, none of which bring any value. Same goes for CMake -- I've worked on multiple large C projects. None used an off-the-shelf build tool like CMake. These tools are inadequate for large-scale projects. (But, lets give the author credit here, he never claimed that his project was large or long-term). Still, I had never found CMake to be useful, nor for small nor for big projects. Whenever I had to work on a project that used CMake, it was a major pain. It is common to test stuff in containers during development. But, it's also more common the more lazy and less insightful the programmer is / intends to be. In my experience, better programmers usually set up their environment in such a way that they don't have to deal with the container nonsense, as it gets in the way of debugging and a bunch of other tools useful to interact / understand the program being tested. So... maybe containers for a smoke test. But, if you plan on going long term... that's just not going to cut it. You need a proper environment where you have comfortable access to your program.
hot_gril 3y ago
Having bounced around very different things a lot, the NodeJS community feels the nicest. It's not about flexing your tooling, flexing your lack of tooling, or dunking on other languages, it's about getting stuff done by whatever means necessary.
- shrimp_emoji 3y ago
  By importing leftpad
  - deleted 3y ago
    [deleted]

randmeerkat 3y ago

> Attitudes like I'm seeing expressed here are reinforcing my desire to get away from embedded, or at last work with people that don't wish to stay stuck in the stone age. I hate to break it to you, but there’s the same problems on the SWE side too. The problem is never the stack, it’s the culture. If you’re tired of embedded, that’s fine, but remember to ask culture questions for your next position.

manofmanysmiles 3y ago
That’s disheartening, but not surprising. > remember to ask culture questions for your next position. I will definitely take that under advisement. Any places you recommend I look into?
- randmeerkat 3y ago
  > That’s disheartening, but not surprising. Don’t be discouraged, it’s just life. > I will definitely take that under advisement. Any places you recommend I look into? Ask yourself what you want? What do you want in a leader? What do you want in a company? Be picky, be patient, if you can, maybe start something yourself. I wish I could tell you what would be the right fit for you, but I can’t. All I can say is don’t lose hope, but at the same time don’t expect too much either. We’re all just trying to figure out this thing called life, whether we’re embedded engineers, SWEs, or even sales for that matter.

Sakos 3y ago

I think the article is great too. There's a complete dearth of decent guides for how to setup a C/C++ environment with dependencies, including some sort of build system, and it's often been my biggest stumbling block. Everybody assumes you know how all this works and most guides are either way too basic ("just do make" like the comment below) or it's highly technical documentation that overwhelms anybody who isn't already familiar with C development.

P_I_Staker 3y ago
> There's a complete dearth of decent guides for how to setup a C/C++ environment with dependencies, including some sort of build system, and it's often been my biggest stumbling block. Disagree. I had to learn make for my first job. I found two ways to manage dependencies that are probably the most common, and the limitations. There really isn't a method that is perfect; I don't know if dependencies can be done (even outside of C) without occasionally rebuilding. The methods that I've seen rely on using the compiler to generate .h dependencies via the preprocess command. This can be done with gcc / cygwin for cross compilation, or with the native compiler. I'll explain. Method 1: the "better" method. Generate dependencies for your header files at make invocation, before compile step. This is more robust, but outside of very small projects, this can add a ton of time to the build. Method 2: the faster, more common method. Generate dependencies as a side effect of the build. When you compile, you use the previous dependencies. A new dependency file is generated for next time. They both have limitations. Method 2 can detect changes in the header files included from C files, but not headers included from H files. Method 2 can detect changes in header chain, but not all the time. I think it's the files that the headers include, those includes from that file don't get updated, but it's been a while since I've read the paper. Anyway neither method is that hard. You use gcc to generate dependencies for each file, then combine into one file (or you may create .d files, but for some reason a single file is common). That's it. Otherwise, add a step to compilation (some compilers may have a build in "byproduct" command). Every time you generate .c there's also .d. When you compile, you use the previous *.d file. Yes you need to know make, and this is an intermediate-to-advanced make task, but this is true for any build system! Entry level is a user that usually just adapts a build from the engineer experienced with the build system.

astrobe_ 3y ago

I spent more than a decade building embedded C/C++, never felt the need for any of that. But I was always able to keep things under my control; that is a GCC-based cross-compilation toolchain, my own makefiles do build stuff, and an editor I understand inside and out. When you are forced to use a proprietary IDE/SDK/compiler ball of mud, certainly that's a different story. I'd say if one has the sort of problems TFA says it addresses, then go for their solution. But if one does not see any problem a priori, then they should go for the simplest thing that could possibly work. One can always reconsider things later; but if one goes for that more sophisticated solution first, and then realize that it was actually not need, they've wasted their time - and perhaps introduced problems that would never had happened without. Don't be fooled by "modern" anything - too often it introduces new problems while solving old problems. "Stone age" can also mean battle-tested and rock-solid solutions.

crabbone 3y ago

> appreciation for maintaining a large project for the long term. Nothing author describes is applicable for a large project or a long-term project or both. He chose one of the worst editors available, and decided to incorporate it into environment setup. Any long-term or large project will have multiple people working on it. A fraction will find the crappy editor the author decided to use useful, but most will want something better. Most people with development experience will want to set up their environment in the way comfortable for them, this setup is asking you to jump through too many hoops, none of which bring any value. Same goes for CMake -- I've worked on multiple large C projects. None used an off-the-shelf build tool like CMake. These tools are inadequate for large-scale projects. (But, lets give the author credit here, he never claimed that his project was large or long-term). Still, I had never found CMake to be useful, nor for small nor for big projects. Whenever I had to work on a project that used CMake, it was a major pain. It is common to test stuff in containers during development. But, it's also more common the more lazy and less insightful the programmer is / intends to be. In my experience, better programmers usually set up their environment in such a way that they don't have to deal with the container nonsense, as it gets in the way of debugging and a bunch of other tools useful to interact / understand the program being tested. So... maybe containers for a smoke test. But, if you plan on going long term... that's just not going to cut it. You need a proper environment where you have comfortable access to your program.

hot_gril 3y ago

Having bounced around very different things a lot, the NodeJS community feels the nicest. It's not about flexing your tooling, flexing your lack of tooling, or dunking on other languages, it's about getting stuff done by whatever means necessary.

shrimp_emoji 3y ago
By importing leftpad
- deleted 3y ago
  [deleted]