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,686 Comments
Tomi Engdahl says:
No, Linux isn’t always best for IoT
https://betanews.com/2024/07/09/no-linux-isnt-always-best-for-iot/#google_vignette
Ask a connected device developer which operating system they prefer and most — about three-quarters to be exact — will reply with Linux. The open-source system is far and away the king of the Internet of Things (IoT) thanks to its flexibility and support for various architectures.
But there’s a problem. Simple, single-function devices like smart thermostats or connected bird feeders often don’t require the robust processing power of Linux. Loading these devices with multi-tasking capabilities can be inefficient and potentially risky. Recent reports of backdoor vulnerabilities in Linux, for example, raise concerns about its attack surface and open-source origins.
This matters since experts predict a major IoT growth spurt over the next five years. Driven by 5G adoption, infrastructure investment, and AI-native applications, the market for connected devices worldwide is set to double to almost $1 trillion. As devices only grow in the modern smart home and office, developers should keep in mind there’s an operating ecosystem beyond Linux.
The problem with Linux
Now don’t get me wrong. Linux is a great operating system (I’ve personally been on board since version 0.9x of the kernel) and there’s a reason why it dominates in this space. There’s something to be said for its architecture, compatibility, affordability, accessibility, and many other features. But, and it’s a big but, this doesn’t mean it’s suited for every connected device.
This is down to three major reasons.
First, today’s devices are increasingly simple. We’re now connecting everything from baby monitors and doorbells to vacuum cleaners and even ovens. Most of these devices perform single or basic functions, making a full-featured operating system like Linux unnecessary. Ironically, this approach would have been impractical a decade ago due to resource limitations. Now, Linux is the OS go-to despite often being overkill.
Second, there’s the lingering question of cybersecurity. Linux recently experienced a major incident when a remote code execution vulnerability was discovered in XZ Utils, a widely used compression library. As I recently wrote, if left undetected, this flaw threatened to allow attackers to bypass authentication and gain full system access. More alarmingly, the backdoor was introduced by a long-time, trusted collaborator, raising concerns over whether the sprawling nature of Linux and its subsystems has become so vast that malicious code can be injected without detection.
Third, real-time operating systems (RTOS) have matured significantly in recent years, particularly in internet protocol support. With robust IP stacks like lwIP and security suites such as mbedTLS, RTOS now allows developers to implement secure web servers and meet industry standards for encryption and networking on resource-constrained devices.
The potential of RTOS
For device developers seeking a lean, focused alternative, RTOS players like Zephyr, FreeRTOS, and ThreadX are gaining traction. These market leaders compile applications directly into the OS, minimizing overhead and attack surfaces compared to dynamically loaded programs in Linux.
This architecture makes RTOS ideal for time-sensitive applications requiring low latency and deterministic performance, like industrial automation or medical devices. Since code runs with minimal abstraction layers, RTOS can deliver mission-critical responsiveness unachievable with general-purpose builds.
Moreover, RTOS benefits developers optimizing for constrained hardware. The small footprint and targeted functionality mean responsive devices can run on minimal memory and processing power.
What developers should do now
My request to developers is simple: deeply consider your device’s needs and resource constraints before defaulting to Linux. This is easy to determine by asking two key questions: How many concurrent tasks will the device run? And how much memory do those processes require? Armed with these answers, you can objectively evaluate if an OS or RTOS is right for you.
Expand your operating system horizons and make evaluated decisions for each project’s unique needs. You can do this by considering factors like processing power, memory constraints, determinism requirements, and long-term goals. An open-minded and unbiased assessment may reveal RTOS as the superior choice for delivering a secure, high-performance embedded device tailored to its intended use case. It’s an IoT debate worth having.
Tomi Engdahl says:
https://etn.fi/index.php/13-news/16398-neljae-64-bittistae-risc-v-ydintae-sulautettuihin
Verkon reunalla toimivissa laitteissa tarvitaan usein 64-bittisiä suorittimia, joissa voidaan ajaa rinnan esimerkiksi Linuxia ja reaaliaikaisia käyttöjärjestelmiä. Microchip vastaa näihin vaatimuksiin uudella 64-bittisellä moniytimisellä RISC-V-mikroprosessorillaan.
PIC64-lanseerauksen myötä Microchipistä tulee käytännössä ainoa ohjainpiirien toimittajan, jonka tuotevalikoima kattaa kaiken 8-bittisistä suorittimista 64-bittisiin. Yhtiön toimitusjohtaja Ganesh Moorthyn mukaan PIC64GX on vasta alkua. Luvassa on useita 64-bittisiä MPU-piirejä eri markkinasegmentteihin.
PIC64GX on samalla Microchipin ensimmäinen 64-bittinen RISC-V-neliydinprosessoria, joka tukee asymmetristä moniprosessointia. Lisäksi suoritin tukee determinististä latenssia eli datan liikuttelu ja sen prosessointi tehdään aina ennustettavassa ajassa.
PIC64GX-perhe on nastoitukseltaan yhteensopiva Microchipin PolarFire-sarjan FPGA-järjestelmäpiirien kanssa
Perusversio lisäksi Microchip esitteli avaruussovelluksiin tarkoitetun PIC64-HPSC-sarjan (High-Performance Spaceflight Computing).
PIC64-portfolionsa käyttöönoton myötä Microchipistä on tullut ainoa sulautettujen ratkaisujen toimittaja, joka kehittää aktiivisesti 8-, 16-, 32- ja 64-bittisiä mikro-ohjaimia (MCU) ja mikroprosessoreita (MPU). Tulevat PIC64-perheet sisältävät RISC-V- ja Arm-arkkitehtuureihin perustuvia piirejä.
Uutta PIC64GX-perhettä tukee PIC64GX Curiosity -evaluointisarja ja kehiutys onnistuu tutusti MPLAB-työkaluilla. Nykyään kehitys onnistuu laajennusten ansiosta myös Microsoftin VS Code -työkaluilla. Linuxin puolelta PIC64-piirjeä tukevat esimerkiksi Canonicalin Ubuntu, Yocto Project ja Buildroot, joiden rinnalla voidaan käyttää Zephyr-RTOS:ia ja siihen liittyviä ohjelmistopinoja.
Tomi Engdahl says:
Embedded Python: MicroPython Is Amazing
https://hackaday.com/2024/07/11/embedded-python-micropython-is-amazing/
In case you haven’t heard, about a month ago MicroPython has celebrated its 11th birthday. I was lucky that I was able to start hacking with it soon after pyboards have shipped – the first tech talk I remember giving was about MicroPython, and that talk was how I got into the hackerspace I subsequently spent years in. Since then, MicroPython been a staple in my projects, workshops, and hacking forays.
If you’re friends with Python or you’re willing to learn, you might just enjoy it a lot too. What’s more, MicroPython is an invaluable addition to a hacker’s toolkit, and I’d like to show you why.
Hacking At Keypress Speed
Got a MicroPython-capable chip? Chances are, MicroPython will serve you well in a number of ways that you wouldn’t expect. Here’s a shining example of what you can do. Flash MicroPython onto your board – I’ll use a RP2040 board like a Pi Pico.
This interactivity is known as REPL – Read, Evaluate, Print, Loop. The REPL alone makes MicroPython amazing for board bringup, building devices quickly, reverse-engineering, debugging device library problems and code, prototyping code snippets, writing test code and a good few other things. You can explore your MCU and its peripherals at lightning speed, from inside the MCU.
There’s many things that make MicroPython a killer interpreter for your MCU. It’s not just the hardware abstraction layer (HAL), but it’s also the HAL because moving your code from board to board is generally as simple as changing pin definitions. But it’s all the other libraries that you get for free that make Python awesome on a microcontroller.
Batteries Included
It really is about the batteries – all the libraries that the stock interpreter brings you, and many more that you can download. Only an import away are time, socket, json, requests, select, re and many more, and overwhelmingly, they work the same as CPython. You can do the same r = requests.get(“https://retro.hackaday.com”); print(r.text)[:1024] as you would do on desktop Python, as long as you got a network connection going on. There will be a few changes – for instance, time.time() is an integer, not a float, so if you need to keep track of time very granularly, there are different functions you can use.
Say, you want to parse JSON from a web endpoint. If you’re doing that in an Arduino environment, chances are, you will be limited in what you can do, and you will get triangle bracket errors if you mis-use the JSON library constructs because somehow the library uses templates; runtime error messages are up to you to implement. If you parse JSON on MicroPython and you expect a dict but get a list in runtime, it prints a readable error message. If you run out of memory, you get a very readable MemoryError printed out, you can expect it and protect yourself from it, even fix things from REPL and re-run the code if needed.
Mind The Scope
In my experience, the single biggest problem with MicroPython is that writing out `MicroPython` requires more of my attention span than I can afford. I personally shorten it to uPy or just upy, informally. Another problem is that the new, modernized MicroPython logo has no sources or high-res images available, so I can’t print my own stickers of it, and MicroPython didn’t visit FOSDEM this year, so I couldn’t replenish my sticker stock.
On a more serious note, MicroPython as a language has a wide scope of where you can use it; sometimes, it won’t work for you. An ATMega328P can’t handle it – but an ESP8266 or ESP32 will easily, without a worry in the world, and you get WiFi for free. If you want to exactly control what your hardware does, counting clock cycles or hitting performance issues, MicroPython might not work for you – unless you write some Viper code.
http://python.lv/2014-10-05-recap.html
Tomi Engdahl says:
Toys! – 32bit multicore microcontrollers. The power of a 90s PC on a teeny weeny board.
Tomi Engdahl says:
End of the Line for Arm’s Mbed OS
Arm has officially pulled the plug on their long ignored Mbed OS. But what will this mean for Arduino who rely heavily on the now dead OS?
https://www.hackster.io/news/end-of-the-line-for-arm-s-mbed-os-7027e92805e7
Yesterday, Arm formally announced that they were pulling the plug on Mbed OS. The end of life announcement gave their IoT operating system a year to live, with an official end-of-life date in July 2026.
The writing has been on the wall for Mbed OS for some time, with the project’s Github having untriaged issues dating back several years, and with many complaining that the the operating system was being ignored. The Mbed online compiler was deprecated back in 2021, and then eventually retired in 2022, and rumours of the OS’ demise and layoffs in the Mbed team have been circulating ever since.
“Embedded and IoT development has evolved and scaled significantly since Mbed was introduced, and projects supported by Arm like micro:bit, Arduino, and Raspberry Pi have gained momentum in educational settings and among the maker community, enabling many of the features that Mbed offered to become more widespread and accessible,”
While it will no longer be actively maintained by Arm, Mbed OS is open source and will remain publically available. There is also a community fork of Mbed OS called Mbed CE that is under active development, and in its end-of-life announcement Arm has pointed external contributors to Mbed to the community fork rather than their own Github.
Tomi Engdahl says:
EMBEDDED PYTHON: MICROPYTHON IS AMAZING
https://hackaday.com/2024/07/11/embedded-python-micropython-is-amazing/
In case you haven’t heard, about a month ago MicroPython has celebrated its 11th birthday. I was lucky that I was able to start hacking with it soon after pyboards have shipped – the first tech talk I remember giving was about MicroPython, and that talk was how I got into the hackerspace I subsequently spent years in. Since then, MicroPython been a staple in my projects, workshops, and hacking forays.
If you’re friends with Python or you’re willing to learn, you might just enjoy it a lot too. What’s more, MicroPython is an invaluable addition to a hacker’s toolkit, and I’d like to show you why
HACKING AT KEYPRESS SPEED
Got a MicroPython-capable chip? Chances are, MicroPython will serve you well in a number of ways that you wouldn’t expect. Here’s a shining example of what you can do. Flash MicroPython onto your board – I’ll use a RP2040 board like a Pi Pico.
Tomi Engdahl says:
Google will update Android’s Linux kernel 4 years after its own long-term support
https://www.androidpolice.com/google-support-linux-kernels-android/
SUMMARY
Google is stepping in to extend Android’s LTS kernel support to six years for enhanced security.
Previously, LTS kernels were being maintained for six years by Linux contributors, but now only get two years of upstream support. Google says it will bridge that four-year gap.
To help accommodate this, OEMs launching Android 15+ devices are now required to use the latest kernel versions for continued support.
Tomi Engdahl says:
The Mbed platform and OS will reach end of life in July 2026, when the Mbed website will be archived and it will no longer be possible to build projects in our online tools
The device software – Mbed OS – is open source and will remain publicly available, but is no longer actively maintained by Arm
The Mbed TLS project is unaffected by this announcement and continues to be supported as part of the TrustedFirmware community project.
https://os.mbed.com/blog/entry/Important-Update-on-Mbed/
Tomi Engdahl says:
https://github.com/ARM-software/CMSIS_6
Tomi Engdahl says:
Recommendations for Mbed users:
We recommend that educational institutions begin to investigate a move away from Mbed as a platform for teaching embedded development. The Arm Education team is actively working on creating alternative teaching and learning solutions in time for the new academic terms starting Fall/Autumn 2025. We welcome feedback from the academic community on this. Reach out to the team at: [email protected]
No new commercial projects should be started using Mbed, and any existing Mbed-based commercial projects should start to investigate alternative frameworks. For a list of frameworks please see the FAQs at the end of this document.
All users begin to migrate code and other data from Mbed.com to other platforms. An export tool is available in your Mbed account.
https://os.mbed.com/blog/entry/Important-Update-on-Mbed/
Tomi Engdahl says:
https://hackaday.com/2024/07/13/c-design-patterns-for-low-latency-applications/
Tomi Engdahl says:
https://www.itprotoday.com/linux-os/enhance-linux-kernel-security-using-lockdown-mode-and-kernel-self-protection
Tomi Engdahl says:
Arduino’s Plug and Make Kit Offers an Easy Introduction to the Internet of Things
This Arduino UNO R4 WiFi bundle aims at simplicity with its Modulino base and matching quick-connect input/output modules.
https://www.hackster.io/news/arduino-s-plug-and-make-kit-offers-an-easy-introduction-to-the-internet-of-things-f624345b97c1
“The Plug and Make Kit is Arduino’s new entry point into the world of IoT and electronics: one that is more accessible, fun, and engaging than ever,” claims Arduino chief executive officer Fabio Violante of the company’s latest bundle. “No matter their age, background or interests, everyone can experience that first taste of technology.”
Tomi Engdahl says:
Coding From Scratch Creates New Risks
The good news for organizations is that CodeOps combines AI and human ingenuity to minimize these risks while saving time and money.
https://thenewstack.io/coding-from-scratch-creates-new-risks/
Digital assets, including apps and websites, are a must-have for organizations, and those that are innovative, intuitive, and fun to use can go a long way toward building long-lasting customer relationships. Creativity helps businesses stand out in a crowded marketplace, but many need to realize that they don’t need to reinvent the wheel and start the app development process from scratch.
In many new app development projects, a significant portion of the required code has already been written — up to 70% is often readily available. This code may originate from open source projects or have been previously developed by developers within the organization.
Despite the abundance of existing code, efforts to prioritize code reuse have historically faced challenges. Solutions such as low- or no-code platforms often force disruption and demand new, non-transferable skill sets, contributing to resistance and failure. Many of these solutions also need more technical maturity to deliver on their promises.
This is why organizations turn to CodeOps, an AI-driven software development process prioritizing systematic code reuse. This helps teams avoid wasting time reinventing the wheel and, more importantly, significantly reduces the risks associated with writing code from scratch, including:
Tomi Engdahl says:
https://hackaday.com/2024/07/14/undo-arduino-encryption-with-an-oscilloscope/
Tomi Engdahl says:
https://hackaday.com/2024/07/13/its-not-unsual-to-love-hacking/
https://hackaday.com/2024/07/11/embedded-python-micropython-is-amazing/
Tomi Engdahl says:
https://hackaday.com/2024/07/15/congratulations-to-the-2024-business-card-challenge-winners/
Tomi Engdahl says:
https://hackaday.com/2024/07/17/digitally-reading-a-micrometers-output/
Tomi Engdahl says:
https://hackaday.com/2024/07/16/times-up-for-mbed/
Tomi Engdahl says:
https://hackaday.com/2024/07/16/playing-rock-paper-scissors-with-a-time-of-flight-sensor/
Tomi Engdahl says:
Embedded devices (like IOT gadgets) can have, and should have, solid secure boot to protect against hacking. A chain of trust makes sure only signed firmware can run. It’s not theater. For PCs … well, the user expects to be able to run all kinds of OSes, so it needs to be more complicated and that makes it harder to get secure. And add to that a bunch of security bugs. So yes, it’s mostly theater. They should have made a physical button you have to push whenever a new OS bootloader is installed, that would store the new signature and require it from then on. Then you are in full control and no malware can affect the boot process.
Tomi Engdahl says:
I’m referring to secure boot on PCs specifically, you don’t make anything that shouldn’t be hacked like a PC, actually secure devices exist and they aren’t built like PCs.
It used to be that if you needed to make a digital system that was secure, you purpose built the hardware for the job. The over reliance on general purpose computers is partly to blame for so many devices being exploitable. Imagine if we built a world where all the connected devices didn’t run software, you could implement TCP/IP and a protocol stack in hardware, no one would have a persistent entry point to your network if devices only had the intelligence to do exactly what they were designed to do. People are inherently lazy. Software is needed because doing the prior would be prohibitively expensive. A solution I propose is a software language that builds a circuit design to do the task, and gives you an ASIC to manufacture. By needlessly complicating things in engineering, you create systems that can be compromised. Computers should be computers, and toasters should be toasters. If you want to control the toaster with the computer, there are ways to do this without putting a computer in the toaster.
Tomi Engdahl says:
Here’s a FLAMING Hot Take:
UEFI Secure Boot will never be truely secure, it’s only security theater.
i mean physical access trumps all obviously, but other than that what are you suggesting the issue with uefi is?
All security is theater if you’re not secure
Nothing is truly secure. Remember, security and privacy are not destinations rather a journey.
Tomi Engdahl says:
them to customers or prospective customers for testing. For reasons that aren’t clear, the test keys made their way into devices from a nearly inexhaustive roster of makers. In addition to the five makers mentioned earlier, they include Aopen, Foremelife, Fujitsu, HP, Lenovo, and Supermicro.
Cryptographic key management best practices call for credentials such as production platform keys to be unique for every product line or, at a minimum, to be unique to a given device manufacturer. Best practices also dictate that keys should be rotated periodically. The test keys discovered by Binarly, by contrast, were shared for more than a decade among more than a dozen independent device makers. The result is that the keys can no longer be trusted because the private portion of them is an open industry secret.
“Imagine all the people in an apartment building have the same front door lock and key. If anyone loses the key, it could be a problem for the entire building. But what if things are even worse and other buildings have the same lock and the keys?”
Matrosov said his team found identical test platform keys on both client and server-related products.
“If the key will be leaked, it’s impacting the ecosystem,” he explained. “It’s not impacting a single device.”
Binarly has named its discovery PKfail in recognition of the massive supply-chain snafu resulting from the industry-wide failure to properly manage platform keys.
The report is available here. Proof-of-concept videos are here and here. Binarly has provided a scanning tool here.
Owning Secure Boot
The threat posed by PKfail is that anyone with (1) knowledge of the private portion of an affected platform key and (2) administrative system rights to an affected device can completely bypass Secure Boot protections. The threat is most immediate for devices that use the platform key compromised in the 2022 leak on GitHub.
Last year, Smolár uncovered BlackLotus, the world’s first-known instance of real-world UEFI-dwelling malware that bypassed Secure Boot. The discovery resulted in the addition of several new entries in the forbidden DBX database. An attacker with knowledge of the private platform key material can “not only make BlackLotus work again but create other malware and enable it on all these devices,” he said.
PKfail has parallels to at least two recent supply-chain mishaps.
The PKfail issue highlights multiple security problems related to device supply chain security:
Poor cryptographic materials management and appearance of the private keys directly in the code repositories with the hardcoded path from the build scripts.
Usage of the non-production cryptographic keys responsible for the platform security of production firmware and devices.
No rotation of the platform security cryptographic keys per product line. For example, the same cryptographic keys were confirmed on client and server-related products. Similar behavior was detected with Intel Boot Guard reference code key leakage.
The same OEM used the same platform security-related cryptographic keys for firmware produced for different device manufactures. Similar behavior was detected with Intel Boot Guard reference code key leakage.
None of the companies answered questions asking how their products came to be using test keys clearly marked as untrusted. All of the companies declined to outline the steps they take to ensure platform keys in their products are managed using best practices in the industry.
Tomi Engdahl says:
https://www.phoronix.com/news/Torvalds-ARM64-Compress-Kernel
Tomi Engdahl says:
Arduino to switch from Arm Mbed to Zephyr RTOS
Following Arm’s decision to stop supporting Mbed from July 2026 onwards, Arduino has now decided to use Zephyr RTOS instead of Arm Mbed for Arduino boards that rely on the latter including Arduino GIGA, Arduino Nano 33 BLE, Arduino Nano RP2040 Connect, as well as Arduino PRO boards/solutions such as the Portenta, Nicla, and Opta families.
Note that Arduino UNO, MKR, and Nano families are not impacted by the change since their Arduino Core implementation does not rely on Mbed. The change is not going to happen overnight as software development takes time, and Arduino plans to release the first beta based on ZephyrOS by the end of 2024. and a rollout for various boards starting in 2025 long before Arm Mbed is phased out for good
https://www.cnx-software.com/2024/07/25/arduino-to-switch-from-arm-mbed-to-zephyr-rtos/
Tomi Engdahl says:
https://blog.arduino.cc/2024/07/24/the-end-of-mbed-marks-a-new-beginning-for-arduino/
Tomi Engdahl says:
Powered by an unspecified 32-bit RISC core running at up to 120MHz, this sub-$7 dev board comes pre-licensed for Tuya’s cloud platform.
Tuya’s Low-Cost T2-U Development Board Aims to Tempt Makers to Try Out Its IoT Ecosystem
Powered by an unspecified 32-bit RISC core running at up to 120MHz, this sub-$7 dev board comes pre-licensed for Tuya’s cloud platform.
https://www.hackster.io/news/tuya-s-low-cost-t2-u-development-board-aims-to-tempt-makers-to-try-out-its-iot-ecosystem-36dc358a71f7?fbclid=IwY2xjawEUCuhleHRuA2FlbQIxMQABHSJ61uWhXibPeImHQrFwmlo6e5So9649Kswdz_LuhOGBriJOKrtJ5eSzog_aem_Uc4sWmbAvXh9fQujrMINwg
Tomi Engdahl says:
https://hackaday.com/2024/08/05/embedded-python-micropython-toolkits/
Tomi Engdahl says:
https://etn.fi/index.php/13-news/16425-tehokkaampi-dsp-mikro-ohjaimelle
Tomi Engdahl says:
Golioth for AI Streamlines IoT Data Transforms, ML Models, and Inferencing on Edge Connected Devices
Partnership between Golioth AI and Edge Impulse streamlines capturing data, building an AI model, and updating it over-the-air.
https://www.hackster.io/news/golioth-for-ai-streamlines-iot-data-transforms-ml-models-and-inferencing-on-edge-connected-devices-ddd2db1a4400?bc8a3b91b762ea06e9ca6d8e8e9caca0&fbclid=IwY2xjawEhKJVleHRuA2FlbQIxMQABHQrsg8U2Sr-S0vWHtUFA9RNtj_tQ90FiKOT1GdGrFv1A4773x0T6xko0mw_aem_JU3MLq4cd0TNvxscdNMuDQ
Tomi Engdahl says:
Matthias Kesenheimer’s PicoGlitcher Turns a Raspberry Pi Pico Into a Python-Powered Fault Injector
Designed as a low-cost yet high-performance device for voltage glitching attacks, the PicoGlitcher can be built for under $33.
https://www.hackster.io/news/matthias-kesenheimer-s-picoglitcher-turns-a-raspberry-pi-pico-into-a-python-powered-fault-injector-d1633e6a4b3a?fbclid=IwY2xjawEhLYpleHRuA2FlbQIxMQABHcaggluHnISnofcaLvibiDmwWK1NNvGEo8nWCU3S06gImLzf79ksbQzdLQ_aem_S02O10GU6WTO3_HuJFxE6A
Tomi Engdahl says:
https://betanews.com/2024/07/09/no-linux-isnt-always-best-for-iot/
Tomi Engdahl says:
MicroPython-Powered Robotics for All: Hands-on with the Arduino Alvik
Boxy yet cute, Alvik is Arduino’s attempt to get a new generation interested in robotics — and comes complete with a MicroPython curriculum.
https://www.hackster.io/news/micropython-powered-robotics-for-all-hands-on-with-the-arduino-alvik-75fe0244fd10
Tomi Engdahl says:
https://www.raspberrypi.com/news/raspberry-pi-pico-2-our-new-5-microcontroller-board-on-sale-now/
Tomi Engdahl says:
https://etn.fi/index.php/13-news/16477-satelliittiyhteys-iot-mobiiliverkkoon-ensimmaeistae-kertaa
Tomi Engdahl says:
MechDog AI Robot Dog features ESP32-S3 controller, supports Scratch, Python, and Arduino programming
Hiwonder’s MechDog is a compact AI robot dog powered by an ESP32-S3 controller that drives eight high-speed coreless servos. It features built-in inverse kinematics for precise and agile movements and has ports for various I2C sensors such as ultrasonic and IMU sensors. The robot is equipped with a durable aluminum alloy frame and a removable 7.4V 1,500mAh lithium battery for power.
https://www.cnx-software.com/2024/08/08/mechdog-ai-robot-dog-features-esp32-s3-controller-supports-scratch-python-and-arduino-programming/
Tomi Engdahl says:
Top 19 tools for hardware hacking with Kali Linux
https://www.infosecinstitute.com/resources/hacking/top-19-tools-for-hardware-hacking-with-kali-linux/
Tomi Engdahl says:
uSNMP – a small and portable ‘C’ library for SNMP v1
https://github.com/Francis-Tay/uSNMP
Tomi Engdahl says:
https://notenoughtech.com/arduino/arduino-plug-make-kit/
Just over a year ago, Arduino released the 4th revision of their Arduino Uno boards aimed at makers, tinkerers and anyone trying to prototype a project or learn more about C++ and electronics. With a faster CPU, onboard LEDs and ESP32-based WIFI, the Arduino Uno R4 release added new ways to interact with R4 boards. One thing no one really talked about was a white Qwiic connector.
Arduino Plug & Make kit takes full advantage of that port and removes the need for a traditional breadboard!
https://store.arduino.cc/en-fi/products/plug-and-make-kit
Tomi Engdahl says:
https://etn.fi/index.php/13-news/16506-ihme-wi-fi-siirtaeae-valvontakameran-kuvan-kolmen-kilometrin-paeaehaen
Tomi Engdahl says:
https://etn.fi/index.php/13-news/16509-yli-kolmasosa-nettiliikenteestae-on-bottien-aiheuttamaa
Tomi Engdahl says:
https://embeddedcomputing.com/application/industrial/industrial-computing/should-i-use-off-the-shelf-or-custom-hardware-in-my-electronic-product
Tomi Engdahl says:
https://theembeddedkit.io/blog/off-the-shelf-custom-linux-distributions/
Tomi Engdahl says:
https://www.reddit.com/r/embedded/comments/dot2wk/why_do_embed_engineers_use_dev_boards_when_the/
Tomi Engdahl says:
Is embedded over saturated?
https://www.reddit.com/r/embedded/comments/1emgl44/is_embedded_over_saturated/
I know most people here under Reddit are under 30 and don’t remember how hard it was to get into embedded before the introduction of cheap evaluation boards and HALs, but I’d like to hear the opinion of the older people here.
Things I’ve not over the last few years while working with my local university is that the number of kids wanting to go into embedded is 4-5X what it was when I graduated 25 years ago. I’ve also noticed that embedded is perceived as easy relative to other subfields. This was NOT the perception 25 years ago.
Something else I’ve noticed is that quality, relative to their peers as measured by gpa, has gone way down for the applicants of internships and junior positions.
Really? Everybody I work with is fairly self-deprecating about their software jobs, and always seem very impressed by what is done in hardware. Then, when you pull out a schematic to show what is happening, it gets even worse.
Also, once they see that you only work in C, they have a lot of comments about how they’d never like to work in C again, and they were just glad to get it over with in college and move on.
What I do as an embedded engineer simultaneously fascinates and scares the crap out of the software guys on my team. C petrifies them, lol.
Lol, ego boost is right. Though personally I really enjoy the work – working with computing devices and hardware at this level is really cool to me. Plus, it feels like better job security to have a decently versatile embedded skill set, versus having a software skill set.
Tinkering with embedded (RasPi, Arduino, etc) has a reputation for being a hobby project, but professional embedded work doesn’t have a reputation for being easy. The only people I’ve met who think so are people who don’t know what actual embedded work entails (which I admit is most people). Maybe you’re seeing a lot of kids applying with a misunderstanding of advanced embedded concepts?
Embedded SW on commercially tested hardware is easy. Trying to prove to a EE that their custom hardware design has bugs? Not easy. Trying to integrate random on-board peripherals from a datasheet, also not easy.
Embedded engineers don’t develop on RPi and Arduino in the real world.
Cheap boards and HALs are great for prototyping and learning but for the “real” work (i.e the main implementation), not too much has changed in my experience. In some ways we are comically using the same old shite that we did decades ago. The Lindy effect is real, the old stuff is known to work. The skills are only half transferrable between these ecosystems.
the number of kids wanting to go into embedded is 4-5X what it was when I graduated 25 years ago
Very interesting. In the UK at least, embedded has absolutely died a death when it comes to universities. Most courses have shut! Even the “soft” resurgence as IoT nonsense didn’t last through COVID.
The gimmick IoT market also yields some startups needing a prototype. However, yes, a lot is currently outsourced but as far as I recall, it kind of always was.
I personally find embedded “slow and steady”. It won’t capture the big bucks like cloud or “AI” because it is hard to scale. However it pretty much guarantees a stable income because it is hard to get into compared to making apps or websites. Most of my side contracting gigs do tend to be embedded because of this.
Technology changing so fast right now so many thing to learn but where to?From bare metal to FreeRtos/qnx to Customised Linux distro to IOT and now they are intigrating AI to embedded. If you look some embedded jobs with high pay it must be required new tech experience.
Embedded has been advancing quickly. Things are much more complex than they used to be. I’ve had to learn a lot of new and emerging technologies to keep products relevant.
There are a lot of threads on cs careers pointing people towards embedded due to the difficult hiring on software side. The barrier for entry is lower and the content is interesting. It’s easier to learn about embedded than before, so more people’s interests are sparked. There will always be people looking to do something just as a job and not as a passion. Not everyone’s passion can keep bread on the table.
Entry level has slowed down, but I found need for experienced folks has increased. Can’t fill shoes, need somebody ASAP for a (very well paying) project and none of my contacts are available. I saw a slump at the beginning of this year but it picked up again. Plenty of seasoned folks retiring, but due to very harsh deadline pressure there is less desire for bringing up a fresher vs. grabbing someone who can do what you want to do with minimal bring up time.
Unfortunately I lack a crystal ball, but I can confidently say 80% of my team is going to retire before 2030.
Once they run out of experienced people they will hire unqualified candidates to do the work who then will proceed to fail or launch a defective products. Its already happening… But our corporate overlords dont give a fuck.
Tomi Engdahl says:
https://www.viewpointusa.com/IE/wp/comparing-off-the-shelf-to-custom-designs-for-industrial-embedded-systems/
Tomi Engdahl says:
https://www.viewpointusa.com/IE/wp/comparing-off-the-shelf-to-custom-designs-for-industrial-embedded-systems/
The COTS Approach
COTS is an acronym for Commercial-Off-The-Shelf. A COTS prototype is entirely comprised of items that can be ordered from various vendors. Obviously some integration effort and software development are required to create your product concept: if you could buy your product as COTS, you already have a competitor.
Using COTS speeds development of your prototype since you have less to build, can interface to your sensors and actuators with purchasable signal conditioning, and both write and debug your application in a development environment that offers high-level software development tools. The resulting shortened timeline is traded against either high unit cost or high follow-on non-recurring engineering (NRE). The high unit cost happens is you use the prototype design for your end-product. The high NRE happens if you need to convert your COTS design to Custom after you’ve vetted the product design.
The Custom Approach
Building a Custom prototype involves selecting a controller, laying out the circuitry for the I/O signal conditioning and connectivity, writing the application using the tools available for that controller, manufacturing the printed circuit board (PCB), debugging the PCB and app software, and building an enclosure if necessary.
Clearly, this approach takes significantly more effort than the COTS approach before the prototype is available for the intended purpose of evaluating your product idea or upgrade. In our experience, it is common for this effort to take 4 to even 10 times the COTS prototyping effort.
The Hybrid Approach
Your prototype could also be part COTS and part Custom. Such a “Hybrid” approach can offer advantages by combining the increased speed of prototyping with COTS with the reuse of the same hardware and software in both prototype and end-product. By carrying over the effort spent to design and build the prototype and reusing it in the end-product, any NRE is spent once.
Custom
Since the Custom path requires that the prototype be developed from scratch, the non-recurring engineering (NRE) effort is very significant right from the start.
COTS
COTS solutions tend to have a shorter prototyping phase, since the hardware is ready-to-use out of the box and troubleshooting involves only rewiring, reprogramming, or changing the types and quantities of COTS I/O modules. Hence, most of the effort is in software development, and the NRE in prototyping will be smaller than for the Custom approach.
Hybrid
Since a Hybrid approach tries to balance the benefits of the COTS and Custom approaches, the NRE can beabout the same for prototyping as the COTS approach. Further, you likely will start with close to the same form, fit, and function as the prototype when it’s time to move to production, leaving total NRE lower than either COTS or Custom.
Specifically, this reuse benefit appears when you select the same COTS embedded controller that would be used in your end-product and coupling it with COTS I/O. This hybrid combination brings you closer to the form factor your end-product needs than would COTS alone. However, note that, if you need some I/O that is not available as COTS, then some Custom I/O will need to be developed and the NRE will increase but only proportionally to the amount of COTS compared to Custom I/O you require.
Tomi Engdahl says:
https://runtimerec.com/custom-vs-commercial-vs-open-source-rtos/
Tomi Engdahl says:
FreeRTOS vs Linux for Embedded Systems
https://www.bytesnap.com/news-blog/freertos-vs-linux-embedded-systems/
Which operating system is best suited for your embedded systems project – FreeRTOS or Linux?
FreeRTOS and Embedded Linux are two popular options for operating system provision in embedded systems.
But which should you choose for your electronics product design?
In many cases, the decision about which system to use is preferential, as software engineers generally have more experience in one or the other.
In this article we will present an overview of each option, and look at their comparative strengths and weaknesses.
Probably the most popular real-time operating system currently in use, FreeRTOS is currently freely distributed under the MIT license.
FreeRTOS is generally known as the de facto RTOS and is supported by most major semiconductor manufacturers, including NXP, Renesas and ST.
About Embedded Linux
Linux was first released in 1991, and is now the most used OS globally.
Embedded Linux is normally distributed under distributions such as Yocto Project and Debian. Both distributions are based on the Linux Kernel, but designed to be more light-weight and less feature heavy.
This enables engineers to choose the tools that are right for their project and allows great flexibility.
Linux is completely open-source, and is similar to Unix. Linux is very well supported across the board, by chip manufacturers, the many distributions, and by a global community of engineers and hobbyists.
The priority of an RTOS is predictability. This is described as deterministic and requires tasks to be completed within a fixed timeframe or deadline. Due to this guarantee of completion, the operating systems behaviour can be anticipated. Embedded devices in particular have real-time requirements and this is partly why RTOS’ are so popular in the sector.
Linux has a more performance optimized scheduler, which prioritises foreground tasks with the aim of improving overall device performance. As this is less deterministic than an RTOS, it is difficult to know when a task is going to be completed.
The RTOS classification can be further broken down in hard, firm and soft determinism. This refers to the consequences if a deadline is missed.
Memory Management
There are two different types of processor commonly used in embedded systems: application processors and microprocessors.
The different between these is that application processors have a memory management unit. An MMU virtualizes and ‘looks after’ memory for you. As the memory is virtual, an MMU is able to prevent memory fragmentation and the subsequent slowing down of the system by mapping data across to other parts of the same program after memory has been freed.
Another advantage of an MMU is memory protection, which manages the memory access rights of programs, and helps with debugging.
Where do Linux and FreeRTOS come in? Embedded Linux requires an MMU to run, whereas FreeRTOS does not. Having the MMU decreases development effort and improves system support, however increases the memory footprint of the application.
Memory
The key advantage currently of FreeRTOS is that it is lightweight. All the code is in one application layer and therefore less flash and RAM is required for a smooth experience.
Linux, by comparison, is large and clunky, with multiple code layers. The BSP in particular requires a lot of memory, and the OS can be slow to boot due to the complex file structure and amount of code.
Development Effort
FreeRTOS is more difficult to develop, due to the lack of the MMU. Whenever the device hits an error or snag it simply reboots, which makes it very difficult to identify bugs, and leads to a more frustrating development journey overall.
Flexibility
Linux is definitely the stronger contender here. When developing an embedded system, it is much simpler to find a driver for your hardware, and these are often provided by the manufacturer. There is more supported hardware for Linux than FreeRTOS currently, and therefore there is more choice and better opportunity for optimization without extending development time.
Furthermore, as Linux is a larger and more feature-rich OS there is a greater range of products that it is easier to develop for, including AI features and high resolution touch-screen displays.
Embedded Linux also has many programming language options, including Java, C#, C and C++.
FreeRTOS is only written in C and C++, which can be frustrating for some engineers, however most embedded applications are written in one of these two languages so this is usually not a problem.
Debugging
As stated above, the MMU makes debugging much easier for Linux, however debugging as a whole is a very similar experience for both Embedded Linux and FreeRTOS.
With the two operating systems the debugger connects differently; with Linux, the program is run through the debugger, and the IDE connects to it. With FreeRTOS, engineer’s often use JTag.
Unit Cost
FreeRTOS wins here – as it does not require an MMU to run, microcontrollers can be used, which are cheaper than application controllers. FreeRTOS simply has less code and therefore a smaller memory footprint, so less RAM and flash memory are also required.
Support
Linux currently is better supported. Drivers and Daemons for most hardware can be found online, so whatever the project, the engineers have a starting point. There is also a very active forum, where thousands of questions have been answered.
However, choosing FreeRTOS means gaining the benefits of a regular and periodic support updates from AWS, and the fact that currently it has reduced popularity actually could help with security, as it is a less popular target for hackers.
Also, while Linux is better supported at a whole, Amazon’s ownership of FreeRTOS makes it perfectly placed for integration with Amazon products such as Alexa. AWS also has an advanced over-the-air update system that can be used with FreeRTOS, making it a good candidate for use in IoT systems.
FreeRTOS is also quickly catching Linux up with supported hardware and in the wider community, so this section may need altering in the next couple of years!
There are many reasons why a business may wish to port FreeRTOS over to Linux or vice versa. For Embedded Linux to FreeRTOS, this is usually to leverage the cheaper hardware to lower unit costs, especially for high-volume products.
Summary
In conclusion, both operating systems clearly have key advantages over the other that make them better suited for different projects. They both allow full control of the hardware, and have similar development time when starting with equal experience.
However, most software engineers are currently more experienced with Linux. In addition, Linux comes with the extra support and flexibility of distribution choice and supported hardware.
Overall, we would recommend Embedded Linux as a starting point.