Linux has come a long way from its roots, where users had to compile the kernel and all of the other source code from scratch, often without any internet connection at all to help with documentation. It was the wild west of Linux, and while we can all rely on an easy-to-install Ubuntu distribution if we need it, there are still distributions out there that require some discovery of those old roots. Meet SkiffOS, a lightweight Linux distribution which compiles on almost any hardware but also opens up a whole world of opportunity in containerization.
The operating system is intended to be able to compile itself on any Linux-compatible board (with some input) and yet still be lightweight. It can run on Raspberry Pis, Nvidia Jetsons, and x86 machines to name a few, and focuses on hosting containerized applications independent of the hardware it is installed on. One of the goals of this OS is to separate the hardware support from the applications, while being able to support real-time tasks such as applications in robotics. It also makes upgrading the base OS easy without disrupting the programs running in the containers, and of course has all of the other benefits of containerization as well.
It does seem like containerization is the way of the future, and while it has obviously been put to great use in web hosting and other network applications, it’s interesting to see it expand into a real-time arena. Presumably an approach like this would have many other applications as well since it isn’t hardware-specific, and we’re excited to see the future developments as people adopt this type of operating system for their specific needs.
Thanks to [Christian] for the tip!
When I began programming microcontrollers in 2003, I had picked up the Atmel STK-500 and learned assembler for their ATtiny and ATmega lines. At the time I thought it was great – the emulator and development boards were good, and I could add a microcontroller permanently to a project for a dollar. Then the ESP8266 came out.
I was pretty blown away by its features, switched platforms, except for timing-sensitive applications, and it’s been my chip of choice for a few years. A short while ago, a friend gave me an ESP32, the much faster, dual core version of the ESP8266. As I rarely used much of the computing power on the ESP8266, none of the features looked like game changers, and it remained a ‘desk ornament’ for a while.
About seven weeks ago, support for the
libSodium Elliptic Curve Cryptography library was added. Cryptography is not the strongest feature of IoT devices, and some of the methods I’ve used on the ESP8266 were less than ideal. Being able to more easily perform public-private key encryption would be enough for me to consider switching hardware for some projects.
However, my preferred automated build tool for NodeMCU wasn’t available on the ESP32 yet. Compiling the firmware was required – this turned out to be a surprisingly user-friendly experience, so I thought I’d share it with you. If I had known it would be so quick, this chip wouldn’t have sat on my desk unused quite so long! Continue reading “Compiling NodeMCU For The ESP32 With Support For Public-Private Key Encryption”
Regular reader [MS3FGX] recently wrote a guide to compiling OpenWRT from source. You may be wondering why directions for compiling an open source program warrant this kind of attention. The size and scope of the package make it difficult to traverse the options available to you at each point in the process, but [MS3FGX] adds clarity by discussion as much as possible along the way.
OpenWRT is an open source alternative firmware package that runs on may routers. It started as a way to unlock the potential of the Linksys WRT54G. But the versatility of the user interface, and the accessibility of the Linux kernel made it a must-have for any router. This is part of what has complicated the build process. There are many different architectures supported and you’ve got to configure the package to build for your specific hardware (or risk a bad firmware flash!).
You’ll need some hefty hardware to ease the processing time. The source package is about 300 MB but after compilation the disk usage will reach into the Gigabyte range. [MS3FGX] used a 6-core processor for compilation and it still took over 20 minutes for a bare-bones distribution. No wonder pre-built binaries are the only thing we’ve ever tried. But this is a good way to introduce yourself to the inner workings of the package and might make for a
frustrating fun weekend project.
Relief is here from long compile times when developing firmware for your Arduino project. [Paul] was puzzled by the fact that every file used in a sketch is fully recompiled every time you hit upload–even if that file didn’t change. To make things more confusing, this behavior isn’t consistent across all Arduino compatible hardware. The Teensy has an additional feature not seen when working with other hardware boards in that it reuses previously compiled code if nothing has changed. It even tells you which files are being reused, as shown in the image above.
After the break we’ve embedded [Paul’s] video that walks us through the process of editing the Arduino IDE to reuse previously compiled files. It’s a one-liner addition to the boards.txt file. For example, if you’re working with the Arduino Uno all that needs to be added is ‘uno.build.dependency=true’. [Paul] had previously submitted a patch to roll this into the Arduino IDE source code, but it was not accepted citing a need for more testing. He’s asking for help with that testing and wants you to post your thoughts, or any bug information, on the new issue he’s opened regarding this feature. Continue reading “Get The Lead Out Of The Arduino Compile Process”
[Sergio Campamá] wrote in to tell us he’s assembled a guide for compiling the latest release of MSPGCC. This is a cross-compiling tool chain for the popular MSP430 line of microncontrollers. We used a version available from the Ubuntu repositories when developing with the TI Launchpad and the eZ430-F2013.
Installing from repositories is easy, but you don’t get the newest features and often newer hardware isn’t supported. [Sergio] reports that the newest version, called Uniarch, pulls source code and header files from the middle of this month and supports over 300 devices. In fact, it specifically outlines the goal of making new hardware easier to incorporate than with previous versions. He’s tailored this guide specifically for Ubuntu but while we were wading through a Google search we also found a page that outlines compilation for OSX.
We didn’t really notice before, but GitHub sure does make those README.md files look nice when viewed on the web, doesn’t it?
If you’ve ever tried compile a linux kernel yourself you know the headache of configuring and taking care of dependencies. KernelCheck makes this a point and click process for debian based linux distributions such as Ubuntu. You can use it to compile and install any 2.6.* stable kernel as well as the bleeding edge. KernelCheck even offers custom compilation options such as including kernel patches or rolling in proprietary video drivers. A tutorial (PDF) is also provided so you can see what you’re getting yourself into.
[via Web Upd8]