New approaches for embedded development

The idea for this posting started when I read New approaches to dominate in embedded development article. Then I found some ther related articles and here is the result: long article.

Embedded devices, or embedded systems, are specialized computer systems that constitute components of larger electromechanical systems with which they interface. The advent of low-cost wireless connectivity is altering many things in embedded development: With a connection to the Internet, an embedded device can gain access to essentially unlimited processing power and memory in cloud service – and at the same time you need to worry about communication issues like breaks connections, latency and security issues.

Those issues are espcecially in the center of the development of popular Internet of Things device and adding connectivity to existing embedded systems. All this means that the whole nature of the embedded development effort is going to change. A new generation of programmers are already making more and more embedded systems. Rather than living and breathing C/C++, the new generation prefers more high-level, abstract languages (like Java, Python, JavaScript etc.). Instead of trying to craft each design to optimize for cost, code size, and performance, the new generation wants to create application code that is separate from an underlying platform that handles all the routine details. Memory is cheap, so code size is only a minor issue in many applications.

Historically, a typical embedded system has been designed as a control-dominated system using only a state-oriented model, such as FSMs. However, the trend in embedded systems design in recent years has been towards highly distributed architectures with support for concurrency, data and control flow, and scalable distributed computations. For example computer networks, modern industrial control systems, electronics in modern car,Internet of Things system fall to this category. This implies that a different approach is necessary.

Companies are also marketing to embedded developers in new ways. Ultra-low cost development boards to woo makers, hobbyists, students, and entrepreneurs on a shoestring budget to a processor architecture for prototyping and experimentation have already become common.If you look under the hood of any connected embedded consumer or mobile device, in addition to the OS you will find a variety of middleware applications. As hardware becomes powerful and cheap enough that the inefficiencies of platform-based products become moot. Leaders with Embedded systems development lifecycle management solutions speak out on new approaches available today in developing advanced products and systems.

Traditional approaches


Tradionally embedded developers have been living and breathing C/C++. For a variety of reasons, the vast majority of embedded toolchains are designed to support C as the primary language. If you want to write embedded software for more than just a few hobbyist platforms, your going to need to learn C. Very many embedded systems operating systems, including Linux Kernel, are written using C language. C can be translated very easily and literally to assembly, which allows programmers to do low level things without the restrictions of assembly. When you need to optimize for cost, code size, and performance the typical choice of language is C. Still C is today used for maximum efficiency instead of C++.

C++ is very much alike C, with more features, and lots of good stuff, while not having many drawbacks, except fror it complexity. The had been for years suspicion C++ is somehow unsuitable for use in small embedded systems. At some time many 8- and 16-bit processors were lacking a C++ compiler, that may be a concern, but there are now 32-bit microcontrollers available for under a dollar supported by mature C++ compilers.Today C++ is used a lot more in embedded systems. There are many factors that may contribute to this, including more powerful processors, more challenging applications, and more familiarity with object-oriented languages.

And if you use suitable C++ subset for coding, you can make applications that work even on quite tiny processors, let the Arduino system be an example of that: You’re writing in C/C++, using a library of functions with a fairly consistent API. There is no “Arduino language” and your “.ino” files are three lines away from being standard C++.

Today C++ has not displaced C. Both of the languages are widely used, sometimes even within one system – for example in embedded Linux system that runs C++ application. When you write a C or C++ programs for modern Embedded Linux you typically use GCC compiler toolchain to do compilation and make file to manage compilation process.

Most organization put considerable focus on software quality, but software security is different. When the security is very much talked about topic todays embedded systems, the security of the programs written using C/C++ becomes sometimes a debated subject. Embedded development presents the challenge of coding in a language that’s inherently insecure; and quality assurance does little to ensure security. The truth is that majority of today’s Internet connected systems have their networking fuctionality written using C even of the actual application layer is written using some other methods.


Java is a general-purpose computer programming language that is concurrent, class-based and object-oriented.The language derives much of its syntax from C and C++, but it has fewer low-level facilities than either of them. Java is intended to let application developers “write once, run anywhere” (WORA), meaning that compiled Java code can run on all platforms that support Java without the need for recompilation.Java applications are typically compiled to bytecode that can run on any Java virtual machine (JVM) regardless of computer architecture. Java is one of the most popular programming languages in use, particularly for client-server web applications. In addition to those it is widely used in mobile phones (Java apps in feature phones,) and some embedded applications. Some common examples include SIM cards, VOIP phones, Blu-ray Disc players, televisions, utility meters, healthcare gateways, industrial controls, and countless other devices.

Some experts point out that Java is still a viable option for IoT programming. Think of the industrial Internet as the merger of embedded software development and the enterprise. In that area, Java has a number of key advantages: first is skills – there are lots of Java developers out there, and that is an important factor when selecting technology. Second is maturity and stability – when you have devices which are going to be remotely managed and provisioned for a decade, Java’s stability and care about backwards compatibility become very important. Third is the scale of the Java ecosystem – thousands of companies already base their business on Java, ranging from Gemalto using JavaCard on their SIM cards to the largest of the enterprise software vendors.

Although in the past some differences existed between embedded Java and traditional PC based Java solutions, the only difference now is that embedded Java code in these embedded systems is mainly contained in constrained memory, such as flash memory. A complete convergence has taken place since 2010, and now Java software components running on large systems can run directly with no recompilation at all on design-to-cost mass-production devices (consumers, industrial, white goods, healthcare, metering, smart markets in general,…) Java for embedded devices (Java Embedded) is generally integrated by the device manufacturers. It is NOT available for download or installation by consumers. Originally Java was tightly controlled by Sun (now Oracle), but in 2007 Sun relicensed most of its Java technologies under the GNU General Public License. Others have also developed alternative implementations of these Sun technologies, such as the GNU Compiler for Java (bytecode compiler), GNU Classpath (standard libraries), and IcedTea-Web (browser plugin for applets).

My feelings with Java is that if your embedded systems platform supports Java and you know hot to code Java, then it could be a good tool. If your platform does not have ready Java support, adding it could be quite a bit of work.


Increasing trends


Embedded databases are coming more and more to the embedded devices. If you look under the hood of any connected embedded consumer or mobile device, in addition to the OS you will find a variety of middleware applications. One of the most important and most ubiquitous of these is the embedded database. An embedded database system is a database management system (DBMS) which is tightly integrated with an application software that requires access to stored data, such that the database system is “hidden” from the application’s end-user and requires little or no ongoing maintenance.

There are many possible databases. First choice is what kind of database you need. The main choices are SQL databases and simpler key-storage databases (also called NoSQL).

SQLite is the Database chosen by virtually all mobile operating systems. For example Android and iOS ship with SQLite. It is also built into for example Firefox web browser. It is also often used with PHP. So SQLite is probably a pretty safe bet if you need relational database for an embedded system that needs to support SQL commands and does not need to store huge amounts of data (no need to modify database with millions of lines of data).

If you do not need relational database and you need very high performance, you need probably to look somewhere else.Berkeley DB (BDB) is a software library intended to provide a high-performance embedded database for key/value data. Berkeley DB is written in Cwith API bindings for many languages. BDB stores arbitrary key/data pairs as byte arrays. There also many other key/value database systems.

RTA (Run Time Access) gives easy runtime access to your program’s internal structures, arrays, and linked-lists as tables in a database. When using RTA, your UI programs think they are talking to a PostgreSQL database (PostgreSQL bindings for C and PHP work, as does command line tool psql), but instead of normal database file you are actually accessing internals of your software.

Software quality

Building quality into embedded software doesn’t happen by accident. Quality must be built-in from the beginning. Software startup checklist gives quality a head start article is a checklist for embedded software developers to make sure they kick-off their embedded software implementation phase the right way, with quality in mind


Traditional methods for achieving safety properties mostly originate from hardware-dominated systems. Nowdays more and more functionality is built using software – including safety critical functions. Software-intensive embedded systems require new approaches for safety. Embedded Software Can Kill But Are We Designing Safely?

IEC, FDA, FAA, NHTSA, SAE, IEEE, MISRA, and other professional agencies and societies work to create safety standards for engineering design. But are we following them? A survey of embedded design practices leads to some disturbing inferences about safety.Barr Group’s recent annual Embedded Systems Safety & Security Survey indicate that we all need to be concerned: Only 67 percent are designing to relevant safety standards, while 22 percent stated that they are not—and 11 percent did not even know if they were designing to a standard or not.

If you were the user of a safety-critical embedded device and learned that the designers had not followed best practices and safety standards in the design of the device, how worried would you be? I know I would be anxious, and quite frankly. This is quite disturbing.


The advent of low-cost wireless connectivity is altering many things in embedded development – it has added to your list of worries need to worry about communication issues like breaks connections, latency and security issues. Understanding security is one thing; applying that understanding in a complete and consistent fashion to meet security goals is quite another. Embedded development presents the challenge of coding in a language that’s inherently insecure; and quality assurance does little to ensure security.

Developing Secure Embedded Software white paper  explains why some commonly used approaches to security typically fail:


Many organizations are only now becoming aware of the need to incorporate security into their software development lifecycle.

Some techniques for building security to embedded systems:

Use secure communications protocols and use VPN to secure communications
The use of Public Key Infrastructure (PKI) for boot-time and code authentication
Establishing a “chain of trust”
Process separation to partition critical code and memory spaces
Leveraging safety-certified code
Hardware enforced system partitioning with a trusted execution environment
Plan the system so that it can be easily and safely upgraded when needed

Flood of new languages

Rather than living and breathing C/C++, the new generation prefers more high-level, abstract languages (like Java, Python, JavaScript etc.). So there is a huge push to use interpreted and scripting also in embedded systems. Increased hardware performance on embedded devices combined with embedded Linux has made the use of many scripting languages good tools for implementing different parts of embedded applications (for example web user interface). Nowadays it is common to find embedded hardware devices, based on Raspberry Pi for instance, that are accessible via a network, run Linux and come with Apache and PHP installed on the device.  There are also many other relevant languages

One workable solution, especially for embedded Linux systems is that part of the activities organized by totetuettu is a C program instead of scripting languages ​​(Scripting). This enables editing operation simply script files by editing without the need to turn the whole system software again.  Scripting languages ​​are also tools that can be implemented, for example, a Web user interface more easily than with C / C ++ language. An empirical study found scripting languages (such as Python) more productive than conventional languages (such as C and Java) for a programming problem involving string manipulation and search in a dictionary.

Scripting languages ​​have been around for a couple of decades Linux and Unix server world standard tools. the proliferation of embedded Linux and resources to merge systems (memory, processor power) growth has made them a very viable tool for many embedded systems – for example, industrial systems, telecommunications equipment, IoT gateway, etc . Some of the command language is suitable for up well even in quite small embedded environments.
I have used with embedded systems successfully mm. Bash, AWK, PHP, Python and Lua scripting languages. It works really well and is really easy to make custom code quickly .It doesn’t require a complicated IDE; all you really need is a terminal – but if you want there are many IDEs that can be used.
High-level, dynamically typed languages, such as Python, Ruby and JavaScript. They’re easy—and even fun—to use. They lend themselves to code that easily can be reused and maintained.

There are some thing that needs to be considered when using scripting languages. Sometimes lack of static checking vs a regular compiler can cause problems to be thrown at run-time. But it is better off practicing “strong testing” than relying on strong typing. Other ownsides of these languages is that they tend to execute more slowly than static languages like C/C++, but for very many aplications they are more than adequate. Once you know your way around dynamic languages, as well the frameworks built in them, you get a sense of what runs quickly and what doesn’t.

Bash and other shell scipting

Shell commands are the native language of any Linux system. With the thousands of commands available for the command line user, how can you remember them all? The answer is, you don’t. The real power of the computer is its ability to do the work for you – the power of the shell script is the way to easily to automate things by writing scripts. Shell scripts are collections of Linux command line commands that are stored in a file. The shell can read this file and act on the commands as if they were typed at the keyboard.In addition to that shell also provides a variety of useful programming features that you are familar on other programming langauge (if, for, regex, etc..). Your scripts can be truly powerful. Creating a script extremely straight forward: It can be created by opening a separate editor such or you can do it through a terminal editor such as VI (or preferably some else more user friendly terminal editor). Many things on modern Linux systems rely on using scripts (for example starting and stopping different Linux services at right way).

One of the most useful tools when developing from within a Linux environment is the use of shell scripting. Scripting can help aid in setting up environment variables, performing repetitive and complex tasks and ensuring that errors are kept to a minimum. Since scripts are ran from within the terminal, any command or function that can be performed manually from a terminal can also be automated!

The most common type of shell script is a bash script. Bash is a commonly used scripting language for shell scripts. In BASH scripts (shell scripts written in BASH) users can use more than just BASH to write the script. There are commands that allow users to embed other scripting languages into a BASH script.

There are also other shells. For example many small embedded systems use BusyBox. BusyBox providesis software that provides several stripped-down Unix tools in a single executable file (more than 300 common command). It runs in a variety of POSIX environments such as Linux, Android and FreeeBSD. BusyBox become the de facto standard core user space toolset for embedded Linux devices and Linux distribution installers.

Shell scripting is a very powerful tool that I used a lot in Linux systems, both embedded systems and servers.


Lua is a lightweight  cross-platform multi-paradigm programming language designed primarily for embedded systems and clients. Lua was originally designed in 1993 as a language for extending software applications to meet the increasing demand for customization at the time. It provided the basic facilities of most procedural programming languages. Lua is intended to be embedded into other applications, and provides a C API for this purpose.

Lua has found many uses in many fields. For example in video game development, Lua is widely used as a scripting language by game programmers. Wireshark network packet analyzer allows protocol dissectors and post-dissector taps to be written in Lua – this is a good way to analyze your custom protocols.

There are also many embedded applications. LuCI, the default web interface for OpenWrt, is written primarily in Lua. NodeMCU is an open source hardware platform, which can run Lua directly on the ESP8266 Wi-Fi SoC. I have tested NodeMcu and found it very nice system.


PHP is a server-side HTML embedded scripting language. It provides web developers with a full suite of tools for building dynamic websites but can also be used as a general-purpose programming language. Nowadays it is common to find embedded hardware devices, based on Raspberry Pi for instance, that are accessible via a network, run Linux and come with Apache and PHP installed on the device. So on such enviroment is a good idea to take advantage of those built-in features for the applications they are good – for building web user interface. PHP is often embedded into HTML code, or it can be used in combination with various web template systems, web content management system and web frameworks. PHP code is usually processed by a PHP interpreter implemented as a module in the web server or as a Common Gateway Interface (CGI) executable.


Python is a widely used high-level, general-purpose, interpreted, dynamic programming language. Its design philosophy emphasizes code readability. Python interpreters are available for installation on many operating systems, allowing Python code execution on a wide variety of systems. Many operating systems include Python as a standard component; the language ships for example with most Linux distributions.

Python is a multi-paradigm programming language: object-oriented programming and structured programming are fully supported, and there are a number of language features which support functional programming and aspect-oriented programming,  Many other paradigms are supported using extensions, including design by contract and logic programming.

Python is a remarkably powerful dynamic programming language that is used in a wide variety of application domains. Since 2003, Python has consistently ranked in the top ten most popular programming languages as measured by the TIOBE Programming Community Index. Large organizations that make use of Python include Google, Yahoo!, CERN, NASA. Python is used successfully in thousands of real world business applications around globally, including many large and mission-critical systems such as and

Python was designed to be highly extensible. Libraries like NumPy, SciPy and Matplotlib allow the effective use of Python in scientific computing. Python is intended to be a highly readable language. Python can also be embedded in existing applications and hasbeen successfully embedded in a number of software products as a scripting language. Python can serve as a scripting language for web applications, e.g., via mod_wsgi for the Apache web server.

Python can be used in embedded, small or minimal hardware devices. Some modern embedded devices have enough memory and a fast enough CPU to run a typical Linux-based environment, for example, and running CPython on such devices is mostly a matter of compilation (or cross-compilation) and tuning. Various efforts have been made to make CPython more usable for embedded applications.

For more limited embedded devices, a re-engineered or adapted version of CPython, might be appropriateExamples of such implementations include the following: PyMite, Tiny Python, Viper. Sometimes the embedded environment is just too restrictive to support a Python virtual machine. In such cases, various Python tools can be employed for prototyping, with the eventual application or system code being generated and deployed on the device. Also MicroPython and tinypy have been ported Python to various small microcontrollers and architectures. Real world applications include Telit GSM/GPRS modules that allow writing the controlling application directly in a high-level open-sourced language: Python.

Python on embedded platforms? It is quick to develop apps, quick to debug – really easy to make custom code quickly. Sometimes lack of static checking vs a regular compiler can cause problems to be thrown at run-time. To avoid those try to have 100% test coverage. pychecker is a very useful too also which will catch quite a lot of common errors. The only downsides for embedded work is that sometimes python can be slow and sometimes it uses a lot of memory (relatively speaking). An empirical study found scripting languages (such as Python) more productive than conventional languages (such as C and Java) for a programming problem involving string manipulation and search in a dictionary. Memory consumption was often “better than Java and not much worse than C or C++”.

JavaScript and node.js

JavaScript is a very popular high-level language. Love it or hate it, JavaScript is a popular programming language for many, mainly because it’s so incredibly easy to learn. JavaScript’s reputation for providing users with beautiful, interactive websites isn’t where its usefulness ends. Nowadays, it’s also used to create mobile applications, cross-platform desktop software, and thanks to Node.js, it’s even capable of creating and running servers and databases!  There is huge community of developers. JavaScript is a high-level language.

Its event-driven architecture fits perfectly with how the world operates – we live in an event-driven world. This event-driven modality is also efficient when it comes to sensors.

Regardless of the obvious benefits, there is still, understandably, some debate as to whether JavaScript is really up to the task to replace traditional C/C++ software in Internet connected embedded systems.

It doesn’t require a complicated IDE; all you really need is a terminal.

JavaScript is a high-level language. While this usually means that it’s more human-readable and therefore more user-friendly, the downside is that this can also make it somewhat slower. Being slower definitely means that it may not be suitable for situations where timing and speed are critical.

JavaScript is already in embedded boards. You can run JavaScipt on Raspberry Pi and BeagleBone. There are also severa other popular JavaScript-enabled development boards to help get you started: The Espruino is a small microcontroller that runs JavaScript. The Tessel 2 is a development board that comes with integrated wi-fi, an ethernet port, two USB ports, and companion source library downloadable via the Node Package Manager. The Kinoma Create, dubbed the “JavaScript powered Internet of Things construction kit.”The best part is that, depending on the needs of your device, you can even compile your JavaScript code into C!

JavaScript for embedded systems is still in its infancy, but we suspect that some major advancements are on the horizon.We for example see a surprising amount of projects using Node.js.Node.js is an open-source, cross-platform runtime environment for developing server-side Web applications. Node.js has an event-driven architecture capable of asynchronous I/O that allows highly scalable servers without using threading, by using a simplified model of event-driven programming that uses callbacks to signal the completion of a task. The runtime environment interprets JavaScript using Google‘s V8 JavaScript engine.Node.js allows the creation of Web servers and networking tools using JavaScript and a collection of “modules” that handle various core functionality. Node.js’ package ecosystem, npm, is the largest ecosystem of open source libraries in the world. Modern desktop IDEs provide editing and debugging features specifically for Node.js applications

JXcore is a fork of Node.js targeting mobile devices and IoTs. JXcore is a framework for developing applications for mobile and embedded devices using JavaScript and leveraging the Node ecosystem (110,000 modules and counting)!

Why is it worth exploring node.js development in an embedded environment? JavaScript is a widely known language that was designed to deal with user interaction in a browser.The reasons to use Node.js for hardware are simple: it’s standardized, event driven, and has very high productivity: it’s dynamically typed, which makes it faster to write — perfectly suited for getting a hardware prototype out the door. For building a complete end-to-end IoT system, JavaScript is very portable programming system. Typically an IoT projects require “things” to communicate with other “things” or applications. The huge number of modules available in Node.js makes it easier to generate interfaces – For example, the HTTP module allows you to create easily an HTTP server that can easily map the GET method specific URLs to your software function calls. If your embedded platform has ready made Node.js support available, you should definately consider using it.

Future trends

According to New approaches to dominate in embedded development article there will be several camps of embedded development in the future:

One camp will be the traditional embedded developer, working as always to craft designs for specific applications that require the fine tuning. These are most likely to be high-performance, low-volume systems or else fixed-function, high-volume systems where cost is everything.

Another camp might be the embedded developer who is creating a platform on which other developers will build applications. These platforms might be general-purpose designs like the Arduino, or specialty designs such as a virtual PLC system.

This third camp is likely to become huge: Traditional embedded development cannot produce new designs in the quantities and at the rate needed to deliver the 50 billion IoT devices predicted by 2020.

Transition will take time. The enviroment is different than computer and mobile world. There are too many application areas with too widely varying requirements for a one-size-fits-all platform to arise.

But the shift will happen as hardware becomes powerful and cheap enough that the inefficiencies of platform-based products become moot.



Most important information sources:

New approaches to dominate in embedded development

A New Approach for Distributed Computing in Embedded Systems

New Approaches to Systems Engineering and Embedded Software Development

Lua (programming language)

Embracing Java for the Internet of Things


Wikipedia Node.js

Writing Shell Scripts

Embedded Linux – Shell Scripting 101

Embedded Linux – Shell Scripting 102

Embedding Other Languages in BASH Scripts

PHP Integration with Embedded Hardware Device Sensors – PHP Classes blog


Python (programming language)

JavaScript: The Perfect Language for the Internet of Things (IoT)

Node.js for Embedded Systems

Embedded Python

MicroPython – Embedded Pytho

Anyone using Python for embedded projects?

Telit Programming Python

JavaScript: The Perfect Language for the Internet of Things (IoT)


Node.js for Embedded Systems

Why node.js?

Node.JS Appliances on Embedded Linux Devices

The smartest way to program smart things: Node.js

Embedded Software Can Kill But Are We Designing Safely?






  1. Tomi Engdahl says:

    Don’t Delay() Use an Arduino Task Scheduler Today!

    Task scheduling is a transformative way to write maintainable code for Arduino and other AVRs. No more spaghetti code. C++ tutorial.

    As my Arduino projects became more complex I started to realize the delay() function caused unforeseen problems. While in a delay, the Arduino/AVR can’t process any other code (with a few exceptions). I came across this solution while researching another topic and I thought I would document it for my future projects. Alan Burlison created an eloquent Task Scheduler library that solves the delay issues —but more importantly, it made me rethink how I design my Arduino/AVR projects.

    A very simple Arduino task manager

    The LED chain project I’m working on requires that the AVR microcontroller handles several different tasks:

    Read a rotary encoder and switch
    Drive a seven-segment display
    Drive a radio
    Drive four LED strips each containing twenty LEDs
    Provide logic to tie all the above together

    Normally that sort of multiple-task workload might suggest the use of a RTOS, but the Arduino Pro Mini has only 32Kb of program memory (of which 2Kb is used by the bootloader) and 2Kb of RAM, so every byte is precious. So, whatever we come up with has to be as minimal as possible. OK, let’s see if we can make some assumptions and trade-offs that will help keep things simple and create a small set of C++ classes we can use to implement the task management

  2. Tomi Engdahl says:

    Top 10 Tips When Designing with Embedded Flash

    These top 10 tips outline the things that engineers need to consider when specifying embedded flash to help make the process simpler

    #10: FOB vs. steady-state performance
    #9: Seeking consistent performance
    #8: Overprovisioning
    #7: Managing static data with RDM and DDR
    #6: Ensuring health
    #5: Improved mapping with hyMap
    #4: Invisible caching trade-offs
    #3: Trading capacity for performance and reliability
    #2: Data in power-failure events
    #1: Defining requirements

    There is a variety of storage systems and controllers available in terms of interface options and quality levels. If the storage system is vital for your application or holds sensitive data, or if failure would result in costly down-time, you need to choose your controller carefully, so make sure that you fully understand your requirements.

  3. Tomi Engdahl says:

    Heterogeneous Design Creating Havoc With Firmware Versions

    Updates, last-minute changes to design add a whole new set of challenges at sign-off.

  4. Tomi Engdahl says:

    Big Shift In Multi-Core Design

    System-wide concerns in AI and automotive are forcing hardware and software teams to work together, but gaps still remain.

  5. Tomi Engdahl says:

    Most Embedded System Failures Can Be Prevented
    Simple steps early in the design process can pay dividends down the road, expert says.

    Early awareness of problems is the key to circumventing failures of embedded electronics, an expert will tell attendees at the upcoming Embedded Systems Conference in Boston.

    The Three Biggest Culprits

    The most insidious failure mechanism – the one that often blindsides developers – is heat, Hillman said. Unfortunately, thermal issues are typically addressed too late.

    He recommends that developers do “back-of-the-envelope” calculations as early in the design as possible, even before doing simulations or computational fluid dynamics (CFD) studies. “

    In terms of raw numbers, however, the biggest problem may be connectors, Hillman will tell attendees. “When we talk to customers, we hear that connectors are the most common cause of embedded systems failures,” Hillman told us.

    it can be a difficult failure to prevent, since connectors may be specified early and designers may have little choice in the matter. Still, he said, designers should consider such issues as positive retention, strain relief, alignment of pins, and separation of power and ground.

    Finally, he said, embedded designers must weigh the effects of developing their own systems versus buying them from vendors. The majority of engineers do a mixture of both, he said. And if that’s the case, they must be prepared, not only to choose the best vendor, but to clearly define that vendor’s role.

    “You have to decide early on what you need from the vendor,”

  6. Tomi Engdahl says:

    3 Reasons UX/UI Is Important for Hardware Products

    As engineers, we must embrace the idea that a well-designed user experience and user interface can be the key to the success or failure of a hardware product.

    While we often think about user experience (UX) and user interface (UI) in the context of software, let’s not forget how crucial UX/UI can be in the development of hardware products. Sometimes UX/UI is the only or main differentiator in a company’s products and can be the key to the success or failure of a product.

    As engineers, particularly those involved in projects invoking Department of Defense (DoD) specifications, UI in the hardware world is often perceived as meeting human interface specifications. And while this certainly is part of the UI story, the total story of UX and UI is much greater than meeting government specification, which are driven by the need for operational efficiency.

    The full UX/UI portfolio is not just functional, but a tie into the emotional attachment to a product.

    Here are some reasons why UX/UI considerations are important when developing hardware products:

    1.) Well-Designed Products Work Better
    2.) Great Design Makes Users Feel Good About Using the Products
    3.) Good Design Builds Brand Loyalty

  7. Tomi Engdahl says:

    Technical Documentation in Software Development: Types, Best Practices, and Tools

    Technical documentation in software engineering is the umbrella term that encompasses all written documents and materials dealing with software product development. All software development products, whether created by a small team or a large corporation, require some related documentation. And different types of documents are created through the whole software development lifecycle (SDLC).

  8. Tomi Engdahl says:

    Beware the Hidden Costs of a Free Embedded RTOS

    If you’re basing your selection of a real-time operating system (RTOS) solely on initial cost, then you may be in for a rude awakening.

    Engineers who select an embedded RTOS simply because its free can end up spending more money in the long run, contends Jacob Beningo, an embedded software consultant at the Beningo Embedded Group. Moreover, they can fail certifications and end up having security issues.

    “You have to stop looking at cost as the only data point, and really evaluate all the features and the ecosystem,” Beningo said. “When you’re selecting your RTOS, you need to do your engineering due-diligence to make sure you select something that meets all your needs.”

  9. Tomi Engdahl says:

    In a video, Mentor’s Colin Walls digs into power management in embedded software with a particular look at the Power Pyramid model.

    Video about embedded power management

  10. Tomi Engdahl says:

    Target: 50% Reduction In Memory Power

    Is it possible to reduce the power consumed by memory by 50%? Yes, but it requires work in the memory and at the architecture level.

  11. Tomi Engdahl says:

    Optimization Challenges For Safety And Security

    The road to optimized tradeoff automation is long. Changing attributes along the way can make it even more difficult.

  12. Tomi Engdahl says:

    Finding Code Problems Before High-Level Synthesis

    Making sure C++ models are correct before simulation.

  13. Tomi Engdahl says:

    New Approaches To Security

    Data analytics, traffic patterns and restrictive policies emerge as ways to ensure that systems are secure.

  14. Tomi Engdahl says:

    Mullistava tekniikka pakkaa koodin tiheämpään

    Periaate toimii Javan lisäksi kaikilla muillakin objektiorientoituneilla kielillä, kuten Pythonilla tai Go-kielellä. Lisätehoa saataisiin käyttöön kaikilla ohjelmia ajavilla koneilla, eikä ohjelmista tarvitsisi muuttaa koodiriviäkään.

  15. Tomi Engdahl says:

    How the Boeing 737 Max Disaster Looks to a Software Developer

    The Boeing 737 Max has been in the news because of two crashes, practically back to back and involving brand new airplanes. In an industry that relies more than anything on the appearance of total control, total safety, these two crashes pose as close to an existential risk as you can get.

    Apparently the 737 Max pitched up a bit too much for comfort on power application as well as at already-high angles of attack. It violated that most ancient of aviation canons and probably violated the certification criteria of the U.S. Federal Aviation Administration. But instead of going back to the drawing board and getting the airframe hardware right (more on that below), Boeing relied on something called the “Maneuvering Characteristics Augmentation System,” or MCAS.

    Boeing’s solution to its hardware problem was software.

    “Cheap way to prevent a stall when the pilots punch it,” or CWTPASWTPPI, system. Hmm. Perhaps MCAS is better, after all.

    MCAS is certainly much less expensive than extensively modifying the airframe to accommodate the larger engines.

    the major selling point of the 737 Max is that it is just a 737, and any pilot who has flown other 737s can fly a 737 Max without expensive training, without recertification, without another type of rating.

    It all comes down to money, and in this case, MCAS was the way for both Boeing and its customers to keep the money flowing in the right direction.

    That’s probably also the reason why the documentation about the MCAS system was kept on the down-low.

    Angle-of-attack sensors look like wind vanes because that’s exactly what they are.

    Long ago there was a joke that in the future planes would fly themselves

    On the 737, Boeing not only included the requisite redundancy in instrumentation and sensors, it also included redundant flight computers—one on the pilot’s side, the other on the copilot’s side.

    their main job is to fly the plane when commanded to do so and to make sure the human pilots don’t do anything wrong when they’re flying it. The latter is called “envelope protection.”

    When MCAS senses that the angle of attack is too high, it commands the aircraft’s trim system

    In the 737 Max, like most modern airliners and most modern cars, everything is monitored by computer, if not directly controlled by computer. In many cases, there are no actual mechanical connections (cables, push tubes, hydraulic lines) between the pilot’s controls and the things on the wings, rudder, and so forth that actually make the plane move.

    With computer oversight there is a loss of natural sense in the controls. In the 737 Max, there is no real “natural feel.”

    Indeed, not letting the pilot regain control by pulling back on the column was an explicit design decision.

    MCAS is implemented in the flight management computer, even at times when the autopilot is turned off, when the pilots think they are flying the plane.

    The flight management computer is a computer.

    It’s full of lines of code. And that’s where things get dangerous.

    Those lines of code were no doubt created by people at the direction of managers. Neither such coders nor their managers are as in touch with the particular culture and mores of the aviation world

    In the 737 Max, only one of the flight management computers is active at a time—either the pilot’s computer or the copilot’s computer. And the active computer takes inputs only from the sensors on its own side of the aircraft.

    In the Boeing system, the flight
 management computer does not “look 
across” at the other instruments. It 
believes only the instruments on its side. It doesn’t go old-school. It’s modern. It’s software.

    This means is that if a particular angle-of-attack sensor goes haywire—which happens all the time in a machine that alternates from one extreme environment to another, vibrating and shaking all the way—the flight management computer just believes it.

    It gets even worse. There are several other instruments that can be used to determine things like angle of attack, either directly or indirectly, such as the pitot tubes, the artificial horizons, etc. All of these things would be cross-checked by a human pilot to quickly diagnose a faulty angle-of-attack sensor.

    Like someone with narcissistic personality disorder, MCAS gaslights the pilots. And it turns out badly for everyone. “Raise the nose, HAL.” “I’m sorry, Dave, I’m afraid I can’t do that.”

    In the MCAS system, the flight management computer is blind to any other evidence that it is wrong, including what the pilot sees with his own eyes and what he does when he desperately tries to pull back on the robotic control columns that are biting him, and his passengers, to death.

    In the old days, the FAA had armies of aviation engineers in its employ.

    As airplanes became more complex and the gulf between what the FAA could pay and what an aircraft manufacturer could pay grew larger, more and more of those engineers migrated from the public to the private sector. Soon the FAA had no in-house ability to determine if a particular airplane’s design and manufacture were safe. So the FAA said to the airplane manufacturers, “Why don’t you just have your people tell us if your designs are safe?”

    The airplane manufacturers said, “Sounds good to us.”

    Thus was born the concept of the “Designated Engineering Representative,” or DER. DERs are people in the employ of the airplane manufacturers, the engine manufacturers, and the software developers who certify to the FAA that it’s all good.

    It is astounding that no one who wrote the MCAS software for the 737 Max seems even to have raised the possibility of using multiple inputs

    But I do know that it’s indicative of a much deeper problem. The people who wrote the code for the original MCAS system were obviously terribly far out of their league and did not know it. How can they can implement a software fix, much less give us any comfort that the rest of the flight management software is reliable?

    So Boeing produced a dynamically unstable airframe, the 737 Max. That is big strike No. 1. Boeing then tried to mask the 737’s dynamic instability with a software system. Big strike No. 2. Finally, the software relied on systems known for their propensity to fail (angle-of-attack indicators) and did not appear to include even rudimentary provisions to cross-check the outputs of the angle-of-attack sensor against other sensors, or even the other angle-of-attack sensor. Big strike No. 3.

    None of the above should have passed muster. None of the above should have passed the “OK” pencil of the most junior engineering staff, much less a DER.

    That’s not a big strike. That’s a political, social, economic, and technical sin.

    it seems that with the 737 Max, Boeing has changed philosophies about human/machine interaction as quietly as they’ve changed their aircraft operating manuals.

    The 737 Max saga teaches us not only about the limits of technology and the risks of complexity, it teaches us about our real priorities. Today, safety doesn’t come first—money comes first, and safety’s only utility in that regard is in helping to keep the money coming. The problem is getting worse because our devices are increasingly dominated by something that’s all too easy to manipulate: software.

    Hardware defects, whether they are engines placed in the wrong place on a plane or O-rings that turn brittle when cold, are notoriously hard to fix. And by hard, I mean expensive. Software defects, on the other hand, are easy and cheap to fix. All you need to do is post an update and push out a patch. What’s more, we’ve trained consumers to consider this normal

    I believe the relative ease—not to mention the lack of tangible cost—of software updates has created a cultural laziness within the software engineering community. Moreover, because more and more of the hardware that we create is monitored and controlled by software, that cultural laziness is now creeping into hardware engineering—like building airliners.

    Boeing is in the process of rolling out a set of software updates to the 737 Max flight control system, including MCAS.

    Nowhere is this problem more acutely felt than in systems designed to augment or improve safety. Every increment, every increase in complexity, ultimately leads to decreasing rates of return and, finally, to negative returns. Trying to patch and then repatch such a system in an attempt to make it safer can end up making it less safe.

    This is the root of the old engineering axiom “Keep it simple, stupid” (KISS) and its aviation-specific counterpart: “Simplify, then add lightness.”

    Now software stands between man and machine, and no one seems to know exactly what is going on. Things have become too complex to understand.

    In the 737 Max case, the rules were also followed. The rules said you couldn’t have a large pitch-up on power change and that an employee of the manufacturer, a DER, could sign off on whatever you came up with to prevent a pitch change on power change. The rules didn’t say that the DER couldn’t take the business considerations into the decision-making process. And 346 people are dead.

  16. Tomi Engdahl says:

    Sovellusinsinöörin rooli pienenee

    Nykysuunnittelija on tottunut hakemaan tietoa netin kautta ja ostamaan tarvitsemansa komponentit verkkokaupasta. On selvää, että perinteisen sovellusinsinöörin tai FAE-insinöörin rooli pienenee koko ajan, sanovat myyntiään nopeasti kasvattaneen Mouser Electronicsin Euroopan nokkamiehet Mark Burr-Lonnon (vas.) ja markkinointijohtaja Graham Maggs.

  17. Tomi Engdahl says:

    The Case For Embedded FPGAs Strengthens And Widens

    Combining the flexibility of a FPGA with the performance and cost benefits of an SoC is pushing this technology well into the mainstream.

  18. Tomi Engdahl says:

    Leverage object-oriented industrial programming

    Plants and equipment are assembled from objects, so controls architecture should be too. New tools help industrial programmers deliver the productivity of object-oriented programming (OOP) without the complexity.

    New object-oriented industrial programming (OOIP) techniques deliver the productivity gains of object-oriented programming (OOP) while maintaining the ease-of-use and reliability required for industrial controls applications.

    OOP for industrial controls

    The industrial controls and computer science communities tend to differ on OOP interpretation. To understand OOIP, it’s important to note its key differences with OOP.


    Includes the full suite of computer science OOP features
    Is primarily text-based
    Is typically the domain of highly educated computer scientists.


    Has the ability to instantiate function blocks (FB) into other FBs using the concepts of encapsulation, instantiation, and abstraction
    Is primarily graphics-based
    Is usable by controls engineers and plant technicians with minimal training.

  19. Tomi Engdahl says:

    Rushing To The Edge

    Why the next big thing is unnerving tech giants and pushing design in new directions.

  20. Tomi Engdahl says:

    Tips and Tricks for Successful IoT Software Development

    Ideally, you need an approach that results in software that drives IoT solutions for the future, while keeping the users’ evolving needs in mind and delivering on the promise and benefits of connectivity.

    How is this accomplished?

    Test Often, Gather Feedback, Iterate

    Testing and gathering critical feedback is what makes product development a success. You want to get a version of the software into as many users’ hands as soon as possible and be prepared to address their feedback.

    An iterative, cross-platform software collaboration, born out of the agile methodology, is more advantageous due to its flexibility and direct connection to the end user. An iterative approach is micro-goal driven, with an easy process in place to adjust to changing requirements. This improves your team’s ability to accurately and efficiently manage costs, and it provides the quickest route to market.

    Unlike waterfall, where there is a sequential, straight-line process, agile addresses every component in the stack in a series of continuous, quick-moving sprints that deliver an improved, market-ready product faster. The project moves in manageable pieces. There are no surprises lurking at the end of the process.

    Communication is vital to the collaborative and iterative agile approach. Developers should be in ongoing contact with the customer through daily scrums, biweekly planning meetings and biweekly reviews.

  21. Tomi Engdahl says:

    Safety-Critical Coverage

    Verification in automotive, medical and industrial designs.

  22. Tomi Engdahl says:

    Redefining Expectations for Test

    How to tackle testing automotive and AI systems

  23. Tomi Engdahl says:

    Leverage object-oriented industrial programming

    Plants and equipment are assembled from objects, so controls architecture should be too. New tools help industrial programmers deliver the productivity of object-oriented programming (OOP) without the complexity.

  24. Tomi Engdahl says:

    5 Lessons to Learn from the Boeing 737 MAX Fiasco

    Although it will be months before we have full reports about the 737 MAX crashes, we don’t have to wait to draw lessons from those incidents.

    Lesson #1 – Don’t compromise your product to save or make money short-term

    Lesson #2 – Identify and mitigate single points of failure

    Lesson #3 – Don’t assume your user can handle it

    Lesson #4 – Highly tested and certified systems have defects

    Lesson #5 – Sensors and systems fail

  25. Tomi Engdahl says:

    Traditional development methods do not scale into the IoT sphere. Strong inter-dependencies and blurred boundaries among components in the edge device stack result in fragmentation, slow updates, security issues, increased cost, and reduced reliability of platforms.


  26. Tomi Engdahl says:

    What is a developer journal?

    Solve your future problems faster by logging the most useful things you’ve already learned.

  27. Tomi Engdahl says:


    As technology grows more and more powerful, tech companies need to prepare for sometimes unexpected ethical issues.

    Here are four things to consider when seeking to build ethically sound digital services.





    By following the discussion around the topics above, it seems that the current ethical principles are drawn from the following sources: human rights, laws and regulations such as GDPR – and last but not least, the social responsibility of individual companies.

    Besides the official regulations, we need to start building an environment of trust when it comes to technology. This could even be seen as an expansion of the ethics courses currently offered by our public schools.

  28. Tomi Engdahl says:

    Revolutionize Your Design and Test Workflow

    In the 1990s, agile software development profoundly transformed software development. Agile is far more than a process; it’s a new way to work. Today, a similar transformation is happening in test and measurement: TestOps. Learn about TestOps and how to accelerate your product development workflow.

  29. Tomi Engdahl says:

    JEDEC’s Soft Reset Offers Significant Benefits to Embedded Developers

    The industry standards body JEDEC has defined a serial reset protocol that avoids the need for a dedicated reset pin.

  30. Tomi Engdahl says:

    GitHub Adds New Tools to Help Developers Secure Code

    Microsoft-owned GitHub on Thursday announced the introduction of several new security tools and features designed to help developers secure their code.

    The code hosting service in 2017 launched a new security feature designed to warn developers if the software libraries used by their projects contain any known vulnerabilities. Since the introduction of the security alerts has resulted in significantly fewer vulnerable code libraries on the platform, GitHub has continued to make improvements and it has now announced even more enhancements as a result of a partnership with WhiteSource.

    The partnership helps GitHub broaden coverage of security flaws in open source projects and allows it to provide even more details that should help developers assess and address vulnerabilities.

    Another new tool is Dependency Insights, which helps enterprises gain full visibility into their dependencies — including vulnerabilities and licenses — and better understand their exposure.

  31. Tomi Engdahl says:

    TestOps: How to automate your software pipeline at the speed of DevOps

    TestOps is a combination of Test and Operations (Ops) which is a more evolved version of traditional testing to assure the quality of services. Testing is done on one side, and once complete, the testers effectively throw the delivery over the fence to the operations team who deploy it into production.

    Now, as an alternative to this approach testers need to focus on the live production site to upgrade the quality and have faster results.

    TestOps has innovated the way to carry out testing, combining both the Development Team and Testing Team to have the same role as that of ops. They contribute to speed up the process and support boost the reliability and quality of the product.

    TestOps: What Does This Mean
    Traditionally, devs and testers worked in a clean almost-no-overlap environment. Developers have always been limited to conduct unit testing but, now they are made to build bug-free code and run functional test cases. This made it easier for the testers to focus more on production and high context scenario. Testers now focus on collecting and identifying the right data. They need to set up tools to run the tests in production, check the data, and analyze it.

    TestOps in Product Engineering–global-engineering/products-and-engineering-services/testops/

  32. Tomi Engdahl says:

    The rapidly increasing complexity of today’s designs, combined with schedule pressure to deliver innovative products to market as quickly as possible, strains engineering resources to the limit, often to the point of breaking. As a result, 17% of all projects get canceled, and another 28% miss their target release date.

    Integrated Verification: A Shift-Left Solution for a More Efficient Design Flow

  33. Tomi Engdahl says:

    How the C/C++ <> Shift Operators Work
    By Max Maxfield | Friday, May 24, 2019

    The ways in which the shift operators perform their magic may seem a little daunting when you are first exposed to them, but things are not as bad as they seem.

    Many beginners are confused about the way in which the <> (shift right) operators work in programming languages like C/C++. In this column, all (well, quite a lot) will be revealed, but before we plunge head first into the fray with gusto and abandon, we first need to make sure that we all understand some basic concepts.

  34. Tomi Engdahl says:

    “The dramatic increase in computing power found in microcontrollers means that embedded versions of Python, such as CircuitPython and MicroPython, are becoming increasingly popular among makers.”

  35. Tomi Engdahl says:

    A high-speed network driver written in C, Rust, Go, C#, Java, OCaml, Haskell, Swift, Javascript, and Python.

    Ixy is an educational user space network driver for the Intel ixgbe family of 10 Gbit/s NICs (82599ES aka X520, X540, X550, X552, …). Its goal is to show that writing a super-fast network driver can be surprisingly simple.

  36. Tomi Engdahl says:

    Memory Management Approach for Swapless Embedded Systems

  37. Tomi Engdahl says:

    Start tinkering with the Circuit Playground Express
    Learn what you can do with these tiny gadgets and a bit of Python code.


Leave a Comment

Your email address will not be published. Required fields are marked *