I find that in today’s age of IDEs like Visual Studio, Eclipse, Code Blocks, etc., that many developers get hung up on linker issues. This is completely understandable as many languages have moved away from the compiler/linker paradigm toward single compilation units or virtual machine code. Also, these modern development environments hide many of the steps that it takes to get a working executable out of working code. The result is that most of the C developers I run into are very familiar and are even experts in the C language itself, but unexpectedly struggle when presented with a build configuration issue.
Welcome to part two of my blog series on software architecture. The previous blog focused on an overview of software architecture in general. Part three will focus on software architecture that I have found to be beneficial. For now, let’s review four common software architecture pitfalls that I have encountered:
Recently, I was assigned to a project that assisted a customer in rapidly designing a micro controller embedded system capable of wired communication with other devices. Our involvement in the development of this project allowed the customer to focus on higher-level details, which were then built off of our implementation.
Software Architecture is a key component in developing a long term, successful embedded system device. However, the topic of what is included in software architecture is complex. Let’s take a look at an example of what software architecture is with an excerpt from Luke Hohmann in Beyond Software Architecture: Creating and Sustaining Winning Solutions:
“Software architecture is the sum of the nontrivial modules, processes, and data of the system, their structure and exact relationships to each other, how they can be and are expected to be extended and modified, and on which technologies they depend, from which one can deduce the exact capabilities and flexibilities of the system and from which one can form a plan for the implementation or modification of the system.”
Safety is a challenging status to achieve and maintain, thus the need for the guidelines that collectively fall under the heading of Functional Safety (FS). DISTek has always been conscience of safety as it applies to the products developed for our customers. This includes implementing the various requirements and guidelines associated with Functional Safety, as expressed in documents, such as ISO 25119.
Here at DISTek we just competed our 24th full calendar year as a company, which means our 25th anniversary happens in 2017. We are excited to think about our future as we pass this milestone, but it is also healthy to step back and review what we did in 2016. We took some bumps and bruises along the way – as did many in the industries we serve – but we also had some exciting successes.
As promised, here's my Part Two blog posting regarding the raspberrry pi.
The default kernel in Raspbian Jesse, the latest release of the raspberry pi’s official OS, could use a tune-up before being fit for duty running time-sensitive machine controls. On a vanilla Linux kernel program, latencies depend on everything running on the system making consistent and punctual tasks difficult to guarantee. The RT PREEMPT patch is a popular fix for this problem. The patch converts Linux into a fully preempt-able RTOS. If you want to control physical processes with your pi, as I intend to in DISTek’s training curriculum update, this is the way to go. But how big of a difference does it make on a pi?
Recently, I’ve been launching a little office project to develop a new training curriculum for DISTek engineers. Because it is hands-on training, it will require a toolchain. Since our customers use everything from off-the-shelf professional solutions to home-brewed ones, it’s important to prevent the nuances of a new toolchain from being a distraction in the training’s purpose of conveying good software practices and controls concepts.