Introduction When developing Embedded Software for memory constrained microcontrollers (typically using Embedded C), the most common constraint is the memory – in particular, RAM is often the most constrained resource. This issue is further exacerbated when using a multithreaded operating system, where many threads are running simultaneously – each allocates some Read more…
Information hiding is a good programming practice, however, what should one do when coding standards get in the way of this.
Good Software diagramming is the practice of documenting the essential parts of your source code that are not already clear (such as the underlying structure), or that are hidden by the other details. After having been dissatisfied with any single automated tool, good diagramming turns out to be more of an art form as I go back to basics and discover a combination of common and free tools and techniques that yield very satisfying results.
When programming in an environment that discourages the use of function pointers, one may find it difficult not to violate some of the common programming principals. I will be covering one common use of function pointers which is very often better avoided, especially when writing firmware for memory constrained systems such as many types of IoT-based products.
C is not generally known to offer function call chaining as is commonly found in many Object Orientated Languages. The following shows a C idiom for doing this.
How coroutines (Protothreads) can be used with C to reduce the cost and complexity of small systems such as those found in IoT based products.
C is the predominant language used by firmware that must scale to any large degree. However attempting to scale it down can be a lot more tricky than scaling it up.
Unit testing C code generally has some significant challenges when compared to some other languages. The main difficulty is that it can be quite difficult to test the outcome of a function call and how it has interacted with other modules and functions. This is because the state of the module Read more…
I don’t rate myself as much of an expert in IDEs, refactoring, history of programming, or in my ability to observe trends, but I still find these topics fascinating and I have had a bit of experience evaluating different products (mainly relating to C development) and will make an attempt at presenting my viewpoint. Read more…
Introduction When writing multi-file C application, or inheriting a project others have worked on, it is always helpful to understand how the code is structured from a file level. Ideally, you want to try to keep module dependencies running in a single direction, limiting reverse dependencies. Keeping the code structure in check can Read more…
When we decided to improve our coding quality by introduced unit testing to our work process in order to test our C code. The concept was new to many of the engineers who programmed in C, and there was a perception amongst some (developers as well as managers) that it makes development Read more…
Introduction Writing bug-free code is something we all strive for, but its almost impossible to meet this lofty goal with nontrivial programs. There are many different tools and techniques that can help to get us a lot closer to this goal [and more quickly] – one should use a combination Read more…