Go has a pretty neat development environment, and its helpful to set up a standard GOPATH on your workstation up front. This is what I do:
Now, after you log in, you can do things like:
In the quest for technologies that work well for embedded Linux systems, I recently gave Go another try. The last time I tried this was very early on and there were some floating point issues on ARM that appear to be fixed now. Having spent a few days porting an existing application to Go, there is a lot to like about Go.
With the explosion of IOT (Internet of things), there are now more technologies we can use to build systems. In reality, we’ve been doing IOT for years. We’ve been networking devices for a long time. We’ve been collecting data from remote nodes. This is nothing new, but what the IOT movement brings to the table is technologies that are much lower cost, and more standardized. Two of these technologies are MQTT and CoAP. Both very interesting, and very useful. Recently, I helped a system manufacturer think through the architecture of a system with the following requirements:
Recently, I sent a survey to the OpenEmbedded and Yocto mail lists asking a series of questions about how they use OE. 38 people responded. The average number of years using OE is 4.8 years.
One of the common things we do during Linux kernel development is move a series of patches from one kernel version to a similar version (say Linux 4.1 to 4.1.12). This is required as new stable versions of particular kernel version are released. One approach is to merge, but then your changes are mixed in with upstream commits and are more difficult to manage. Git rebase offers a convenient way to move a set of patches. In the following example we have a series of changes we made (or patches we applied) on top of the 4.1 kernel.
Recently, I needed to enable the eject command in BusyBox for an OpenEmbedded (Yocto) based project. Below is a way to do this in a fairly painless way:
I’ve already written about using autotools and qmake in OE. With recent projects, we’re using CMake to build most C/C++ components. Like any good tool, CMake has a learning curve, but it seems to do its job quite well. Below are examples of a CMake build file, and corresponding OE recipe.
Read More »Best practices for using CMake in OpenEmbedded/Yocto
As I work at the intersection of hardware and software, I spend a fair amount of time reading schematics for printed circuit boards (PCBs). I’m astounded at how sloppy most schematics are, and have come up with a few suggestions to consider.
Is the size of the libraries required for C++ (vs C) a concern in Embedded Linux systems? Most Embedded Linux systems likely include some C++ code, so this is probably not even a decision we need to make in many cases. However, often there is a need for a small initramfs that is used as part of the boot process (perhaps for software updates) before switching to the main root file system. In this case, it makes sense to keep the initramfs as small as possible, and we might be concerned here with the size of C++ libraries.
Read More »Library sizes for C vs C++ in an embedded Linux system
Recently I was asked why use systemd vs sysvinit in embedded systems? There are many discussions on this, and really most of the reasons people use it for servers and desktops are also valid for embedded systems. Lennart Poettering’s articles explain very well why you might want to consider systemd. A few things that rank high on my list: