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,430 Comments
Tomi Engdahl says:
Is golang a good language to use for the Internet of things?
https://www.quora.com/Is-golang-a-good-language-to-use-for-the-Internet-of-things
Apparently so: Golang framework for robotics, physical computing, and the Internet of Things (IoT)
http://www.slideshare.net/YoniDavidson/the-internet-of-things-in-now-see-how-golang-is-a-part-of-this-evolution-58137793
Other comment:
Golang is basically a replacement for Javascript/node.js for server-side HTTP applications. It’s better in every way than Javascript, in my opinion.
Golang can do other things, but after having used it for a project, I don’t think it’s great for most IoT coding. There are high level scripts, and there is code that needs to work with data on a low level. A lot of IoT is the former, and a lot is also the latter.
For the latter in particular, Go is lousy. It is inelegant in the way it handles data, and pointer usage is deprecated. In short, it sucks for dealing with protocols. Granted, it’s still better than Java is for these purposes, but it isn’t better than C, and Go-to-C linkage is not as trivial as Julia-to-C linkage.
Tomi Engdahl says:
11 IoT Programming Languages Worth Knowing
http://www.informationweek.com/mobile/mobile-applications/11-iot-programming-languages-worth-knowing/d/d-id/1319375
Choosing which language to use for an Internet of Things project can be as big a decision as choosing a hardware platform. Here are 11 options to consider for your next coding project.
Tomi Engdahl says:
How Rust Compares to Other Programming Languages
http://thenewstack.io/safer-future-rust/
The Mozilla Foundation, known for the popular Firefox web browser and Thunderbird email clients, has also been working on the open source Rust programming language for a while now. Many developers have been watching Rust with anticipation, waiting for the right time to dive in and start building things. Given that Rust hit 1.0 last May, it is now better than ever to start hacking on Rust!
More like C++ and Go, less like Node and Ruby
While Rust is a general purpose language, you could write your next web app in Rust, but you wouldn’t be best experiencing what it has to offer. Rust is a low-level language, best suited for systems, embedded, and other performance critical code. While it is conceivable that one day people will be writing the latest 3D video games in Rust — an area where high performance has historically been critical — it is unlikely ever to have a web framework that will go toe-to-toe with Ruby on Rails.
Safer than C/C++
The biggest — and some would say most vital — difference between Rust and C++ is the emphasis on writing safe code.
With “safe code,” objects are managed by the programming language from the beginning to end. The developer doesn’t do any pointer arithmetic or manage memory, as can be necessary in C or C++ programs.
Tomi Engdahl says:
How good is Rust for bare-metal programming as compared to C/C++?
https://www.quora.com/How-good-is-Rust-for-bare-metal-programming-as-compared-to-C-C++
C and C++ are fairly straightforward to use in embedded systems.
Rust, as I have seen recently, is becoming popularly viewed as a runner up to replace C++. But how will it fair in embedded systems and MCU domain where there is no OS?
Rust should be as good as C at this. There are still some unstable features that you have to use, but many of them are being stabilized in the near time frame. We have a whole dedicated IRC channel deveoted to OSDev, for example, and there’s more tutorials and examples being written all the time.
The big challenge here is basically, “Does LLVM support your architecture?” If it doesn’t, like some proprietary chips where a C compiler is provided by the vendor, well, you’re stuck.
Yikes,
You see, Rust has great potential for baremetal programming but as of now, while it is possible, it is a huge pain in the ass.
The biggest problems so far have been that you can only program on the metal if you use the “core” crate and if you use the #![no_std] feature. Both of which are still experimental as of last time I checked.
Another issue is that you can only even think about doing this if you are using the nightly releases, not the stable ones. But this is more of an annoyance than a real problem
Lack of cargo support is expected but the compiler flags to get your desired binaries are really obscure and hard to remember.
No. It’s not the language; it’s (the lack of) everything else around it that you need.
When you’re programming on bare metal, it’s because you have no other choice. You’re doing it because it’s the brand new PCB or silicon that just came back from fab.
You want the entire ecosystem of ancillary support – proven tools, answers on Stack Exchange, trusted FAE that you can all, rock solid essentials like u-boot.
All this – points to C. And no, not C++.
I’m sure once Rust stabilizes and matures, it’ll be a fine low-level systems programming language. But the real question is whether it will garner enough industry support to displace C/C++, and IMO, it will not. Rust will have its ardent fan base, no doubt, but C/C++ will continue to rule the systems space.
I havn’t delved into embedded systems, as of now. But reading on that and having conversations with rust guys over irc, its definitely suitable for embedded development, as rust code runs with a very minimal runtime, using only the libcore
There’s already zinc.rs , they are trying to achieve a bare metal stack for ARM.
zinc.rs
http://zinc.rs/
Zinc is an experimental attempt to write an ARM stack that would be similar to CMSIS or mbed in capabilities but would show rust’s best safety features applied to embedded development.
Zinc is mostly assembly-free and completely C-free at the moment. One of the goals of zinc is to figure out, how much of the usual RTOS stack is it possible to write in rust in a safe manner, while keeping the resource usage profile low enough (comparable to C/C++ code).
Tomi Engdahl says:
Taking Rust everywhere with rustup
https://blog.rust-lang.org/2016/05/13/rustup.html
Cross-compilation is an imposing term for a common kind of desire:
You want to build an app for Android, or iOS, or your router using your laptop.
You want to write, test and build code on your Mac, but deploy it to your Linux server.
You want your Linux-based build servers to produce binaries for all the platforms you ship on.
You want to build an ultraportable binary you can ship to any Linux platform.
You want to target the browser with Emscripten or WebAssembly.
In other words, you want to develop/build on one “host” platform, but get a final binary that runs on a different “target” platform.
Thanks to the LLVM backend, it’s always been possible in principle to cross-compile Rust code: just tell the backend to use a different target! And indeed, intrepid hackers have put Rust on embedded systems like the Raspberry Pi 3, bare metal ARM, MIPS routers running OpenWRT, and many others.
The Rust community has been hard at work toward the goal of “push-button cross-compilation”.
At its heart, rustup is a toolchain manager for Rust. It can download and switch between copies of the Rust compiler and standard library for all supported platforms, and track Rust’s nightly, beta, and release channels, as well as specific versions. In this way rustup is similar to the rvm, rbenv and pyenv tools for Ruby and Python. I’ll walk through all of this functionality, and the situations where it’s useful, in the rest of the post.
Today rustup is a command line application, and I’m going to show you some examples of what it can do, but it’s also a Rust library, and eventually these features are expected to be presented through a graphical interface where appropriate — particularly on Windows. Getting cross-compilation set up should eventually be a matter of checking a box in the Rust installer.
Tomi Engdahl says:
Rhai – embedded scripting for Rust
https://github.com/jonathandturner/rhai
Rhai is an embedded scripting language for Rust that gives you a safe and easy way to add scripting to your applications.
Rhai’s current feature set:
Easy integration with Rust functions and data types
Fairly efficient (1 mil iterations in 0.75 sec on my 5 year old laptop)
Low compile-time overhead (~0.6 sec debug/~3 sec release for script runner app)
Easy-to-use language based on JS+Rust
Support for overloaded functions
No additional dependencies
No unsafe code
Tomi Engdahl says:
Atmel START
http://start.atmel.com/
This tool will help you select and configure software
components and tailor your embedded application in
a usable and optimized manner.
To get started you can either create a new project from scratch or open an existing example. In both cases you can configure your software components and device settings such as clocks and pin layout. When you are done, you can export your project and open it using your favourite IDE for further development.
Tomi Engdahl says:
Sophisticated Java Solutions Marry IoT and ARM Architecture
http://intelligentsystemssource.com/sophisticated-java-solutions-marry-iot-and-arm-architecture/?utm_source=eNewsletter&utm_medium=email&utm_term=IoT&utm_campaign=IIot
With an exploding number of devices for IoT and cloud computing, development with Java is becoming more attractive than ever. Java technologies for the ARM32 platform are a valuable piece of that puzzle.
Expanding Market Share
ARM has expanded its market share beyond the mobile and into embedded and IoT with its low power consumption and competitive price to compute ratio. It’s evident that ARM is now a mainstream embedded processor architecture. According to Linley Group, ARM has more than 77 percent of the licensed embedded processor market today and it has dominated the tablet and smartphone space. Now, it is expanding across consumer IoT markets and rapidly penetrating into the industrial IoT space where traditional x86, MIPS, and PowerPC processors have enjoyed a stable position for many years. According to ARM, it is looking to hit a compound annual growth rate of 5 percent in networking and 10 percent across all mobile, home, enterprise, and embedded segments by next year. In fact, major chipmakers are actively replacing legacy SoCs with ARM cores on their product roadmap
Java for Embedded & IoT
Java continues to be the most popular programming language. The latest TIOBE Index ranks Java as the #1 for the programming community. For the hardcore embedded community, C is still considered to be the most widely used programming language. However, interest and adoption of Java have been steadily growing since last year due to the plethora of platforms requiring portability across IoT and Cloud systems
Java has been used in embedded devices since the 90s
Today Java SE is running on healthcare devices, network and storage appliances, gateways, automatic teller machines (ATMs), kiosks, imaging, and multi-function printers. With the advent of IoT, there is a blurring line between traditional embedded and enterprises
For those that have been running Java, extending existing capabilities is less challenging. Besides, Cloud is what makes IoT possible today. IoT and Cloud are inseparable and a significant portion of the cloud computing platforms are Java-based. The third component that is critical for success is open source
Open Source Java & Zulu Embedded
A large portion of today’s technological innovations come from the open source community, Eclipse and Apache projects being good examples. For Java, OpenJDK is where open source Java has originated from.
Zulu Embedded is a certified build of OpenJDK for the embedded space. It supports both headful and headless modes. It also offers compact profiles of Java 8 for resource constrained devices in addition to Java 6 and 7. Java 8 Compact Profiles allow you to run Java in devices with a memory as low as 12mb. As far as operating systems are concerned, Zulu Embedded has been tested with most flavors of Linux, MacOS, as well as Windows 10 IoT Core. For ARM32, compared to other comparable JVMs, Zulu Embedded provides unsurpassed performance with its JIT (Just-In-Time) compiler
Recently Azul Systems released Java APIs for accessing device peripherals. APIs are available on Windows 10 IoT and Linux as part of the Zulu Device APIs. Device APIs deliver optional Java extensions to the base Zulu Embedded JRE for enabling software control over device I/Os and their peripherals. It covers following peripheral access:
General Purpose Input/Output (GPIO).
Inter-Integrated Circuit Bus (I2C).
Serial Peripheral Interface.
For IoT services and gateway use cases, Zulu Embedded has been tested to work with all major OSGi implementations, including Eclipse and ProSyst.
No Commercial License
One of the biggest advantages of Zulu Embedded is that there is no commercial license, as it is based on open source. Until now, there were very few options in finding a suitable Java SE runtime for ARM32 other than Oracle. Oracle Java is a great product, but as all embedded developers know, Oracle’s Binary Code License limits usage and distribution of Java outside of general purpose computing. Zulu Embedded is taking those licensing costs and field-of-use restrictions off the table.
https://www.azul.com/
Tomi Engdahl says:
Hardware designer is a disappearing resource
lectronica – Finland has a long tradition as hardware, system and circuit design. In the future, this knowledge must need less and less. – It is becoming less and less relevant in what format the device is used, the Nordic countries, says Aho Titus sale of Avnet Embedded.
Just extinction Aho not iron the designer would like to declare that it would lead to the company’s difficulties. – It would be dangerous if no one would be able to specify products at hardware levels, says Aho.
The software is thus the King, also embedded applications. Card Computers are standard products and are found mainly in the choice of different card formats. Cards suppliers sequestered primarily in terms of service and support.
Embedded development changing more and more of encoding is also a bit of a problem for Finland. We do have would be a lot of talented designers, but many of them are more or less device designers. – It is not easy to leap to move to the software developer. Yes, it requires its own education
Source: http://etn.fi/index.php?option=com_content&view=article&id=5385:rautasuunnittelija-on-katoava-luonnonvara&catid=13&Itemid=101
Tomi Engdahl says:
Embedded Software’s Future: Platform-Based Development
http://www.designnews.com/author.asp?section_id=1386&doc_id=282052&itc=dn_analysis_element&&cid=nl.x.dn14.edt.aud.dn.20161111.tst004c
Every time a new embedded software project starts, the air is electrified with energy, hope, and excitement. For engineers, there are few things on Earth as exciting as creating a new project and bringing together new and innovative ideas that have the potential to change the world. Unfortunately, shortly after project kick-off, engineers can quickly lose their passion as they are forced to dig into the nuts and bolts by once again writing microcontroller drivers, trying to integrate real-time operating systems (RTOSes) and third-party components. These repetitive project tasks can consume time, energy, and dampen product innovation. An interesting solution is beginning to arrive that could help developers — embedded system platforms.
An embedded system platform contains all the building blocks that a developer needs to quickly get a microcontroller up and running in a short time period and direct their focus on the product. Too much time and money is wasted just trying to get a microcontrollers software up and running. The idea behind the platform is that drivers, frameworks, libraries, schedulers, and sometimes even application code are already provided so that developers can focus on their product features rather than the mundane and repetitive software tasks.
Embedded software platforms provide developers with an opportunity to shave months from the development cycle by leveraging existing HALs and APIs. Becoming a microcontroller expert in all the little nuances is no longer required. HALs and APIs abstract the lower level hardware and make development similar to writing software on a PC, although developers still need to keep in mind that they are working in a resource-constrained environment. Make a simple call to that UART HAL and serial data can be transmitting in minutes rather than weeks.
There are many advantages to platform development that developers should keep in mind:
Leveraging existing software to prevent reinventing the wheel
Faster time to market
Potential to decrease overall project costs
Increased firmware robustness
There are certainly a few potential issues that developers should be concerned with, as well:
Platform licensing models
Cost to change platforms if direction changes in the future
Becoming dependent upon a third-party platform
Having too much free time due to smoothly moving projects
The truth is that embedded system development has become increasing complex in the past decade as microcontrollers have increased exponentially in their capability.
Tomi Engdahl says:
MicroLisp With Matching Parens
http://hackaday.com/2016/11/11/microlisp-with-matching-parens/
Lisp is a supremely elegant programming language, but you won’t find it around much today. That’s a shame; in the 80s and 90s, all the cool kids were using Lisp machines, computers dedicated to the creation and interpretation of Lisp. While the AI renaissance of the 80s is dead, replaced with the machine learning fad of today, Lisp machines have gotten much smaller. Now, they’ll fit in your pocket, and they have parenthesis matching, to boot.
If this build looks familiar, you’re not wrong. A while back, we saw a similar pocket Lisp computer based around the ATMega328 microcontroller with 32k of Flash and 2k of RAM. That’s not a lot by any measure, and a much more suitable processor for an AVR-based pocket Lisp machine would be the big boys of the ATMega family.
Tiny Lisp Computer 2
http://www.technoblogy.com/show?1INT
Tomi Engdahl says:
So you think you know C?
https://hackernoon.com/so-you-think-you-know-c-8d4e2cd6f6a6#.z3hw7j3uk
Tomi Engdahl says:
Home> Community > Blogs > Embedded Insights
Changing roles for embedded developers
http://www.edn.com/electronics-blogs/about-embedded/4443012/Changing-roles-for-embedded-developers?_mc=NL_EDN_EDT_EDN_today_20161115&cid=NL_EDN_EDT_EDN_today_20161115&elqTrackId=750f0d56a7d04df8abec512fe42cbea3&elq=89e210db955b47238bdc1daebffbc7bf&elqaid=34796&elqat=1&elqCampaignId=30364
When I started as an embedded developer (top processor speed was 500 kHz at that time), the job involved both hardware design and application software development (in assembly). Later, hardware and software development tended to separate as hardware engineers concentrated on solving tricky high-speed signal issues and software developers addressed things like memory constraints and real-time performance. But the rise of off-the-shelf hardware and software platforms based on powerful yet inexpensive processors with massive memory resources is changing the role of embedded developers once again.
There will always be a need for custom hardware and software in embedded applications, especially those with tight constraints on things like cost, power, performance, and footprint. But the range of platforms becoming available is addressing more and more of the application space, and the approach has considerable appeal in situations where time to market is the most pressing concern. When the core processing hardware, operating system drivers, and user interfaces are available off the shelf, designers have just the application code left to deal with.
Almost.
There is one problem with creating a system from a collection of off-the-shelf components. For the most part, those components were created in isolation from one another. So there is little to no guarantee that they will simply plug and play together.
This kind of system integration requires a somewhat different skill set than system design.
When you’re using off-the-shelf elements, however, you need to first learn how those elements work before you can figure out why they are not working together. Understanding someone else’s design can be a substantial challenge.
Fortunately, once you understand the platforms involved, creating the next system design using those platforms becomes a whole lot easier. Which is why development teams are moving toward platforms. From-scratch designs take essentially the same effort each time. Platform-based designs become easier and faster each time.
“Our view of the embedded market is that development will move from requiring detailed technical expertise to needing the integration and optimization of system software,”
The company’s new strategy, then, is based on four key principles:
Systems and ecosystems are becoming increasingly complex and interconnected
The technologies and standards are changing more quickly and more drastically
More experts, types of players and interactions are involved in each connected project
The “time to market” is becoming increasingly shorter and quick and easy solutions are expected.
Their conclusion: integrating effectively the various technologies and various software layers, from the hardware to the cloud, is becoming the key to success for connected/embedded projects.
To successfully build an embedded system in today’s climate, then, requires a combination of wide technology expertise (operating systems, board support packages, microcontrollers, cloud services, and the like) and strong system integration skills, including testing and validation, to deal with the IP that external partners provide. Large companies could have all these skills in house, but many development teams won’t, and will need help.
Tomi Engdahl says:
Embedded Software’s Future: Platform-Based Development
http://www.designnews.com/design-hardware-software/embedded-softwares-future-platform-based-development/139549642345540?cid=nl.x.dn14.edt.aud.dn.20161116.tst004c
Every time a new embedded software project starts, the air is electrified with energy, hope, and excitement. For engineers, there are few things on Earth as exciting as creating a new project and bringing together new and innovative ideas that have the potential to change the world. Unfortunately, shortly after project kick-off, engineers can quickly lose their passion as they are forced to dig into the nuts and bolts by once again writing microcontroller drivers, trying to integrate real-time operating systems (RTOSes) and third-party components. These repetitive project tasks can consume time, energy, and dampen product innovation. An interesting solution is beginning to arrive that could help developers — embedded system platforms.
An embedded system platform contains all the building blocks that a developer needs to quickly get a microcontroller up and running in a short time period and direct their focus on the product. Too much time and money is wasted just trying to get a microcontrollers software up and running.
The typical development time line has stayed roughly the same. With more to do, smaller budgets, and the same time to do it in, developers need to become smarter and find new methods and ways to develop their systems without compromising robustness, integrity, and features.
One possible solution is to use embedded platforms such as the Renesas Synergy Platform, Electric Imp, and Microchip Harmony, among others.
Platforms can vary from extending the traditional developers capabilities through radically transformational and different development techniques. In either case, given time, budget, and feature sets, it is very obvious that building embedded systems from the ground will very soon no longer be an option.
Tomi Engdahl says:
Startup Programs Multicores on Data, Not Gut
http://www.eetimes.com/document.asp?doc_id=1330844&
Multicores have been the force behind computing for more than a decade. The very idea of gaining speed in processing by breaking up problems in multiple pieces and computing the parts simultaneously took the electronics industry by storm.
But when it comes to programming a multicore system — whether multicores are homogeneous or heterogeneous, such an insurmountable task has been left to engineering teams’ “empirical experience” or their “seat-of-the-pants” programming, observed Kumar Venkatramani,vice president, business development at Silexica. “Software for these multicores has not come of age yet,” he said.
Silexica’s products include tools to expose parallelism and solve software mapping problems.
Growing problems
Programming for multicores is no cakewalk, especially at a time when the number of cores is exponentially growing and those cores include different computation engines such as CPUs and DSPs.
Take an example of 5G base stations, said Venkatramani. It’s not unusual to find a project in which designers are developing a system consisting of 500 cores where 55,000 tasks must run. 500 engineers are put to the task in programming it. The project would take 4 times longer to complete, 3 times more engineers, resulting in 4.5 times more costly, he explained.
For now, Silexica is targeting its tools for three key market segments. They include embedded vision/augmented reality, wireless broadband and autonomous driving/ADAS.
Common to all three segments is that these applications tend to “push the boundaries of available hardware,” noted the company. These segments also use applications that have little legacy.
Tomi Engdahl says:
Changing roles for embedded developers
http://www.edn.com/electronics-blogs/about-embedded/4443012/Changing-roles-for-embedded-developers?_mc=NL_EDN_EDT_EDN_review_20161118&cid=NL_EDN_EDT_EDN_review_20161118&elqTrackId=5a6cd1d7bef54ebcb710d7b31e033a53&elq=bbd34b5f5fa84ec89ba906fe83ee2914&elqaid=34852&elqat=1&elqCampaignId=30425
When the core processing hardware, operating system drivers, and user interfaces are available off the shelf, designers have just the application code left to deal with.
“Our view of the embedded market is that development will move from requiring detailed technical expertise to needing the integration and optimization of system software,” Chammings said. “In the early days, when the MCU was simpler, developers could do everything themselves. With the second generation they needed vendor support as well as operating systems and user interface software expertise. What’s coming now, though, is the consumerization of user interfaces, data collection and management, cloud ecosystems, and the like.”
The company’s new strategy, then, is based on four key principles:
Systems and ecosystems are becoming increasingly complex and interconnected
The technologies and standards are changing more quickly and more drastically
More experts, types of players and interactions are involved in each connected project
The “time to market” is becoming increasingly shorter and quick and easy solutions are expected.
Their conclusion: integrating effectively the various technologies and various software layers, from the hardware to the cloud, is becoming the key to success for connected/embedded projects.
Tomi Engdahl says:
IoT Developers, ‘Focus on Your Secret Sauce’
With the help of specilized IoT platforms, developers can cut months off their time to market.
http://www.designnews.com/iot/iot-developers-focus-on-your-secret-sauce/43789911646118?cid=nl.x.dn14.edt.aud.dn.20161121.tst004c
Heath, who will host a session titled, Rapid IoT Software Development Using Embedded Python , said that it’s tempting for experienced designers to want to do it all themselves, and then get tangled up in the complexities of routing algorithms and microcontroller interfaces. Instead, he said, it’s better for developers to use existing embedded platforms that help them tie their IoT applications to the cloud.
Without the help of such platforms, they will lose valuable time in getting their product to market, he said. “It’s going to take them longer to get to the same place,” he told us. “The first six months will be spent on solving problems – the routing algorithms and device interfaces. And six months later they say, ‘Now we can start on the real stuff.”
The demo will be done, he said, using tools from Synapse’s Things Platform , along with the Python programming language and Synapse’s SNAP operating system.
“We’re trying to show that in order to develop IoT applications you need a system that that includes an easy way to program,” he told us. “You need different tools at each layer that you can build your applications on.”
Tomi Engdahl says:
From Specification To Virtual Prototype
http://semiengineering.com/from-specification-to-virtual-prototype/
Differentiation and success for any embedded system comes from how effectively and rapidly new software features can be added.
The secret for success comes in mixing both hardware and software.
Tomi Engdahl says:
Ask Slashdot: Has Your Team Ever Succumbed To Hype Driven Development?
https://ask.slashdot.org/story/16/11/27/2017235/ask-slashdot-has-your-team-ever-succumbed-to-hype-driven-development
Someone reads a blog post, it’s trending on Twitter, and we just came back from a conference where there was a great talk about it. Soon after, the team starts using this new shiny technology (or software architecture design paradigm), but instead of going faster (as promised) and building a better product, they get into trouble. They slow down, get demotivated, have problems delivering the next working version to production.
Describing behind-schedule teams that “just need a few more days to sort it all out,” he blames all the hype surrounding React.js, microservices, NoSQL, and that “Test-Driven Development Is Dead” blog post by Ruby on Rails creator David Heinemeier Hansson.
Hype Driven Development
https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22#.syclh6uao
Software development teams often make decisions about software architecture or technological stack based on inaccurate opinions, social media, and in general on what is considered to be “hot”, rather than solid research and any serious consideration of expected impact on their projects. I call this trend Hype Driven Development, perceive it harmful and advocate for a more professional approach I call “Solid Software Engineering”. Learn more about how it works and find out what you can do instead.
Tomi Engdahl says:
Using Design by Contract for Developing Embedded Software
http://www.designnews.com/design-hardware-software/using-design-contract-developing-embedded-software/155558861246185?cid=nl.x.dn14.edt.aud.dn.20161201.tst004c
Embedded software design methodologies are meant to help guide engineers toward developing software that is more robust, has fewer bugs, and is more maintainable, to name a few coveted characteristics.
Embedded software design methodologies have been developed by the dozen if not by the hundreds. Methodologies are meant to help guide engineers toward developing software that is more robust, has fewer bugs, and is more maintainable, to name a few coveted characteristics.
One methodology that can be useful for developing embedded software interfaces is Design by Contract.
The term Design by Contract was first used, and later trademarked, by Bertrand Meyer in connection with the object-oriented programming language, Eiffel. The idea behind Design by Contract is that developers should be designing precise and verifiable software interfaces for components in their applications; in essence, they create a contract between the interface and the application code that will use the interface. For example, when creating a hardware abstraction layer interface for a GPIO component, each component interface would contain some method for defining the components pre-conditions, post-conditions, and invariants. In many circumstances, developers using an interface are often left in the dark about these conditions which can be quite dangerous.
For a designer to share and identify the pre-conditions and the post-conditions for a component makes sense, yet, very rarely do developers explicitly provide this information.
Design by Contract provides application developers a contract for using the component. If the preconditions are met, then the interface is contractually guaranteed to provide the specified post-condition from calling the interface.
Since the pre-conditions and post-conditions are fully specified up front, the component developer can use C assertions to validate that the contract is being met by the component user.
If any precondition is not met or an input value is out of range, this is a bug in the application software and the assertion will stop the application from executing and provide a message stating which file and line number the assertion is located in addition to how it failed. Once an application has been developed and all assertions have been met, the assertions can be turned off to decrease the code size and minimize overhead associated with the assertions.
Design by Contract sounds like a great idea but for embedded software developers simply following Design by Contract doesn’t quite go far enough. For example, in a standard implementation, interface implementers would not be responsible for detecting or handling errors that might occur.
Developers looking to improve an interfaces understanding can use techniques from Design by Contract and then take the methodology one step further by applying defensive programming techniques to the implementation. Relying on user application code to “do the right thing” can be dangerous given the speed at which software is developed and the pressure engineers are under to just make something work.
Design by Contract is by no means a new idea. It was first described in computer science literature as far back as 1986. Developers who are involved in creating API’s and HAL’s may find that borrowing ideas from this methodology can improve clarity and component use.
Tomi Engdahl says:
Embedded Hardware in Space. It’s Hard.
http://www.designnews.com/design-hardware-software/embedded-hardware-space-it-s-hard/123817169746181?cid=nl.x.dn14.edt.aud.dn.20161201.tst004c
Tomi Engdahl says:
Safety and Cybersecurity — You Can’t Have One Without the Other
Security planning needs to include safety. The two can no loner be separate concerns.
http://www.designnews.com/cyber-security/safety-and-cybersecurity-you-cant-have-one-without-other/61645859446201?cid=nl.x.dn14.edt.aud.dn.20161206.tst004c
On the plant network and across multiple devices, safety and cybersecurity have tended to be separate concerns. Yet in our increasingly unsafe networked world, the two considerations have started to bleed into one another. Device manufacturers and embedded software designers, need to be vigilant in order to provide a safe and secure system for applications to do their work.
safety, cybersecurity, wind River
The blend of security and safety will be covered in detail in the session There Is No Safety Without Security and No Security Without Safety by Michel Chabroux, on Wednesday, December 7 at ESC Silicon Valley .
Tomi Engdahl says:
Using Design by Contract for Developing Embedded Software
http://www.designnews.com/design-hardware-software/using-design-contract-developing-embedded-software/155558861246185?cid=nl.x.dn14.edt.aud.dn.20161205.tst004c
Embedded software design methodologies are meant to help guide engineers toward developing software that is more robust, has fewer bugs, and is more maintainable, to name a few coveted characteristics.
Embedded software design methodologies have been developed by the dozen if not by the hundreds. Methodologies are meant to help guide engineers toward developing software that is more robust, has fewer bugs, and is more maintainable, to name a few coveted characteristics. Methodologies vary in focus from being heavily reliant upon documentation all the way through being focused on cleverly crafting code to act as documentation. One methodology that can be useful for developing embedded software interfaces is Design by Contract.
Tomi Engdahl says:
Sophisticated Java Solutions Marry IoT and ARM Architecture
http://intelligentsystemssource.com/sophisticated-java-solutions-marry-iot-and-arm-architecture/
With an exploding number of devices for IoT and cloud computing, development with Java is becoming more attractive than ever. Java technologies for the ARM32 platform are a valuable piece of that puzzle.
Expanding Market Share
ARM has expanded its market share beyond the mobile and into embedded and IoT with its low power consumption and competitive price to compute ratio. It’s evident that ARM is now a mainstream embedded processor architecture. According to Linley Group, ARM has more than 77 percent of the licensed embedded processor market today and it has dominated the tablet and smartphone space. Now, it is expanding across consumer IoT markets and rapidly penetrating into the industrial IoT space where traditional x86, MIPS, and PowerPC processors have enjoyed a stable position for many years. According to ARM, it is looking to hit a compound annual growth rate of 5 percent in networking and 10 percent across all mobile, home, enterprise, and embedded segments by next year. In fact, major chipmakers are actively replacing legacy SoCs with ARM cores on their product roadmap
When ARM released its 64-bit ARMv8 with 32bit support, the mobile sector gobbled them up as soon as chip makers delivered them to the market. Now with devices like Raspberry Pi 3 (with 64-bit Cortex-A53) adoption of ARM has further increased—not only by the maker community but also by OEMs looking to take advantage of fast performance at an extremely competitive price. Sooner than expected by many, a revolutionary Pi Zero, 32-bit ARMv6 based SoC can be purchased for $5, is adding to the already huge ARM momentum. With its tiny form factor, Pi Zero consumes extremely low power, as low as 80mA. Yet it is fast and maintains binary compatibility with previous generations.
Java for Embedded & IoT
Java continues to be the most popular programming language. The latest TIOBE Index ranks Java as the #1 for the programming community. For the hardcore embedded community, C is still considered to be the most widely used programming language. However, interest and adoption of Java have been steadily growing
Java has been used in embedded devices since the 90s with Java ME CLDC (Micro Edition Connected Limited Device Configuration) used as a dominant platform for feature phones. Then Java ME CDC (Micro Edition Connected Device Configuration) and PBP (Personal Basis Profile) became a standard for Blu-ray disk players and cable television set-top boxes. Java SE began driving many embedded computers in the industrial setting and expanded into communications equipment and industrial printing.
Today Java SE is running on healthcare devices, network and storage appliances, gateways, automatic teller machines (ATMs), kiosks, imaging, and multi-function printers. With the advent of IoT, there is a blurring line between traditional embedded and enterprises.
For those that have been running Java, extending existing capabilities is less challenging. Besides, Cloud is what makes IoT possible today. IoT and Cloud are inseparable and a significant portion of the cloud computing platforms are Java-based. The third component that is critical for success is open source
Open Source Java & Zulu Embedded
A large portion of today’s technological innovations come from the open source community, Eclipse and Apache projects being good examples. For Java, OpenJDK is where open source Java has originated from. OpenJDK is the basis for Java SE’s Reference Implementation and the way the Java Spec is defined. Java SE is developed and maintained in the open under the OpenJDK projects. Companies such as Oracle, IBM, RedHat and Azul take the code in OpenJDK and use it to build JDKs.
Zulu Embedded is a certified build of OpenJDK for the embedded space. It supports both headful and headless modes. It also offers compact profiles of Java 8 for resource constrained devices in addition to Java 6 and 7. Java 8 Compact Profiles allow you to run Java in devices with a memory as low as 12mb. As far as operating systems are concerned, Zulu Embedded has been tested with most flavors of Linux, MacOS, as well as Windows 10 IoT Core.
Recently Azul Systems released Java APIs for accessing device peripherals. APIs are available on Windows 10 IoT and Linux as part of the Zulu Device APIs. Device APIs deliver optional Java extensions to the base Zulu Embedded JRE for enabling software control over device I/Os and their peripherals. It covers following peripheral access:
General Purpose Input/Output (GPIO).
Inter-Integrated Circuit Bus (I2C).
Serial Peripheral Interface.
For IoT services and gateway use cases, Zulu Embedded has been tested to work with all major OSGi implementations, including Eclipse and ProSyst.
Tomi Engdahl says:
Embedded Software Verification Issues Grow
http://semiengineering.com/embedded-software-verification-issues-grow/
Inconsistent results, integration issues, and lack of financial incentives to solve these problems point to continued problems for chipmakers.
Embedded software is becoming more critical in managing the power and performance of complex designs, but so far there is no consensus about the best way to approach it—and that’s creating problems.
Even with safety-critical standards such as DO-178C for aerospace and ISO 26262 for automotive, different groups of tool providers approach software from different vantage points. This produces inconsistent results, frequent incompatibilities that can make integration nightmarish, and it makes it hard to migrate technology from one project to the next or even from one design to a derivative design.
Rising complexity in heterogeneous SoC architectures only compounds the problem.
Tomi Engdahl says:
eForth for cheap STM8S Value Line gadgets
Turn cheap stuff from AliExpress into interactive development kits!
https://hackaday.io/project/16097-eforth-for-cheap-stm8s-value-line-gadgets
This project turns cheap “Value Line” STM8S µC based boards into interactive Forth development kits. To do this we learn how the hardware works, write board support code, and create documentation. The SDCC tool chain makes it possible to code in C while using the Forth core for testing, setting control parameters, or as an advanced scripting engine!
The code is based on STM8EF by Dr. C.H. Ting, the 2010 eForth Demo for the STM8S Discovery (2K RAM, 32K Flash) where kernel, interpreter, compiler, and debug tools fit in 5.5K Flash.
https://github.com/TG9541/stm8ef
Tomi Engdahl says:
8 pillars of embedded software
http://www.edn.com/electronics-blogs/embedded-basics/4442167/8-pillars-of-embedded-software?_mc=NL_EDN_EDT_EDN_today_20161219&cid=NL_EDN_EDT_EDN_today_20161219&elqTrackId=1106125f3c7c4a46bf5f03dabd670d89&elq=d7ba377ef607436089271baa9171b745&elqaid=35219&elqat=1&elqCampaignId=30769
Let’s examine each pillar and its role in embedded software development.
Pillar #1 – Architecture
Pillar #2 – Code Analysis
Pillar #3 – Debugging
Pillar #4 – Documentation
Pillar #5 – Programming language skills
Pillar #6 – Standards
Pillar #7 – Testing
Pillar #8 – Tools
Conclusions
Teams that master these eight pillars of embedded software will build their software upon a strong foundation. The majority of teams that I see fail lack expertise in at least one of these pillars. To ensure success, teams need to have expertise in each pillar and use a disciplined design approach.
More:
Mastering the 8 Pillars of Embedded Software
http://beningo.com/mastering-the-8-pillars-of-embedded-software/
Tomi Engdahl says:
The Missing Professional Software Engineer Mystery
Working toward a PE license is a great way for developers to stand apart from the pack.
https://www.designnews.com/design-hardware-software/missing-professional-software-engineer-mystery/10436903747192?cid=nl.x.dn14.edt.aud.dn.20161227.tst004c
Software engineers are everywhere. They develop the low-level firmware that drives our gadgets, the application code that allows us to interact with our devices, the software that manages the internet, satellites, medical devices, automobiles … the list goes on and on. Despite the abundant and ever-growing software developer ranks, there seems to be a mystery; the professional software engineers are missing!
Professional software engineers are those engineers that have successfully passed the NCEES Professional Engineering exam in the Software track. The mystery surrounding the missing professional software engineers is that after examining the latest exam data it is obvious that very few engineers are taking the software exam.
Becoming a Professional Engineer has many advantages such as:
Recognition in the work place
Commanding a higher salary
Access to opportunities that may require a PE license
Less hoops to jump through when serving as an expert witness
Second, developers may not even realize that the Software and Computer Engineering exams even exist! The Software exam was only added as an option within the last three to five years.
Tomi Engdahl says:
The mythical software engineer
http://www.edn.com/electronics-blogs/benchtalk/4443132/The-mythical-software-engineer?_mc=NL_EDN_EDT_EDN_review_20161216&cid=NL_EDN_EDT_EDN_review_20161216&elqTrackId=52703e99501b41b39023d5595d866af3&elq=520cdb1a53a84644bc5d68d279c003c6&elqaid=35204&elqat=1&elqCampaignId=30755
The term or title “Software engineer” has become so commonplace that many of us don’t give it a second thought. Are there actual software engineers? Or is this another example of the dilution and devaluation of the title “engineer”?
More years ago than I care to remember, I read about one university’s efforts to stamp out the term “software engineer” (I think it was McGill).
According to UW’s software engineering FAQ page, while all UW computer-related programs stress both hardware and software skills, and may have lots of overlap in terms of career prospects
Software engineer and author Steve McConnell says:
With only about 40% of software developers holding computer science degrees and practically none holding degrees in software engineering, we shouldn’t be surprised to find people confused about the difference between software engineering and computer science.
and
This puts computer science students into a technological no-man’s land. They are called scientists, but they are performing job functions that are traditionally performed by engineers, without the benefit of engineering training.
I recommend reading the whole chapter: Software Engineering, Not Computer Science
Software Engineering, Not Computer Science
http://www.stevemcconnell.com/psd/04-senotcs.htm
“A scientist builds in order to learn; an engineer learns in order to build.”
— Fred Brooks
Engineering vs. Science
With only about 40 percent of software developers holding computer science degrees and practically none holding degrees in software engineering, we shouldn’t be surprised to find people confused about the difference between software engineering and computer science. The distinction between science and engineering in software is the same as the distinction in other fields.[1] Scientists learn what is true, how to test hypotheses, and how to extend knowledge in their field. Engineers learn what is true, what is useful, and how to apply well-understood knowledge to solve practical problems. Scientists must keep up to date with the latest research. Engineers must be familiar with knowledge that has already proven to be reliable and effective. If you are doing science, you can afford to be narrow and specialized. If you are doing engineering, you need a broad understanding of all the factors that affect the product you are designing. Scientists don’t have to be regulated because they are chiefly accountable to other scientists. Engineers do have to be regulated because they are chiefly accountable to the public. An undergraduate science education prepares students to continue their studies. An undergraduate engineering education prepares students to enter the workforce immediately after completing their studies.
Universities award computer science degrees, and they normally expect their computer science students to obtain software development jobs in which they will immediately begin solving real-world problems. Only a small fraction of computer science undergraduates go on to graduate school or research environments in which they are advancing the state of knowledge about software or computers.
This puts computer science students into a technological no-man’s land. They are called scientists, but they are performing job functions that are traditionally performed by engineers, without the benefit of engineering training. The effect is roughly the same as it would be if you assigned a physics Ph.D. to design electrical equipment for commercial sale.
Beyond the Buzzword
Some people think that “software engineering” is just a buzzword that means the same thing as “computer programming.” Admittedly, “software engineering” has been misused. But a term can be abused and still have a legitimate meaning.
The dictionary definition of “engineering” is the application of scientific and mathematical principles toward practical ends. That is what most programmers try to do. We apply scientifically developed and mathematically defined algorithms, functional design methods, quality-assurance methods, and other practices to develop software products and services.
In software, a well-run project can be managed to meet any of the following product objectives:
Minimal defects
Maximum user satisfaction
Minimal response time
Good maintainability
Good extendibility
High robustness
High correctness
Each software project team should define the relative importance of each characteristic explicitly, and then the project team should conduct the project in a way that achieves its objectives.
a software team might also work to achieve any of the following project objectives:
Short schedule
Predictable delivery date
Low cost
Small team size
Flexibility to make mid-project feature-set changes
Each software project must strike a balance among various project and product goals. We don’t want to pay $5,000 for a word processor, nor do we want one that crashes every 15 minutes.
Tomi Engdahl says:
Getting started with MicroPython
http://www.edn.com/electronics-blogs/embedded-basics/4441798/Getting-started-with-MicroPython?_mc=NL_EDN_EDT_EDN_today_20161228&cid=NL_EDN_EDT_EDN_today_20161228&elqTrackId=3cfc113bb5da44448e7bb67a8719f79a&elq=f7ea26b1025a499698cbba99dafa41c6&elqaid=35324&elqat=1&elqCampaignId=30873
The first step a developer interested in MicroPython must take before diving into a real-time embedded application is to select a supported development kit or microprocessor. The best place for a developer look for a supported development kit is to check-out the MicroPython Github Board Summary page. Developers who want to get up and running quickly should consider the PyBoard, which comes with MicroPython already installed. Developers who want to use a development kit that is suitable for working with Arduino shields and don’t mind the extra step of putting MicroPython on the development kit (to learn how to compile and install MicroPython see Jacob’s videos) should consider using the Netduino Plus 2.
Once a developer has hardware running MicroPython, getting started with programming in MicroPython is relatively straight forward. The developer simply plugs their device into a PC over USB, which allows them to access the REPL (Read Evaluate Print Loop) terminal. The REPL allows a developer to test out commands and scripts using MicroPython simply by typing.
For example, a great first thing to try is to learn to control the on-board LEDs. Control of any microcontroller peripheral in MicroPython is done using the pyb library.
A developer can then access any microcontroller peripheral through the pyb library. For example, a LED can be turned on by typing pyb.LED(LED #).on() or turned off by typing pyb.LED(LED #).off().
Tomi Engdahl says:
Python’s role in developing real time embedded systems
goo.gl/aXJXb4
Python has become quite the trending program language over the last few years.
Below are five roles that developers may find Python playing in real-time embedded systems.
Role #1 – Device control and debugging
Role #2 – Automating testing
Role #3 – Data analysis
Role #4 – Real-time Software
Role #5 – Learning object oriented programming
Conclusions
Students and engineers are becoming very familiar with the Python programming language. One might consider the Maker movement and the Raspberry Pi to be a few reasons it has moved up the list in popularity. But also, the language itself is flexible, easy to learn, and can be adapted to work within a microcontroller based environment. Developers thus shouldn’t be surprised when they see Python cropping up and beginning to play a role in embedded system development.
Tomi Engdahl says:
Testing software to ensure a successful user experience
http://www.edn.com/electronics-blogs/brians-brain/4443198/Testing-software-to-ensure-a-successful-user-experience?_mc=NL_EDN_EDT_EDN_weekly_20161229&cid=NL_EDN_EDT_EDN_weekly_20161229&elqTrackId=1004066ffce24e409a08e32d9b99bfd1&elq=6a0ece316c0842b4a0808c224412b15e&elqaid=35341&elqat=1&elqCampaignId=30890
Tomi Engdahl says:
Transitioning to Python 3
http://www.linuxjournal.com/content/transitioning-python-3
The Python language, which is not new but continues to gain momentum and users as if it were, has changed remarkably little since it first was released. I don’t mean to say that Python hasn’t changed; it has grown, gaining functionality and speed, and it’s now a hot language in a variety of domains, from data science to test automation to education. But, those who last used Python 15 or 20 years ago would feel that the latest versions of the language are a natural extension and evolution of what they already know.
At the same time, changes to the language—and particularly changes made in Python 3.x—mean that Python 2 programs won’t run unmodified in Python 3. This is a known issue, and it was part of the process that Python’s BDFL (Benevolent Dictator for Life) Guido van Rossum announced back when the “Python 3000″ project was launched years ago. Guido expected it would take time for organizations to move from Python 2 to Python 3, but he also felt that the improvements to the language were necessary.
The first thing to ask is this: what exactly changed in Python 3? And, how easily can you move from Python 2 to Python 3? Or, how can you modify your Python 2 programs so they’ll continue to work in Python 2, but then also work unmodified in Python 3?
On the face of things, not very much actually changed in Python 3. It’s a cleaner, more efficient and modern language that works like more modern Python developers want and expect.
Tomi Engdahl says:
Atari Now Runs Java, Thankfully Doesn’t Require Constant Updates
http://hackaday.com/2017/01/02/atari-now-runs-java-thankfully-doesnt-require-constant-updates/
Java Grinder is a tool that compiles Java programs to run on platforms like microcontrollers and consoles, by outputting native assembly code and using APIs to work with custom hardware like bespoke graphics and sound chips.
At the end of the day, porting Java code to a system with 128 bytes of RAM probably isn’t going to be particularly useful. However, as a coding exercise and learning experience, there’s a lot of value here in terms of building your skills as a coder. Other such experiments have shown us Java running on other unexpected devices, like the Sega Genesis or the MSP430.
Atari 2600 Java
http://www.mikekohn.net/micro/atari2600_java.php
Tomi Engdahl says:
Java Grinder
http://www.mikekohn.net/micro/java_grinder.php
Java Grinder is a tool that gives the ability to write programs in Java to run natively on microcontrollers, game consoles, and computers. Java Grinder is not a JVM, but instead translates byte-code from Java .class files into native assembly code much like a JIT or an “ahead of time” compiler. On the microcontrollers, there is a Java API to take advantage of the I/O ports, UART, SPI, and more. On the game console / computer side, there are Java API’s to manipulate the graphics and sound chips.
Tomi Engdahl says:
Why JavaScript is used in IoT
http://blog.hackerearth.com/javascript-in-iot
In 1995, JavaScript emerged as programming language to create web pages. Brendan Eich developed JavaScript with syntax similar to C, but nobody believed that JavaScript would play a major role in development of commercial softwares. In 1997, JavaScript was made a standard through ECMA international.
Now JavaScript is widely used in web pages, web servers, mobile apps, and IoT systems.
You ask me why JavaScript is used in building IoT systems? Here are my reasons.,
JavaScript is a event-driven language
It is quite good at event-driven applications. In event driven applications, every device listens to various other events and responds to concerned events.
Memory management
JavaScript has a garbage collector, which eliminates the need of explicitly freeing up the memory. This allows embedded developers to focus on other important aspects of development. The automatic freeing of the unused memory results in a stable product because the garbage collector eliminates memory leaks.
Existing JavaScript tools, libraries and plugins
With the increased use of JavaScript in various applications, there are many JavaScript development resources available, such as
JavaScript libraries like Underscore.js, lodash, traverse, and Async
Testing tools like Blue Ridge, SugarTest, FireUnit, JSLint etc.
Client-side development framework
Server-side JavaScript APIs and others
JavaScript compatible hardware solutions
A wide variety of hardware solutions in IoT, such as Raspberry Pi, Espruino, etc.. support Node.js. There are JavaScript-only microcontrollers such as Tessel 2 and Espruino which have proven to be very useful in IoT projects. Thousands of Node Package Manager (NPM) modules for Node.js such as PM2, Socket.io, Mocha etc. have been developed to enhance the power of Node.js in IoT.
End-user scripting
End user scripting can be enabled by embedded devices using JavaScript
End-user scripting
End user scripting can be enabled by embedded devices using JavaScript
JavaScript is widely used across internet
JavaScript is easy to learn
Familiar Syntax
Popularity of Node.js !
Tomi Engdahl says:
Browsing Forth
http://hackaday.com/2017/01/04/browsing-forth/
Forth has a strong following among embedded developers. There are a couple of reasons for that. Almost any computer can run Forth, even very small CPUs that would be a poor candidate for running programs written in C, much less host a full-blown development environment. At its core, Forth is very simple. Parse a word, look the word up in a dictionary. The dictionary either points to some machine language code or some more Forth words. Arguments and other things are generally carried on a stack.
There’s even a version for the ESP8266 and the Arduino
Tomi Engdahl says:
Testing software to ensure a successful user experience
http://www.edn.com/electronics-blogs/brians-brain/4443198/Testing-software-to-ensure-a-successful-user-experience?_mc=NL_EDN_EDT_EDN_today_20170103&cid=NL_EDN_EDT_EDN_today_20170103&elqTrackId=0c2d0a2aba524de7aa84f3a36b9d8353&elq=3b20a60498cf48bf910e1e0bc3bdbeb5&elqaid=35383&elqat=1&elqCampaignId=30932
Tomi Engdahl says:
eForth for cheap STM8S Value Line gadgets
Turn cheap stuff from AliExpress into interactive development kits!
https://hackaday.io/project/16097-eforth-for-cheap-stm8s-value-line-gadgets
This project turns cheap “Value Line” STM8S µC boards into interactive Forth development kits by learning how a board works, and writing board support code and docs. Using the SDCC tool chain it’s possible to combine C code with a Forth shell for testing, setting control parameters, or as a scripting engine!
The code is based on the STM8EF eForth Demo by Dr. C.H. Ting for STM8S Discovery.
Tomi Engdahl says:
Finding Evasive System-Level Bugs Using Memory Consistency Algorithm
Tackling a bug, like catching jewel thieves, is easier when you can narrow down the suspects.
http://semiengineering.com/finding-evasive-system-level-bugs-using-memory-consistency-algorithm/
Looking for an anomaly is not just a good way to find the bad guys in real life, it’s also good for finding bad things in a design. There was a project at Stanford University called DIDUCE, which instrumented a compiler to save all values taken on by a variable when a program was run. The project was run by Dr. Monica Lam, and a paper on it can be found here: http://suif.stanford.edu/papers/Diduce.pdf.
Essentially, the program looks at the values taken on by all variables over time, finds the unusual values, and brings these values to the attention of the programmer to see if they represent a bug. If a variable usually has values between 500 and 1000, except once when it took on the value 2,384,294,103 — this might be a bug. Even though the program may not fail on any specific test case, it is probably worth looking to see what is going on around this unusual occurrence. The project found a frightening number of latent bugs in a number of open source projects, including bugs in the Java secure socket layer. The paper is definitely worth a read.
And we can apply these same hunting techniques to our system level debug, looking for what is there but shouldn’t be.
Codelink is a non-intrusive debug technology. It enables a debugger to show you what is going on in the processor, but it does not affect the program execution in any way. As a result, it makes it a lot easier to find problems like this one. Codelink traces the processor as it runs and stores the data in what we call a “replay database.” It uses this database to reconstruct the state of the processor. Embedded in this are all the read and write operations that took place while the program was running. Sure, it’s a lot of data — literally gigabytes for a Linux boot. But that is exactly what is needed for feeding a big data algorithm.
So from the billions of read and write operations, after filtering out the IO locations I was left with dozens of suspect values. A few dozen suspects I can hunt down.
The source of the problem was that the processor was sending out two transactions to two different peripherals. The bus fabric needed to notice this, as per the spec, and force the ordering of the return. But the guy who wrote the bus fabric missed this tiny detail
Tomi Engdahl says:
Optimizing Linux for Slow Computers
http://hackaday.com/2017/01/19/optimizing-linux-for-slow-computers/
Linux distributions, at least the general purpose ones, have to be all things to all people. Which means that the way they work has to deliver acceptable performance to multiple use cases, from servers through desktops, portable, and even mobile devices. Those low-level power users we mentioned earlier can tweak their systems to release any extra performance, but the rest of us? We just have to put up with it.
To help us, [Fabio Akita] has written an excellent piece on optimizing Linux for slow computers. By which he means optimising Linux for desktop use on yesterday’s laptop that came with Windows XP or Vista, rather than on that ancient 486 in the cupboard. To a Hackaday scribe using a Core 2 Duo, and no doubt to many of you too, it’s an interesting read.
Optimizing Linux for Slow Computers
http://www.akitaonrails.com/2017/01/17/optimizing-linux-for-slow-computers
Tomi Engdahl says:
Low-Cost Programmable Power Supply
Chinese “LM2596 DC/DC buck converter with voltmeter” + “some wires” + “Forth” = “programmable power supply”
https://hackaday.io/project/19647-low-cost-programmable-power-supply
Programmable power supplies are essential for test automation but they are pricey. Using results from the “eForth for cheap STM8S Value Line gadgets” this project tries to bring the cost/programmability ratio to a record low by using very cheap Chinese DC/DC converter modules with a µC based voltmeter. With the right trade-offs the programmability is basically for free!
price per unit < $3 (excluding the external power source)
A quick search for "LM2596 DC 4.0-40 to 1.3-37V Adjustable Step-Down" on AliExpress presents a range of cheap DC/DC converters with voltmeter with at a price starting from $1.50.
By chance I found out that the voltmeter is based on the low-cost µC STM8S003F3P6.
Tomi Engdahl says:
Friday Hack Chat: CircuitPython with Adafruit Engineers
http://hackaday.com/2017/01/25/friday-hack-chat-circuitpython-with-adafruit-engineers/
What the heck is CircuitPython? Get that question answered along with many more during this Friday’s Hack Chat. Three engineers from Adafruit join us as [Ladyada], [Tony DiCola], and [Scott Shawcoft] lead a CircuitPython discussion at Noon PST on 1/27/17.
CircuitPython is Adafruit’s new extension on the MicroPython codebase. It adds support for SAMD21 processors in MicroPython and reworks the API for better support across platforms and better documentation. Does this still sound like jibberish? The Python programming language has been extended to microcontrollers.
Tomi Engdahl says:
Forth: The Hacker’s Language
http://hackaday.com/2017/01/27/forth-the-hackers-language/
Let’s start right off with a controversial claim: Forth is the hacker’s programming language. Coding in Forth is a little bit like writing assembly language, interactively, for a strange CPU architecture that doesn’t exist. Forth is a virtual machine, an interpreted command-line, and a compiler all in one. And all of this is simple enough that it’s easily capable of running in a few kilobytes of memory. When your Forth code is right, it reads just like a natural-language sentence but getting there involves a bit of puzzle solving.
Tomi Engdahl says:
Windows 10 is increasing in embedded
ARM and Linux is probably the most popular combination of a variety of embedded applications, but also for versions of Microsoft’s Windows 10 operating system for embedded applications are gaining a foothold.
A good example of this is the German card manufacturer Congatec’s statement that its products will also support Windows 10 IoT IoT Enterprise, and Core editions. Support applies to both Intel’s processor (Atom, Celeron, Pentium, Core and Xeon) cards and modules are based on the AMD R- and G-Series embedded processors are based on the products.
Windows 10′s embedded versions of customized applications are different from the desktop version, for example, so that the operating system works on a smaller memory and its security features are much higher.
Source: http://etn.fi/index.php?option=com_content&view=article&id=5756&via=n&datum=2017-01-31_16:09:57&mottagare=30929
Tomi Engdahl says:
Developer Argues For ‘Forgotten Code Constructs’ Like GOTO and Eval
https://developers.slashdot.org/story/17/02/04/1751211/developer-argues-for-forgotten-code-constructs-like-goto-and-eval?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Slashdot%2Fslashdot%2Fto+%28%28Title%29Slashdot+%28rdf%29%29
Some things in the programming world are so easy to misuse that most people prefer to never use them at all. These are the programming equivalent of a flamethrower… [But] creative use of features such as goto, multiple inheritance, eval, and recursion may be just the right solution for experienced developers when used in the right situation. Is it time to resurrect these four forgotten code constructs?
4 forgotten code constructs: Time to revisit the past?
https://techbeacon.com/revisiting-forgotten-code-constructs
“There is no programming language—no matter how structured—that will prevent programmers from making bad programs.” —Larry Flon
That’s where a few of the old, forgotten code constructs come into play. Creative use of features such as goto, multiple inheritance, eval, and recursion may be just the right solution for experienced developers when used in the right situation.
In software development, one of the most important skills you can have is knowing how to evaluate tradeoffs. Once you get better at choosing the right way over the popular way, you’ll gain a lot in code clarity, readability, and reduced development time.
Tomi Engdahl says:
Integration of vision in embedded systems
http://www.vision-systems.com/articles/print/volume-22/issue-1/features/integration-of-vision-in-embedded-systems.html?cmpid=enl_vsd_vsdnewsletter_2017-02-13
Embedded vision architectures enable smaller, more efficient vision solutions optimized for price and performance.
Embedded computer systems usually come into play, when space is limited and power consumption has to be low. Typical examples are mobile devices, from mobile test equipment in factory settings to dental scanners. Embedded vision is also a great solution for robotics, especially when a camera has to be integrated into the robot’s arm.
Furthermore, the embedded approach allows reducing the system costs compared to the classic PC-based setup. Let’s say you spend $1,700 on the system with a classic camera, a lens, a cable and a PC. An embedded system with the same throughput would cost $300, because each piece of hardware is cheaper
Because embedded architectures require greater up-front development resources to result in lower unit cost, volume is a key factor to consider when deciding to launch an embedded machine vision or image processing project.
So be it smart industrial wearables, automated parking systems, or people counting applications, there are several embedded system architectures available for integrating cameras into your embedded vision system.
In the machine vision world, a typical camera integration works with a GigE or USB interface, which more or less is a plug-and-play solution connected to a PC (or IPC). Together with a manufacturer’s software development kit (SDK) it is easy to get access to the camera and this principle can be transferred to an embedded system
Utilizing a single-board computer (SBC), this basic integration principle remains the same
Popular single-board computers like Raspberry Pi or Odroid have compatible interfaces (USB/ Ethernet). There are also industry-proven single-board computers available from companies such as Toradex (Horw, Switzerland; http://www.toradex.com) or Advantech (Taipei, Taiwan; http://www.advantech.com) that provide these standard interfaces.
The major differences are the processor types that these single-board computers are equipped with. Although there are SBCs available with x86-based processors, most processing units use ARM type processors because they typically consume less power.
More and more camera manufacturers provide their software development kit (SDK) also in a version working on an ARM platform, so that users can integrate a camera in a familiar way as on a Windows PC.
In the best case, the SDK provides the same functionality and APIs (application programmable interfaces) for both platforms
Embedded systems can be specialized to an even higher level, when the processing technology needs to be even more stripped down, for certain applications. That is why many systems are based on a system on module (SoM).
Special image data transfer
A direct camera-to-SoC-connection for the image data transfer can be achieved by an LVDS-based connection or via the MIPI CSI2 standard. Both methods are not clearly standardized from the hardware side. This means there are no connectors specified, not even numbers of lanes within the cable. As a result, in order to connect a specific camera, a matching connector must usually be designed-in on the carrier board and is not available in standardized form on an off-the-shelf single-board computer.
CSI2, a standard coming from the mobile device industry, describes signal transmission and a software protocol standard. Some SoCs have CSI interfaces and there are drivers available for selected camera modules and dedicated SoCs. However, they are not working in a unified manner and there are no generic drivers.
While LVDS is a widely-used connection for high-speed data transfer, with defined signal transmission principles, there is no standardized software protocol for image data transfer either.
Another aspect of these board-to-board connections is the camera configuration. Controlling signals can be exchanged between SoC and camera via various bus systems, e.g. CAN, SPI or I²C. As yet, no standard has been set for this functionality. It depends on the camera manufacturer, which imaging parameters can be controlled and how.
Conclusion
Embedded vision can be an interesting solution for certain applications; several applications based on GigE or-more typically-on USB, can be developed using single-board computers. Given that these types of hardware are popular and offer a broad range in price, performance and in compliance with quality standards (consumer and business), this is a reasonable option for many cases.
For a more direct interface, LVDS or CSI2-based camera-to-SoC connections are possible for image data transfer. However, there is no comprehensive industrial standard established for a broad variety of technological requirements, or for all platforms.
Tomi Engdahl says:
Leveraging embedded vision system performance for more than just vision
http://www.vision-systems.com/articles/print/volume-21/issue-11/features/leveraging-embedded-vision-system-performance-for-more-than-just-vision.html?cmpid=enl_vsd_vsdnewsletter_2017-02-13
Machine vision has long been used in industrial automation systems to improve production quality and throughput by replacing manual inspection traditionally conducted by humans. Ranging from pick and place and object tracking to metrology, defect detection, and more, visual data is used to increase the performance of the entire system by providing simple pass-fail information or closing control loops.
With the performance of processors doubling every two years and the continued focus on parallel processing technologies such as multicore CPUs, GPUs, and FPGAs, vision system designers can now apply highly-sophisticated algorithms to visual data and create more intelligent systems.
This increase in technology opens up new opportunities beyond just more intelligent or powerful algorithms.
However, as system performance increases, taking this hardware-centric approach can be difficult because these systems are often connected through a mix of time-critical and non-time-critical protocols. Connecting these different systems together over various communication protocols leads to bottlenecks in latency, determinism, and throughput.
Finally, because of this distributed, hardware-centric approach, designers are forced to use disparate design tools for each subsystem-vision-specific software for the vision system, motion-specific software for the motion system, and so on. This is especially challenging for smaller design teams where a small team, or even a single engineer, is responsible for many components of the design.
A software-centric design approach allows designers to simplify their control system structure by consolidating different automation tasks, including visual inspection, motion control, I/O, and HMIs within a single powerful embedded system.
Tomi Engdahl says:
Remember old approaches:
Secrets for designing with flashing LEDs
http://www.edn.com/design/led/4457692/Secrets-for-designing-with-flashing-LEDs
Almost every micro-based project that I have designed in the past 25 years has had a flashing LED, originally as a “health” indicator, but the feature has expanded to use as a status indicator where the number and length of the flash can impart more information. This technique is very common in providing diagnostic information on low end products where there is only a single LED to provide communication. Devices like furnace controllers spring to mind.
On some occasions I have designed products with quite a few LEDs.
Flashing LEDs
http://www.embedded.com/electronics-blogs/without-a-paddle/4457638/Flashing-LEDs
Where I have only used one LED to convey information, I have never really been consistent and often re-wrote software from scratch as the presented information differed. The code would consist of separate blocks to flash the LED under normal circumstances and then some code to vary timing and number of flashes. I never figured out a simple approach until now.
I created an array of 15 32-bit variables. Each element of the array corresponds to a particular LED (there being 15 of them). I chose an update timer of 100ms which seemed to me optimal for the eye to detect and register especially when trying to count flashes. At each timer “tick” the processor looked at each bit of the element of the array in turn. If the bit was set, the LED was turned on, and conversely if the bit was cleared the LED was turned off.
(Please note that this is done via the aforementioned lookup table). This would give me a cycle time of 3.2 seconds (32 * 0.1). If the LED was to be continuously illuminated, the concomitant variable would be set to 0xffffffff. Three short flashes could be 0xa8000000, and one long and 2 short could be 0xf0a00000. In my case the processor would have to analyse all 15 variables at each timer tick.
Tomi Engdahl says:
Security IoT devices is a bad way
Barr Group’s recent survey shows that the designers of embedded devices are still not taking seriously enough security devices.
Barr query explained that 60 per cent of IoT Developers does not rely on the use of the best design work security devices in their designs. For example, 56 prosenttiaei make regular source validation errors or bugs or security holes to find.
The study also explained that 60 per cent of the designers did not visit any of the static source code analysis tool for checking. 25 per cent have no bug database, or any other system known to have a problem with being monitored.
More than a third, or 37 percent of IoT Developers do not take advantage of any written / documented coding standards.
Barr Group Chief Technology Officer Michael Barr says this is a big problem, because the embedded devices are the door to the Internet. – There are a number of simple practices that are known to lead to safer systems, such as version control, code review, static analysis and coding standards.
Source: http://www.etn.fi/index.php/kolumni-ecf/5915-iot-laitteiden-tietoturva-on-retuperalla