[sdiy] Resources on embedded programming good practices?
johnspeth at yahoo.com
Tue Apr 21 16:52:22 CEST 2020
I'm in 100% agreement with this opinion but I'll add this:
Embedded code best practices are basically the same as non-embedded best
practices, generally speaking. It's in the hardware interfacing and low
level code that the differences appear. So it's entirely useful to learn
best practices from the classic sources, whatever they may be. Remember
that many handsomely formatted embedded code bodies of work, especially
from hobbyists and even from pros, don't necessarily represent best
But beware: The more resource limited your target is, the more
exceptions to best practices you'll find yourself applying if you run
into said limitations.
On 4/21/2020 7:16 AM, music.maker at gte.net wrote:
> "Best practices". For whom? For what? Why? I've seen many suggestions for such expressions and while it sounds academic and proper, reality eventually comes knocking at the door. We tend to push the hardware, so the code that is written isn't always going to be "as the professor taught" nor pretty nor elegant. Sometimes it's dirty and would deserve an F in college, but if it works and is reliable, it's not wrong. As a personal style, I am a comment profusely.
> Different environments dictate different approaches. A corporate group project needs practices which don't require a specific key man, rather that can be easily understood by any qualified coder. This can preclude using obscure obfuscated quirks of a device. Single coder projects are very different. The single coder answers to no one but him/herself so best practices are their own definition.
> Looking at lots of successful code written by others can be helpful to expose certain practices which can make code more reusable, but not every technique will fit the needs of every coder and every project.
> So in my world, there is no set of absolute best practices. Only those which I have found work to my advantage in my workflow.
> MTG <grant at musictechnologiesgroup.com> wrote:
>> I'm also interested in this. Sorry, I'm going to add on to your request. :)
>> ...including hardware such as starter SBCs "professional" debugging (NOT
>> printf styles). And I guess recommendations for sustainable compiler
>> environments, IDEs, version control. Sustainable meaning the same tool
>> will work in 5 or 10 years and not want to update every time I use it.
>> Maybe someone can suggest some electronic music code online that seems
>> to be written to "best practices" standards?
>> On 4/21/2020 5:36 AM, Spiros Makris wrote:
>>> Hello list,
>>> IÂ want to improve my coding habits so that my results will stay
>>> maintainable and easy to mod/reuse in the future. The scope of my
>>> applications (thus far) is sequencing and other similar low frequency
>>> control/real time devices. I use the arduino platform a lot for it's
>>> incredible simplicity and driver availability (I love you Teensy) but
>>> I'm trying to transition to STM32 eventually, seeing it as a more
>>> "serious" and professional platform. In both cases I use C/C++.
>>> I was officially taught C while studying in the university but that was
>>> 10 years ago and I've only picked up programming again in the past two
>>> or three. I understand digital hardware and the core C concepts,
>>> however, I don't have the opportunity to work alongside an experienced
>>> colleague to learn how I should write my code to be up to "industry
>>> standards" (= not be an unmaintainable mess etc) and I'm looking for
>>> something to refer to, other than my own trial and error.
>>> Example topics include anything from structuring headers to using
>>> globals or structuring function calls- especially under the prism of
>>> embedded applications. I would appreciate any suggestions on online
>>> resources or books.
>>> Synth-diy mailing list
>>> Synth-diy at synth-diy.org
>> Synth-diy mailing list
>> Synth-diy at synth-diy.org
> -- ScottG
> -- Scott Gravenhorst
> -- http://scott.joviansynth.com/
> -- When the going gets tough, the tough use the command line.
> -- Matt 21:22
> Synth-diy mailing list
> Synth-diy at synth-diy.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Synth-diy