E-ALE is a Free & Open Source Linux Training Program for Embedded Engineers

E-ALE official hardware kit

As I wrote about the Embedded Linux Conference 2019 schedule a few days ago, I found out one of talk planned to use E-ALE hardware kit for the session. I had never heard about this kit, but a quick search led me to e-ale.org website which explains E-ALE stands for Embedded Apprentice Linux Engineer. The training program is made for embedded engineers with experience designing firmware for microcontrollers, but now need to transition to embedded Linux. Training only happens in-person (no webinar) at existing Embedded Linux conferences and is comprised of 8 to 9 seminars over 2 to 3 days. It usually starts with a presentation on one subject, followed by lab time to practice the relevant learned skills. The training takes place on the E-ALE kit at each conference, but it does not refer to a specific hardware platform. In most conferences, the PocketBeagle and BaconBits add-on board are used to lab sessions, but for example this year at …

Embedded Linux Conference & Open Source Summit 2019 Schedule

Embedded Linux Conference 2019 Schedule

In the last few years, I covered the Embedded Linux Conference and IoT Summit schedules since both were happening at the same time and in the same location. But the Linux Foundation have recently announced the Embedded Linux Conference will combine with the Open Source Summit, so the IoT Summit appears to have been phased out. The full schedule for the events taking place on August 21 – 23, 2019 at the Hilton San Diego Bayfront, USA, has also been released, so I’ll create a virtual schedule with some of the sessions most relevant to this blog. Wednesday August 21, 2019 11:30 – 12:05 – What’s New with U-Boot? by Simon Glass, Google LLC U-Boot is a widely used bootloader in embedded systems. Many users are unaware of the wide feature-set of U-Boot, particularly features added in the last few years. This talk aims to bring users (and prospective users) up to speed on the state of the art in …

Fusion for TIVA v8 Development Board Enables Debugging & Programming over WiFi

Fusion for TIVA V8 Development Board

Texas Instruments TIVA Arm Cortex-M4 MCU family was first introduced in 2013, I tested a TIVA Launchpad the following years, and since microcontrollers have usually a long life span they are still in use today, and should still be available for many years. I’m writing about this TI MCU family today because MikroElektronika has just announced Fusion for TIVA V8 development board for TI TIVA, Stellaris and MSP432 microcontrollers with plenty of I/Os including some MikroBus expansion slots, as well as support for debugging and programming over WiFi in addition to the usual USB-UART interface. Fusion for TIVA v8 board specifications: MCU – Socket for MikroElektronika MCU CARD Display Interfaces 2x 20-pin TFT display connector 1x 16-pin LCD connector for 2×16 characters LCD displays in 4-bit mode,  optional PWM backlight driving feature Programming – On-board CODEGRIP programmer/debugger, JTAG connector for connecting an external programmer/debugger Connectivity – Ethernet port, WiFI in CODEGRIP programmer/debugger USB – 1x USB port, 1x USB-UART, Expansion …

Eclipse IoT Survey Report Reveals Arm & Linux Dominate, Security Concerns

Constrained devices Arm IoT

The Eclipse IoT Working Group has just released a report asking the global IoT developer community to share their perceptions, requirements, and priorities. And with over 1,700 individuals taking the survey between February and March 2019, the key findings are interesting: IoT drives real-world, commercial outcomes today. 65% of respondents are currently working on IoT projects professionally or will be in the next 18 months. IoT developers mostly use C, C++, Java, JavaScript, and Python AWS, Azure, and GCP are the leading IoT cloud platforms Top three industry focus areas remain the same as last year: IoT Platforms, Home Automation, and Industrial Automation / IIoT. MQTT remains the dominant IoT communication protocol leveraged by developers The Eclipse Desktop IDE is the leading IDE for building IoT applications The last point may be slightly biased because the survey was done by the Eclipse IoT Working Group, so most respondents were already familiar with the Eclipse IDE. Security concerns dropped slightly compared …

Zero-overhead Destructors in C

CNXSoft: This is another guest by Blu, this time about C programming, and specifically destructors in C programming language If you asked seasoned C++ developers what their favorite features in the C++ language might be, chances are that destructors would be on everybody’s shortlist. As many other C++ developers, I too tend to do my occasional share of C, and if there’s one feature I dearly miss in C that is destructors ‒ precisely in their capacity of automating the release of resources at the right moment. But first a disclaimer is in order: many people call simple application of destructors ‘RAII’ ‒ ‘Resource Acquisition Is Initialization’; I find this acronym unnecessarily awkward and obfuscating an otherwise straightforward concept, so you won’t see this acronym through the end of this text. Instead, I’ll be using ‘end-of-scope’ action. Traditionally, in the language of C end-of-scope (more often end-of-function) actions are achieved via deliberate arrangement of the control flow, often via goto’s …

Self-hosted GLES on ChromeOS, part two

This is a follow-up post from an earlier guest post by Blu about OpenGL ES development on Chrome OS. One can’t practice real-time rendering to disk files for long ‒ it’s just unnatural. So after checking that my habitual GLES tests work as intended on ChromeOS when rendering to an off-screen-buffer-subsequently-saved-to-a-PNG, the next step was to figure out a way how to show frames on screen at a palpable framerate, if possible. Being as new to Chrome OS as the next guy, I had to start from scratch with ‘How to show EGL surfaces on screen fast’. In the comments section to the first article William Barath kindly mentioned that there was a wayland client library on Chromebrew, so I decided to pursue that as I had had (positive) prior experience with wayland. Long story short, the established way on most platforms for connecting wayland to EGL (or vice versa) is to ask wayland/weston for an EGL-compatible window surface, and …

MicroWebSrv Lightweight HTTP Web Server Supports HTML/Python Language Templating

There are many languages that can be used to create a web page: HTML,  HTML5, JavaScript, PHP, etc… But Python? Apparently yes, as MicroWebSrv  lightweight web server – mostly designed for ESP32 platforms running MicroPython such as Pycom boards – supports inserting Python code inside “HTML” files with the extension .pyhtml. The code can be found in Github, and is only comprised of three files. microWebSrv.py – The Web server microWebSocket.py – The optional support of WebSockets microWebTemplate.py – The optional templating language for .pyhtml rendered pages Beside HTML/Python files, the web server can handle GET, POST, … requests, an embedded full REST API, routing handlers, WebSockets, etc… That’s what a mixed HTML + Python .pyhtml file may look like: You can use double curly braces {{ and }} to insert MicroPython code, if statements, for loops, or includes. I’m not sure if this makes really sense for all platforms, but if your board is resource limited, and already runs …

Self-hosted OpenGL ES Development on ChromeOS?

opengles chromeos

This is a guest post by blu about developing OpenGL ES applications on Chrome OS. Ever since I’ve been using a chromebook in developer mode as my daily notebook (can’t beat 10h-plus battery life on ~300EUR well-performing machines), I’ve been missing one thing ‒ OpenGL ES coding under ChromeOS. My chromebook is more than well-equipped for GLES3 hardware-wise (verified via dual-booting to ArchLinux), and I always have up-to-date toolchains self-hosted under ChromeOS, thanks to an excellent package manager aptly named Chromebrew. And yet my coding-on-the-go under ChromeOS has been limited to console apps ‒ ChromeOS has strict limitations which include no X11 display manager, or any other industry-standard display manager that I’m aware of, and I don’t feel like dual-booting into ArchLinux too often ‒ ChromeOS has spoiled me with its fine-tuned performance. The no-display-manager limitation of ChromeOS is usually worked-around via Crouton but in my case Crouton would not help ‒ no 3D-hardware-accelerated support on ARM chromebooks. So in …