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
C/C++
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
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
Databases
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
Safety
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.
Security
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:
MISCONCEPTION 1: SECURITY BY OBSCURITY IS A VALID STRATEGY
MISCONCEPTION 2: SECURITY FEATURES EQUAL SECURE SOFTWARE
MISCONCEPTION 3: RELIABILITY AND SAFETY EQUAL SECURITY
MISCONCEPTION 4: DEFENSIVE PROGRAMMING GUARANTEES SECURITY
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).
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
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
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
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 YouTube.com and Google.com.
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 appropriate. Examples 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.
Sources
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
Embracing Java for the Internet of Things
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
JavaScript: The Perfect Language for the Internet of Things (IoT)
Anyone using Python for embedded projects?
JavaScript: The Perfect Language for the Internet of Things (IoT)
MICROCONTROLLERS AND NODE.JS, NATURALLY
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?
DEVELOPING SECURE EMBEDDED SOFTWARE
1,687 Comments
Tomi Engdahl says:
Outstanding work! Formal verification of program abstractions is absolutely correct within the modeling framework. Thus, if you can construct a model of your program and you verify that it is correct, then you have a 100% guarantee that the software works according to specifications. No need for testing required. The biggest obstacle to verification of software is and always has been the modeling language and tools (that and the fact that most verification problems are undecidable). Developers are already reluctant to do basic testing [1], let alone modeling and formal verification. Therefore, making the tools and frameworks more intuitive, accessible and easy to use, especially for concurrent programs, is of utmost importance, which this work tries to remedy.
[1] https://www.techrepublic.com/article/software-tests-are-essential-in-improving-quality-but-most-developers-arent-automating-them/
Tomi Engdahl says:
Digital Control in Power Supplies Adds Value to Industry 4.0, IoT Apps
Supply performance can be optimized for applications both on installation and dynamically in operation, with wider systems controlling and monitoring power-supply characteristics for efficient integration.
Tomi Engdahl says:
Open-Source Security: The Good, the Bad, and the Ugly
Some form of open-source software is in almost every commercial product, which is good and bad from a security standpoint.
https://www.electronicdesign.com/altembedded/article/21133709/opensource-security-the-good-the-bad-and-the-ugly?utm_source=EG+ED+IoT+for+Engineers&utm_medium=email&utm_campaign=CPS200619063&o_eid=7211D2691390C9R&rdx.ident%5Bpull%5D=omeda%7C7211D2691390C9R&oly_enc_id=7211D2691390C9R
Tracking a project’s software components is important regardless of whether the code is open source or not. Commercial software used within a project is usually easier to track since a contract is usually involved along with service and support. Open-source software is more of a challenge because one open-source project often depends on other open-source projects. Thus, the issue can cascade into a significant amount of code involved in a project.
Tomi Engdahl says:
https://spectrum.ieee.org/geek-life/hands-on/quickly-embed-ai-into-your-projects-with-nvidias-jetson-nano
Tomi Engdahl says:
Give LEDs, LCDs, and ePaper Displays Custom Fonts with FontEdit
https://www.hackster.io/news/give-leds-lcds-and-epaper-displays-custom-fonts-with-fontedit-69709666f710
This app enables you to import, preview, edit, and export a font for use on embedded systems’ displays.
https://kapusta.cc/2020/03/20/fontedit/
Tomi Engdahl says:
With a low-cost CPLD board, a borrowed oscilloscope, and cheap accessories, an STM8 can have its firmware unprotected with ease.
Hagan Fritsch Unlocks Readout Protection on the STM8 with a Low-Cost Voltage Glitching Setup
https://www.hackster.io/news/hagan-fritsch-unlocks-readout-protection-on-the-stm8-with-a-low-cost-voltage-glitching-setup-b4930678666a
With a low-cost CPLD board, a borrowed oscilloscope, and cheap accessories, an STM8 can have its firmware unprotected with ease.
Tomi Engdahl says:
Built on MicroPython, MicroIDE puts an entire web server and browser-based IDE on an ESP32 — and soon, the ESP8266 too!
MicroIDE Aims to Put an Entire Integrated Development Environment Into Your ESP32 or ESP8266
https://www.hackster.io/news/microide-aims-to-put-an-entire-integrated-development-environment-into-your-esp32-or-esp8266-955d366d6265
Built on MicroPython, MicroIDE puts an entire web server and browser-based IDE on an ESP32 — and soon, the ESP8266 too.
“MicroIDE is an Integrated Development Environment for microcontrollers,” Neufeld writes of the project. “[It's] completely embedded into the firmware. Full access and control over internal/external files. Data visualization and Command Terminal emulation. Simple to add custom modules for rapid development.”
“[MicroIDE] supports ESP32 chips with Wi-Fi (ESP8622 to follow). [It has an] Integrated Web Server (GET & PUT) for read/write, accessible from anywhere via Port Forwarding. Eliminates special software requirements. Wireless editing of code via local website.”
The MicroIDE software is only one half of the puzzle: Neufeld is also working on a custom MicroIDE development board, taking an ESP32 module and fitting it to into a circuit board based on the Arduino Uno form factor.
https://microide.com/
Tomi Engdahl says:
Using OpenAMP to Address Mixed Safety-Critical Systems
https://www.electronicdesign.com/markets/automotive/article/21135976/using-openamp-to-address-mixed-safetycritical-systems
New standards like the OpenAMP Framework let embedded developers take advantage of the features of the MPSoC to separate the safe world from the unsafe world, while maintaining system communications through technologies.
Tomi Engdahl says:
5 Best Practices for Utilizing Open Source Software
https://www.designnews.com/design-software/5-best-practices-utilizing-open-source-software?ADTRK=InformaMarkets&elq_mid=13708&elq_cid=876648
Open source software is everywhere and has the potential to help businesses accelerate development and improve software quality. Achieving these results can be challenging if care is not taken.
Here are five best practices for utilizing open source software successfully.
Best Practice #1 – Use an abstraction layer to remove dependencies
Best Practice #2 – Leverage integrated software when possible
Best Practice #3 – Perform a software audit and quality analysis
Best Practice #4 – Have the license reviewed by an attorney
Best Practice #5 – Select software from an active community
Conclusions
Properly leveraging open source software can dramatically benefit the development team using it. However, in order to be successful, developers need to make sure they select their open source components wisely. This includes abstracting out the component to ensure their application remains flexible and maintainable. It also requires careful review the open source software, assuming it’s not Linux, to ensure quality and general requirements are met before committing to the component.
Following these best practices can help a team avoid a quagmire that results in product delays, a poorly architected solution, quality issues and many other issues that often come up during product development.
Tomi Engdahl says:
Separating process control and safety systems
https://www.controleng.com/articles/separating-process-control-and-safety-systems/?oly_enc_id=0462E3054934E2U
Process safety: Keeping process control and safety systems separate is crucial, but knowing what to separate and integrate and why is critical. Learn about safety instrumented function (SIF) and layers of protection analysis (LOPA).
Tomi Engdahl says:
Vulnerability Management Maturity Model
Taming the beast of Vulnerability Management
https://www.sans.org/blog/vulnerability-management-maturity-model/
You are responsible for the vulnerability management program within your organization. Either as part of a formal program or on an ad-hoc basis, it’s your baby. Except that it isn’t a baby, it is more of an untameable monster, a minotaur in the labyrinth, waiting to surprise you as you turn the corner.
You are not alone. Trust me. There are many people in many organizations that feel this way about their program.
You cannot win at vulnerability management. You can only mature and get better at it.
No, I am not kidding.
You cannot win.
Ever.
Repeat after me. (yes, say it out loud right now)
I cannot win.
Why do I believe that? Vulnerability management is a continuous activity. It will never end, how can you win at it?
Just when you think you have gotten rid of all the problems in your environment, new ones appear. Just when you think you have resolved the process problems, new processes come along. There are always new people coming into the organization that need guidance on the policy suite. New technologies and software are continually released/updated. And don’t even get me going on the speed of changes in the cloud.
Vulnerabilities are like rabbits. You never have just two for long.
Tomi Engdahl says:
In the last few weeks, the LFS editors have been working on a major overhaul of LFS. This work can be reviewed at
[http://www.linuxfromscratch.org/~bdubbs/cross2-lfs-book/](http://www.linuxfromscratch.org/~bdubbs/cross2-lfs-book/)
The elements of building LFS using cross compiling techniques have changed a lot. The old Chapter 5 has been split into three chapters
that have a different focus for each chapter.
Some of the advantages include not requiring a /tools symlink on the host system and not requiring a lot of hackish symlinks when starting the final build system.
In addition, a lot of work was done to minimize the number of test failures in the different packages.
Finally, every page in the new book was reviewed and textual updates made to clarify different elements of the LFS process.
Tomi Engdahl says:
This week, Adam Taylor shows how to configure the Arm Cortex-M1 for debugging with an external JTAG debugger.
MicroZed Chronicles: Debugging the Arm Cortex-M1 and Cortex-M3
https://www.hackster.io/news/microzed-chronicles-debugging-the-arm-cortex-m1-and-cortex-m3-d2e0f8c58821
How to configure the Arm Cortex-M1 for debugging with an external JTAG debugger.
Currently in order to debug an Arm Cortex-M1 or Cortex-M3 core within our Xilinx FPGA, we need to use a separate debugger such as a SEGGER J-Link which I will be using in this example. I do understand, though, this will be changing later in the year with the next Vitis/Vivado release.
The first thing we need to do is enable debug support in the Cortex-M1. I am going to be using JTAG for debug support so I re-customized the IP to support JTAG debugging.
The final thing to do is to make the JTAG pins, TMS, TDI, TDO, TMS, and TRST external and assign them to a suitable connector. I assigned these to IO0 to IO4 on the Arduino shield header.
Tomi Engdahl says:
YOUR MICROCONTROLLER IS YOUR IDE
https://hackaday.com/2020/07/05/your-microcontroller-is-your-ide/
What if your microcontroller IDE was running on the microcontroller itself and not hosted on the computer you use to do the programming? The greatest legacy of Arduino in all its forms has arguably been a software one, in that it replaced annoying proprietary development environments with one that installed easily on a range of operating systems, was easy to use, and above all, worked. The next level of portability is to get rid of any specialize computer-side software. [Ronny Neufeld] wrote MicroIDE for ESP32 as an IDE accessible through a web browser, which interestingly is hosted on the target device itself.
https://microide.com/
Tomi Engdahl says:
VoltLog Addresses a CH341 USB Programmer Design Flaw with a Quick and Easy Hack
Putting out 5V where 3.3V is expected is a problem, but one which can thankfully be fixed with relative ease.
https://www.hackster.io/news/voltlog-addresses-a-ch341-usb-programmer-design-flaw-with-a-quick-and-easy-hack-91fff73012dc
Tomi Engdahl says:
From https://www.facebook.com/groups/electronichobycircuits/permalink/3387338417957510/
Which are the best microcontrollers for industrial application? (should not hanging)
The microcontroller itself doesn’t matter. Pretty much any that has the required features will work fine. It’s the electronics around it and the programming that makes the difference.
If you want a ready made board and don’t want to use actual industrial parts like a PLC, you can look up Industruino. It’s an Arduino uno board with protected 24V logic compatible I/O. It’s still a bit hobby-grade, but better than a regular Arduino.
As for the “not hanging” part, that’s all up to the programming. Program well, and test the code extensively. And make sure you use a watchdog timer to reset the system in case of lockups as a last emergency solution.
Tomi Engdahl says:
$370 million for an integer overflow. The June 4, 1996 Ariane 5 bug: 64 bit float relating to the horizontal velocity of the rocket was converted to a 16 bit signed integer
hownot2code.com/2016/09/02/a-space-error-370-million-for-an-integer-overflow/
Tomi Engdahl says:
RTOS v. OS – Advantages and Disadvantages
https://www.nabto.com/rtos-versus-os-advantages-disadvantages/?utm_source=Facebook&utm_medium=Facebook_annonce&utm_campaign=RTOS_v_OS
When developing a device or system, one of the earliest and most crucial decisions you need to make is deciding what type of operating system it’s going to run off. Linux is often the default OS of choice for many devices and projects, from Android smartphones and smart TVs to game consoles and automobiles.
However, while Linux and other traditional (or standard) operating systems run devices such as these that require intensive memory and processing power, RTOS (or Real Time Operating System) software is often chosen for devices where minimal latency is paramount, or where RAM is limited, to name a few scenarios.
Tomi Engdahl says:
10 software tips for hardware engineers
https://www.edn.com/10-software-tips-for-hardware-engineers/?utm_content=buffer36ee3&utm_medium=social&utm_source=edn_facebook&utm_campaign=buffer
Embedded system design often requires not only an understanding of the hardware but also of how the software affects and interacts with it. Designing hardware requires a certain engineering paradigm that can be a complete polar opposite of designing software. When transitioning from hardware design to include software design, here are ten software tips that hardware engineers should keep in mind when they start developing software.
Tip #1 – Flowchart First, Implement Second
Tip #2 – Use State Machines to Control Program Flow
Tip #3 – Avoid the Use of Global Variables
Tip #4 – Take Advantage of Modularity
Tip #5 – Keep Interrupt Service Routines Simple
Tip #6 – Use Processor Example Code to Experiment with Peripherals
Tip #7 – Limit Function Complexity
Tip #8 – Use a Source Code Repository and Commit Frequently
Tip #9 – Document the Code Thoroughly
Tip #10 – Use an Agile Development Process
Tomi Engdahl says:
There are 5 things you MUST consider:
Validate that Linux will meet your operating system needs.
Be careful not to turn your proprietary IP into OSS.
Don’t let your OSS get out of control. Define a plan for managing Linux and your development tools
Don’t forget about security.
Safety function? Define your risks and follow certification guidelines
Tomi Engdahl says:
https://etn.fi/index.php/13-news/11035-sulautettu-moduuli-joustavasti
Tomi Engdahl says:
Monitoring Chips After Manufacturing
https://semiengineering.com/post-silicon-comprehension/
Adding monitors or traceability into an SoC is not new, but it is beginning to become a huge new opportunity across the entire silicon lifecycle.
New regulations and variability of advanced process nodes are forcing chip designers to insert additional capabilities in silicon to help with comprehension, debug, analytics, safety, security, and design optimization.
The impact of this will be far-reaching as the industry discusses what capabilities can be shared between these divergent tasks, the amount of silicon area to dedicate to it, and the value they may be able to extract from it. New business models may emerge to deal with data ownership.
Is this the next frontier for silicon? “Yes,” says Steve Pateras, senior director for test marketing at Synopsys. “We spent many years trying to optimize designs, tape them out, and then forget about them. We have come to the realization this is no longer possible. You need a methodology, a platform, and an approach that provides a way of monitoring and managing electronics throughout their operational life.”
There are multiple drivers for doing this. “The challenge of ensuring everything is functioning as expected throughout a chip’s lifetime has become more difficult,” says Aileen Ryan, senior director for Tessent portfolio strategy at Mentor, a Siemens Business. “Structural monitoring is required to detect defects, degradations and aging effects. Additionally, there may be functional issues caused by bugs and even malicious attacks which must be detected and mitigated. For chips that are deployed in situations where safety, security and resilience are a priority, it is critical that detection of these issues takes the minimum amount of time.”
This is not just for the benefit of the chip manufacturers. “A big application is preventive maintenance,” says Ansys’ Chang. “Consider unexpected system shutdowns, which can cost a lot of money. If you can catch that before the system breaks down and replace a particular chip or particular PC board, that can save a lot of money. Intentional shutdowns of the system can be done safely, whereas unexpected shutdowns can cause damage. Preventive maintenance can save a lot of money.”
In other industries it is likely to become mandatory. “A new regulation from the United Nations Economic and Social Council, WP.29/GRVA (The Working Party on Automated/Autonomous and Connected Vehicles) is due to go live in January 2021,” says Mentor’s Ryan. “This work relates closely to ISO 21434 and ISO 26262 standards which also address cybersecurity and safety in vehicles – and how these ultimately impact vehicle design and passenger safety. What this means to vehicle OEMs is that they will be automatically and ultimately responsible for the cybersecurity of a vehicle, not only at the point of sale or throughout its warranty period, but throughout its entire lifecycle.”
Tomi Engdahl says:
The programmer’s creedo: “We do these things not because they are easy, but because we thought they were GOING to be easy.”
The project manager’s credo.: “I promised the board it would be delivered next week, now its your problem to deliver it”
Developer’s response: “You get to choose between features, quality, and time to market.”
Harold Dubnow yep, the the project manger just whinges to the board that the developers are not up to the job/not team player and all the other BS they come out with to preserve their job. (usually a good short cut in their case to the door)
Source: https://www.facebook.com/groups/2600net/permalink/2804672866422487/
Tomi Engdahl says:
What Happened To Execute-in-Place?
The concept as it was originally conceived no longer applies. Here’s why.
https://semiengineering.com/what-happened-to-execute-in-place/
Executing code directly from non-volatile memory, where it is stored, greatly simplifies compute architectures — especially for simple embedded devices like microcontrollers (MCUs). However, the divergence of memory and logic processes has made that nearly impossible today.
The term “execute-in-place,” or ”XIP,” originated with the embedded NOR memory in MCUs that made XIP viable. That term is still used, but its meaning has become vague and confused.
“There’s definitely this concept of execute-in-place,” said Mark Reiten, vice president of license marketing for silicon storage technology at Microchip. “Today it’s really more like executing from a caching scheme that allows you to page stuff in rapidly from an external flash. Otherwise, you can’t really operate at a high enough clock speed.”
Memory processes have not been able to keep pace with logic processes. Processor performance scales with each new generation, but memories cannot store code that fast. Various strategies for buffering or caching instructions, which was common in high-speed processors, even is becoming prevalent for all levels of embedded processors. And despite all of the options, there are questions about whether XIP is still a meaningful notion.
NOR on-chip
Whlle servers and desktop computers historically have relied on hard drives (or solid-state drives) for storing code, embedded systems have looked to flash memory – specifically, NOR flash. In earlier times, and even today in lower-performance MCUs, embedding NOR flash meant that, at least for boot code, instructions were delivered directly to the processor, with no need for buffering or caching. “Anything greater than 45nm still uses NOR internally,” said Jim Handy, memory analyst at Objective Analysis.
That makes NOR flash much more attractive for programming than NAND flash, because branches and function calls may interrupt a stream of instructions, and NAND flash must retrieve a page at a time. When embedding flash, MCUs have therefore used NOR flash. As long as the operating frequency is slow enough that the flash access times can keep up, instructions can be fetched and executed directly out of the flash, otherwise known as executed in place.
Embedded NOR memory is still alive and well, although today’s higher volumes are on nodes far from what would be considered leading-edge for logic. “There’s a lot of volume on 55 and 65nm,” said Reiten. “My peak royalty node is still 180nm, but 250, 350 and 500nm are still delivering. 90nm was kind of a weird node. TSMC did it, but a lot of my other partners jumped to 55/65. But we have a nice volume at 90, and 55/65 is going to eclipse it soon. 40 is starting to ramp.”
Capacity for embedded NOR is also less than that what is available in external NOR or NAND.
With access times of around 8ns or less, the more aggressive embedded NOR implementations can support clock speeds of around 120MHz
embedded NOR flash must maintain compatibility with the CMOS logic process from which the MCU is built, and that becomes a limiting factor. “Embedded flash is typically limited to about 40nm,” said Gideon Intrater, CTO at Adesto. “There’s some early availability of 28nm, but it’s very expensive.”
The cost of external NOR flash is about double the cost of NAND flash, according to Syed Hussain, director of segment marketing at Winbond. “NOR flash is less attractive to big business because it’s coming to the end of its Moore’s Law life,”
That higher cost, however, is on a per-bit basis. NAND flash comes in large sizes. If a smaller size is needed than is available in NAND flash, then an external NOR flash device may be less expensive – even if it costs more for each bit.
“External NOR is also cheaper than external NAND for super simple, cost-conscious apps,” said Handy.
Caching changes everything
External NOR flash is unlike embedded NOR flash in one major regard — it’s optimized for size and cost, not for performance. Whereas slower processors could operate directly out of internal NOR flash, external NOR flash latency moved out into the tens-of-microseconds realm. Once a fetched block is streaming, throughput is much faster, and some companies have a continuous streaming mode with two internal buffers. While one is streaming out, the other is fetching a new page for a more or less continuous stream.
But if you were executing directly from the memory, then any branch or loop to an address outside that continuously fed block would incur microsecond latency. That makes executing directly out of memory a complete non-starter.
As a result, most new MCUs have cache. So by definition, you no longer are executing directly out of any non-volatile memory. You’re executing out of the cache. You can keep external NOR in the picture, but the instructions go through the cache en route to the processor. This abstracts the memory speed from the processor speed. The cache is SRAM, which is built out of CMOS logic, so it remains in sync with the selected logic process node.
Meanwhile, NAND has continued to evolve down to about the 15nm node, but the 3D NAND transformation has it moving much farther down the cost and capacity path than would be possible with NOR.
Tomi Engdahl says:
an approach called “shadowing.” In cell phones, for example, NOR flash has been replaced by NAND flash. Because one can’t execute code directly from NAND flash, the code is first transferred from the NAND array into DRAM, and the code is executed from DRAM (via a cache). “NAND flash can be extremely fast,” said Intrater. “We’re talking about NAND flash devices that have interfaces at the gigahertz level.”
Tomi Engdahl says:
Why reference designs are more important than ever
https://www.edn.com/why-reference-designs-are-more-important-than-ever/?utm_source=newsletter&utm_campaign=link&utm_medium=EDNWeekly-20200827
Reference designs have always been prized as handy blueprints from which you can more quickly develop your designs. Increasingly, they’re not just desirable but mandatory to make the sale. It’s easy for us gray-hairs to rant about how designers are getting lazy, or they just don’t make engineers like they used to… but the truth is, as competition increases and design cycles compress, designers are just busier. Anything that speeds up a design is welcome—and reference designs fit the bill perfectly.
Today’s engineers have broader skillsets than their counterparts who began their careers a few decades ago. Back in those days, it was simply more common for engineers to develop areas of specialization. Today’s engineers come up the ranks having learned a wide range of techniques: biasing transistor-level circuits, programming an Arduino or Raspberry Pi board, using sophisticated synthesis tools, and understanding high-level hardware description languages.
However, they may not have as much exposure to the nuances of analog transistor design. Mastering every aspect of the art of electronic design may no longer be tenable.
Tomi Engdahl says:
Intelligent System Design
https://semiengineering.com/intelligent-system-design-2/
How to create unique solutions using intelligent computation and still get to market on time and within budget.
Tomi Engdahl says:
Software Will Determine the Future of Industrial Automation
https://www.electronicdesign.com/industrial-automation/article/21138571/software-will-determine-the-future-of-industrial-automation?utm_source=EG+ED+IoT+for+Engineers&utm_medium=email&utm_campaign=CPS200828023&o_eid=7211D2691390C9R&rdx.ident%5Bpull%5D=omeda%7C7211D2691390C9R&oly_enc_id=7211D2691390C9R
How can we best build software-defined industrial automation? By comparing OPC UA and DDS, how they work, and where they fit.
In the last 20 years, CPUs and networks improved by a factor of 10,000X. According to Moore’s Law, in the next 20 years, they will improve by another factor of 10,000X. During the 40-year design lifecycle of today’s industrial automation (IA) architectures, computers will be a mind-boggling 100,000,000X more powerful. It’s hard to overstate the implications.
Using such power will determine which companies, industries, and even economies win or lose. For today’s designers of tomorrow’s long-lifetime systems, enabling intelligent software is the only significant factor.
In fact, this is already happening. In industry after industry, software is becoming the most valuable part of every system. IA has been an exception to this rule. Nonetheless, like autonomous cars and intelligent medical systems, IA can use sensor fusion, fast distributed reactions, and artificial intelligence (AI) to replace rigid or manual processes with smart autonomy.
Developing architectures seek to solve the problems of the last 20 years, such as reconfiguring workcells, small lot sizes, flexible automation, and vendor interoperability. These will be far more easily solved with flexible software than rigid specifications. The future belongs to software.
The Harsh Truth
Today’s discrete automation systems use a simple hardware-focused architecture. A programmable logic controller (PLC) connects devices over a fieldbus. The PLC controls the devices and manages upstream connections to higher-level software such as human-machine interfaces (HMIs) and historians. Factory-floor software reads sensors, executes logic, and drives actuators, thereby implementing a repetitive operation in a “workcell.” The factory consists of a series of these workcells, each with a few dozen devices.
Workcells aren’t so much programmed as they are configured. Manufacturing engineers or technicians use a palette of devices to implement a function in the cell. The goal of this design is to make it easy to assemble workcells of devices with little software effort. Unfortunately, the goal of minimizing software in plants precludes using advanced computing and intelligent systems. As eloquently put by one industry leader:
“One of the harsh truths about manufacturing software is that it is not developed by software engineers or computer science majors. We would not regularly ask an electrical engineer to design a mechanical system, or a chemical engineer to design an electrical system, but we often ask mechanical, electrical, and chemical engineers to design and develop software systems.”—Brandl, Dennis L. (2012-11-13T22:58:59). Plant IT: Integrating Information Technology into Automated Manufacturing. Momentum Press.
Brandl’s “harsh truth” simply can’t continue. Superior custom software will take its place above reliability, performance, and interoperability as the key to competition. That means industrial companies will need to write their own code with competitive, professional software teams. You can’t win a software war with someone else’s software.
How can we enable this future? First, we need to understand the available industrial architectural frameworks. Then, we can put them together to enable software-driven IA.
What are OPC UA and DDS?
The top industrial architectural frameworks are the OPC Unified Architecture (OPC UA, managed by the OPC Foundation), and the Data Distribution Service (DDS, managed by the Object Management Group). Both have widespread adoption in industrial systems, although not in the same use cases (Fig. 1). DDS finds traction in applications in medical systems, transportation, autonomous vehicles, defense, power control, robotics, and oil and gas. OPC UA is also used in many of these industries, but not in the applications. Rather, OPC UA is mostly employed in discrete automation and manufacturing. In practice, there’s almost no overlap in use cases.
DDS supports publish subscribe, as does the new specification for OPC UA “PubSub.” But OPC UA does not—and will never—do what DDS does. DDS is fundamentally a software-development architecture; OPC UA is not. Thus, the question isn’t about choosing DDS or OPC UA. The question is understanding what they do and deciding which one is needed for your design, or if you need both.
DDS evolved as a software-development framework for control systems.
By contrast, OPC UA grew up in the plant environment where, as Brandl points out, software engineers are rare. Its prime goal was to help PLC-centric workcell designs select different vendor hardware without writing software. The workcells endlessly repeat an operation, but they’re not truly “smart.” OPC UA seeks to minimize, rather than enable, software development.
We must differentiate integrating existing software components from writing new software. OPC UA supports software integration of modules like HMIs and historians. However, it offers no facility for composing intelligent software modules. It’s not a software-development architecture for distributed applications.
What Does OPC UA PubSub Do?
OPC UA PubSub is a simple way to send information from a publisher to many subscribers. A publisher collects a “DataSet” at regular intervals and writes it to its subscribers. A DataSet is pulled out of the OPC UA information model, essentially a list of key-value pairs. On the other end, the Subscriber unpacks it and pushes it into the UA information model. There’s also support for simple structured data types.
Most users plan to use OPC UA PubSub with the UDP transport.
OPC UA PubSub also supports other non-real-time messaging middleware options, MQTT and AMQP.
Fundamentally, OPC UA PubSub offers a simple mechanism to connect variables on a set of tightly coupled devices. Every device gets the same data at the same rates at the same time. With the right companion specifications, it can ensure device interoperability. UA PubSub is very new; there are few deployed applications.
Tomi Engdahl says:
Fast Functional-Safety Certification for Your Project
https://www.electronicdesign.com/technologies/embedded-revolution/article/21140833/fast-functionalsafety-certification-for-your-project
Getting an application functional-safety-certified is often a very difficult process, requiring multiple steps along with testing to complete the functional-safety “checklist.” This article reviews ways to fast-track certification.
Tomi Engdahl says:
Linux and Security for Today’s Embedded Medical Devices
https://www.machinedesign.com/medical-design/article/21140820/linux-and-security-for-todays-embedded-medical-devices
Discover how embedded developers can ease development of advanced Linux-based medical devices for reliability and safety.
Electronics and software going into medical devices has become increasingly more sophisticated. Platforms utilizing embedded Linux are also common these days. Likewise, safety and security remain paramount for medical devices.
Scot, how can Linux open-source software be used for medical device safety?
Linux has been deployed safely in a wide variety of medical devices, but to use Linux in a medical device that has a safety requirement, embedded developers need to follow the process defined by the certification standard for compliance and certification.
So, can Linux be pre-certified for use in a medical device?
Not really. Certain real-time operating systems (RTOSs) such as the Nucleus RTOS from Mentor, can be acquired pre-certified, as can other embedded software components from a number of vendors. To achieve this kind of pre-certification, the vendor must be able to show that the complete software development process—requirements, design, development, testing and verification, and all of the steps of development—has been performed to medical industry standards such as ISO 13485 and/or IEC 62304. Linux and other open-source components aren’t developed to these standards, so they’re not pre-certified.
There have been efforts to show conformance of Linux to the over-arching concepts of functional safety, like mapping to IEC 61508, from which many industry standards are derived, including IEC 62304. While this approach isn’t successful, Project ELISA, a current process, is showing promise by improving the processes for open-source software development, and in mapping the higher-quality output to these standards. However, this promise is likely years away from being completely realized.
What are embedded developers relying on now to ensure the safety of their Linux-based medical devices?
Instead of pre-certification, Linux is generally handled using a concept from IEC 62304 called Software of Unknown Providence, or SOUP, for today’s medical devices. Under these guidelines, Linux is considered as part of the risk assessment of the overall device, and potential failures of Linux as used in the device must be considered, and mitigated, if they might cause harm to a patient. This risk assessment must meet the requirements of the FDA’s pre- and post-submission guidance.
So, on the front end, it requires considerations on the use of Linux in the design, implementation, testing and verification of the device. Then, the use of Linux, and all open-source software, must consider the possibility that issues will be found after product release. Certifiers are taking a very close look at this aspect of open source, especially as far as security issues are concerned.
Both safety and security are necessary when we’re looking at medical devices. We hear that you can’t have safety without security, but why is that?
Security is something that can be looked at as standalone. Even in medical devices, not all aspects of security are tied to safety. For example, when we talk about protecting someone’s personal information, this is an aspect of security that doesn’t overlap with safety. But when we talk about safety, things that could go wrong will impact the patient’s health. If the device isn’t secure, it makes it possible for bad actors to make these negative impacts happen either accidentally—or purposefully.
Does the use of Linux and other open-source software help protect these devices?
Linux is the most heavily used operating system for devices with a large, worldwide developer base. This global developer community focuses on ensuring that Linux works as expected in all conditions, and that it’s as secure as possible.
How is it possible that Linux can have so many security flaws that we’re always finding more?
Linux and other major open-source packages like OpenSSL or SQLite are large packages that can have unpredictable interactions with other software running in the same system. This is combined with the fact that many flaws are hard to find in code reviews, normal testing or by static analysis. And they’re undetectable unless software is combined with task switching and inter-process communication. Best practices will not identify every possible flaw or exploit, and much of the open-source software that we rely on was not originally developed with today’s best practices in place.
However, the most important pieces of open-source software used in devices worldwide are much more stable and secure now, compared to five years ago. This is mainly due to the hard work and diligence of engineers all over the world in identifying avenues of exploitation, fixing those when they find them, and with the worldwide community looking for similar issues in their own projects. The work will never be complete, but it’s becoming harder and harder to find exploitable flaws in this important infrastructure software.
What happens when a security issue is found in Linux?
Security issues in Linux, including other important software like OpenSSL, are found by engineers either by happenstance, like a bug that they uncover during a project, or through concerted efforts to find exploits, like “white hat” hacking. Or, an exploit will be found during a post-mortem analysis of an attack, but that’s uncommon.
In either case, the exploit discoverer will notify the community of the offending open-source component. Then, the discoverer or Linux community member will notify the Common Vulnerability and Exposures (CVE) group, run by MITRE, an organization closely related to the U.S. National Vulnerability Database (NVD) that’s managed by the National Institute of Standards and Technology (NIST).
Once a vulnerability is understood and a fix is available, the CVE is publicized by inclusion in these lists. If the exploit is sufficiently serious, the issue is discussed by the security community worldwide. This is the point where devices are potentially most vulnerable. Since most vulnerabilities are found by the “good guys,” the bad actors will find out about them as will the rest of the world. These bad actors can then deploy exploitations that take advantage of the newly found vulnerability.
That said, this publicity is very important, since it alerts the worldwide community of both the issue and the fix. Thus, an organization can determine if a particular exploit might affect their devices, and if it is, they can mitigate the issue before it may be attacked. Of course, not everybody will be able to update their devices, which will leave them open to attacks. But since there are no real secrets in the world, this openness prevents more issues than it causes.
Back to safety. How safe is Linux?
An operating system like Linux doesn’t directly do anything to make a device safer. The operating system doesn’t prevent a failure from occurring, nor does it make the system recover when a failure occurs.
It’s not doing anything until applications that leverage Linux are running, and it’s those applications that contribute to the overall safety of the device. While an operating system isn’t a safety mechanism, it enables them and is considered to be a safety element.
With today’s advanced and affordable microprocessors, how does a multiprocessor system affect safety?
Today’s microprocessors are powerful and complex, designed to support heterogeneous multiprocessing. They comprise powerful general-purpose cores to run an OS like Linux, and more specialized cores to handle other functions. Designing for safety is an integrated systems issue, not just hardware or software.
To take full advantage of the board BOM costs and higher integration of components in an advanced multiprocessor for a safety-sensitive design, applications must be kept separate—what’s known as mixed-safety criticality.
Simultaneously, the safety-critical portion of the system runs on a separate cluster dedicated to real-time processing. It has features like tightly coupled data and instruction memory with extremely low fetch cycles, and highly deterministic performance, or lockstep mode for error detection.
Advanced multiprocessing systems contain hardware-enforced isolation that keep the application world and the safety-critical world separate. However, the software designer must use middleware such as the Mentor Hypervisor or Mentor Multicore Framework to take advantage of those hardware features.
Tomi Engdahl says:
Codespaces For Embedded Development
https://hackaday.com/2020/09/07/codespaces-for-embedded-development/
We can sympathize with [Benjamin Cabé]. He has a lot of development boards and it has become painful to maintain the many toolchains for each board. We’ve also suffered from upgrading one tool breaks another tool in some obscure way. His solution? Use Github Codespaces which you can get early access for beta testers.
The idea is that you can spin off a container-specific to a GitHub repository that has all the proper versions and dependencies required to work with a project.
https://www.youtube.com/watch?v=-enIM4x-KPA&feature=emb_logo
Tomi Engdahl says:
Meeting Increasing Performance Requirements in Embedded Applications with Scalable Multicore Processors
https://www.eetimes.com/meeting-increasing-performance-requirements-in-embedded-applications-with-scalable-multicore-processors/
There is a transformation occurring in high-end embedded applications as processing spreads from the cloud to the edge and the end points of the Internet. Performance requirements are increasing rapidly and changing the architecture of processors and how they are implemented in designs. This is behind the increased use of multicore processors to deliver higher performance. Most high-end processors today are available with support for dual- and quad-core configurations. There are a few that support up to eight CPU cores, but even this won’t deliver the performance needed for emerging applications in storage, automotive, networking, and 5G. Next-generation embedded applications need scalable support for larger CPU clusters and specialized hardware accelerators to deliver the required performance. Large multicore processors will require a new architectural approach to enable higher performance and not create additional implementation and timing closure problems for embedded designers.
Embedded Performance Challenges
It is no secret that advanced process nodes no longer deliver the higher clock speeds and lower power consumption that they once did. For many process generations logic speeds have continued to increase but memory access times have not (Figure 1). The speed-limiting paths in processors are almost always through memory. This is a situation that is not likely to change for future process nodes because of the very real limitations of semiconductor physics.
Tomi Engdahl says:
Formal Verification Becoming Critical To Auto Security, Safety
Obstacles remain, but adoption is growing.
https://semiengineering.com/formal-verification-becoming-critical-to-auto-security-safety/
Formal verification is poised to take on an increasingly significant role in automotive security, building upon its already widespread use in safety-critical applications.
Formal has been essential component of automotive semiconductor verification for some time. Even before the advent of ADAS and semi-autonomous vehicles — and functional safety specifications like ISO 26262 and cybersecurity specifications like ISO/SAE 21434 — digital system content in cars was growing fast. Leading automotive IC providers such as Bosch and Infineon have been using formal verification as part of their verification flows for years. In fact, early mainstream formal adoption meshed well with needs of automotive chipmakers, which started with system control ICs.
“Automotive systems consist of networked ECUs connected by a CAN bus,” said Pete Hardee, director of product management at Cadence. “This has introduced many scenarios in which connected systems can interact. And that has presented many driver usability advantages, while also introducing many potential failure modes and attack vulnerabilities for safety-critical systems that must be taken into account.”
Hardee noted that few of these modes are easily covered by verification methods that consider verifying intended functionality. “There are perhaps some failure scenarios the verification engineer can conceive, plus some ‘constrained random’ variants of the resultant tests such as those common in UVM-based verification,” he said. “But failure modes and vulnerabilities manifest themselves in ways often totally unrelated to the known functionality of these systems.”
Tomi Engdahl says:
Is DVFS Worth The Effort?
Dynamic voltage and frequency scaling can save a lot of power and energy, but design costs can be high and verification difficult.
https://semiengineering.com/is-dvfs-worth-the-effort/
Tomi Engdahl says:
Dealing With Device Aging At Advanced Nodes
Gaps remain, but understanding about how circuits age and what to do about it is improving.
https://semiengineering.com/dealing-with-device-aging-at-advanced-nodes/
Tomi Engdahl says:
Deciding to use a hypervisor or a multicore framework, or both, to control and manage a multicore system is a critical architecture decision. Read more in this white paper to learn if a hypervisor is required or is a multicore framework a better solution for your specific application requirements.
https://www.mentor.com/embedded-software/resources/overview/multicore-system-management-hypervisor-or-multicore-framework–7127ede5-29be-482c-8894-f9f434dc6686?uuid=7127ede5-29be-482c-8894-f9f434dc6686&clp=1&contactid=1&PC=L&c=2020_09_10_esd_multicore_framework_wp_v2
Tomi Engdahl says:
Digital pregnancy tests are almost as powerful as the original IBM PC
A lot of computer to read an old-fashioned pee stripÅ
https://www.theverge.com/tldr/2020/9/4/21422628/digital-pregnancy-test-teardown-processor-ram-ibm-pc
Tomi Engdahl says:
Integrity Problems For Edge Devices
https://semiengineering.com/integrity-problems-for-edge-devices/
Noise becomes a significant issue at older nodes when voltage is significantly reduced, which is a serious issue for battery-powered devices.
Battery-powered edge devices need to save every picojoule of energy they can, which often means running at very low voltages. This can create signal and power integrity issues normally seen at the very latest technology nodes. But because these tend to be lower-volume, lower-cost devices, developers often cannot afford to perform the same level of analysis on these devices.
Noise can come in many forms. Some of it is static, some is dynamic.
Static noise may be due to things like process variation. “Variation is a huge issue,” says Mo Faisal, president and CEO of Movellus. “If you are running your chip near threshold, your variation from slow corner to fast is no longer 2 or 3 times. It could be up to 20 times.”
Dynamic noise comes from thermal shot noise, interference, imperfect power supplies, and many other sources. “It’s not necessarily that low voltage designs are more susceptible. It is that the noise that they are susceptible to is likely to cause the product to fail,” says Brad Griffin, product management group director for multi-physics system analysis at Cadence. “If the voltage swing is 5 volts, you have a lot of margin for noise. But if the voltage swing is 0.8 volts, you don’t have nearly as much margin.”
Analog circuitry can be more susceptible to noise than digital. “The big challenge for us is around the analog, especially that associated with wireless interfaces,”
Tomi Engdahl says:
Dealing With Device Aging At Advanced Nodes
Gaps remain, but understanding about how circuits age and what to do about it is improving.
https://semiengineering.com/dealing-with-device-aging-at-advanced-nodes/
Tomi Engdahl says:
n the past, aging and stress largely were separate challenges. Those lines are starting to blur for a number of reasons. Among them:
In automotive, advanced-node chips are being used in extreme environments and expected to function reliably for up to 18 years. Likewise, in carrier-class equipment, chips are being subject to heat and cold and expected to last at least a decade or two.
Margin, which has been used to buffer some of the causes of aging and stress, is shrinking in many designs at 7/5/3nm due to relentless demands for lower power and higher performance.
More designs are becoming heterogeneous, raising the possibility that not everything in a multi-chip package will age at the same rate, particularly under different use cases and applications.
If design teams are lucky, problems will show up early in production and they can be fixed before chips are released to the market. But more often than not, issues will take years to materialize as circuits age and something eventually breaks down.
https://semiengineering.com/dealing-with-device-aging-at-advanced-nodes/
Tomi Engdahl says:
Why We Should Build Software Like We Build Houses
https://www.wired.com/2013/01/code-bugs-programming-why-we-need-specs/
Architects draw detailed plans before a brick is laid or a nail is hammered. But few programmers write even a rough sketch of what their programs will do before they start coding. Some may argue that the analogy between specifications and blueprints is flawed because programs aren’t like buildings: Tearing down walls is hard but changing code is easy. But changing code is hard — especially if we don’t want to introduce bugs.
Why We Should (Absolutely Never) Build Software Like We Build Houses
https://www.schneems.com/2014/03/14/why-we-should-never-build-software-like.html
Tomi Engdahl says:
https://www.microsoft.com/en-us/research/publication/build-software-like-build-houses/
Tomi Engdahl says:
https://hackaday.com/2020/07/05/your-microcontroller-is-your-ide/
Tomi Engdahl says:
https://hackaday.com/2020/08/04/dont-let-endianness-flip-you-around/
Tomi Engdahl says:
https://hackaday.com/2020/08/03/optimizing-gif-playback-for-microcontrollers/
Tomi Engdahl says:
https://etn.fi/index.php/13-news/11004-ledi-vilkkumaan-alle-100-tavun-koodilla
Tomi Engdahl says:
https://hackaday.com/2020/06/29/implementing-the-exponential-function/
Tomi Engdahl says:
https://hackaday.com/2020/07/02/easy-secure-https-with-an-esp8266/
Tomi Engdahl says:
Beyond Printf(): Better Logging Practices For Faster Debugging
https://hackaday.com/2020/07/21/beyond-printf-better-logging-practices-for-faster-debugging/
Tomi Engdahl says:
Polymorphic String Encryption Gives Code Hackers Bad Conniptions
https://hackaday.com/2020/07/27/polymorphic-string-encryption-gives-code-hackers-bad-conniptions/
When it comes to cyber security, there’s nothing worse than storing important secret data in plaintext. With even the greenest malicious actors more than capable of loading up a hex editor or decompiler, code can quickly be compromised when proper precautions aren’t taken in the earliest stages of development. To help avoid this, encryption can be used to hide sensitive data from prying eyes. While a simple xor used to be a quick and dirty way to do this, for something really sophisticated, polymorphic encryption is a much better way to go.
An extension for Visual Studio Code, it’s capable of encrypting strings and data files in over 10 languages. Using polymorphic encryption techniques, the algorithm used is unique every time, along with the encryption keys themselves. This makes it far more difficult for those reverse engineering a program to decrypt important strings or data.
How to encrypt strings & files in your source code?
https://dev.to/pelock/how-to-encrypt-strings-files-in-your-source-code-25e