Electronics > Projects, Designs, and Technical Stuff
uSupply Firmware Released
<< < (5/11) > >>
EEVblog:

--- Quote from: nuclearcat on May 27, 2020, 01:05:10 am ---Anonymous function (refered as authored by klingon) probably overkill for embedded and exactly opposite "of easy to understand code".
And whole fact returning pointer to *char by anonymous function might be fine on PC, but ehm, i think questionable in embedded.
But thats IMHO, i might be wrong.
I generally try to be careful and conservative with C++ features in embedded, you never know which function will make your code "suddenly overweight" or will start using "under the hood" dynamic memory allocation/reentrant functions/etc and guarantee you problems.
But it’s best to prove that, if i can write better code. Sure if i will be alive by the time uSupply will be released for sales.
--- End quote ---

The other thing is that David kept finding issues in the C++ compiler (and STM target), as in bugs or quirks that prevented the program from working, and in one case resulted in weeks worth of project delay until the compiler could be patched.
So yeah, the further you push the obscurities of the compiler, the more potential issues you would have for various reasons.
nuclearcat:

--- Quote from: EEVblog on May 27, 2020, 04:47:25 am ---The other thing is that David kept finding issues in the C++ compiler (and STM target), as in bugs or quirks that prevented the program from working, and in one case resulted in weeks worth of project delay until the compiler could be patched.
So yeah, the further you push the obscurities of the compiler, the more potential issues you would have for various reasons.

--- End quote ---
This is most common problem for those programmers who take for granted fancy features of c++17/etc and worked with them mostly on non-embedded targets.
I hit my hands when i try to use "on autopilot" convenient  std::vector(for example) in embedded, after got used to it hour ago on some linux software.
Nevertheless, the basic conveniences of C++ in the form of classes, constructors and destructors are reliable, thanks to the army of arduino testers (gcc/g++ under hood). And they make life much simpler and code more readable even for 8-bit AVR.
EEVblog:

--- Quote from: nuclearcat on May 27, 2020, 05:25:25 am ---
--- Quote from: EEVblog on May 27, 2020, 04:47:25 am ---The other thing is that David kept finding issues in the C++ compiler (and STM target), as in bugs or quirks that prevented the program from working, and in one case resulted in weeks worth of project delay until the compiler could be patched.
So yeah, the further you push the obscurities of the compiler, the more potential issues you would have for various reasons.

--- End quote ---
This is most common problem for those programmers who take for granted fancy features of c++17/etc and worked with them mostly on non-embedded targets.
--- End quote ---

Yes, I don't think David had issue with them on his PC stuff.
hans:

--- Quote from: nuclearcat on May 27, 2020, 01:05:10 am ---
--- Quote from: Dave on May 27, 2020, 12:53:04 am ---As soon as software becomes slightly more complex, you need to start splitting it in logical units, which you put into separate files. A well written software should not have files that stretch for more than a couple of hundred lines. There are of course always exceptions to this rule, but in general, one shouldn't have to scroll around and search for a particular part of code.

Next thing is abstraction. Just tossing register names around all over the place is very poor form. At the very least they should be macroed away with descriptive names.
Preferably, hardware abstraction should be done in a separate module altogether, so you never actually fiddle with registers directly in the application portion. By making code modular, porting code to a new platform becomes very easy. Want to use a new microcontroller? No problem, just replace/modify the hardware abstraction module and you're set.

Good code usually doesn't even need comments, because the names of the functions and variables themselves are descriptive enough to make it clear what something is doing.

--- End quote ---
Anonymous function (refered as authored by klingon) probably overkill for embedded and exactly opposite "of easy to understand code".
And whole fact returning pointer to *char by anonymous function might be fine on PC, but ehm, i think questionable in embedded.
But thats IMHO, i might be wrong.
I generally try to be careful and conservative with C++ features in embedded, you never know which function will make your code "suddenly overweight" or will start using "under the hood" dynamic memory allocation/reentrant functions/etc and guarantee you problems.
But it’s best to prove that, if i can write better code. Sure if i will be alive by the time uSupply will be released for sales.

--- End quote ---
Anonymous functions are sometimes useful, but often not in embedded.

C++ templates for embedded are useful, but also to certain degree. I like the tidiness of the codebase, it seems well maintained and structured. However, I've seen a few cases where I don't think I would have used a template, as the code size/speed gain is probably very small or absent (assuming the optimizer is turned on sufficiently).

Being careful with mechanic/function selection of C++ is a good point. You need to be aware of how the STL functions are implemented, and which are suitable for use on embedded, and also at which portions of the code, or are better left for unit tests (e.g. if the library uses dynamic memory allocation such as std::vector vs std:array). However, I think there are many language features/gems that are too good to leave untouched, for example templates and fast reusage of existing code using classes.
NivagSwerdna:

--- Quote from: nuclearcat on May 27, 2020, 12:55:55 am ---You can gain a lot from writing free code.
)Community recognition. When you contribute to opensource, your potential employer will probably get an positive impression about you even before he looks at your CV.
In some cases, if you are contractor - you may be hired, since such portfolio is the best portfolio.
)Honing your skills and you might get free beta-testing and free review by professionals, including (probably) Dave. It is unlikely that you will have enough money to make Dave interested to touch and look to your proprietary code otherwise.
)Competition. Its FUN to be best!

And not only about gaining something. Altruism is good for humanity. Starting from the fact that the forum(software running it, OS, etc) we are talking in - exists, because many programmers once gifted the world pieces of their code.

--- End quote ---
I actually contribute to at least three open source projects.... but I still think it is a rubbish business model.  :) [I'm probably jaded by having spent decades contracting]
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod