Google’s Pigweed For ARM Development Is A Nice Surprise

Setting up an environment for Embedded Development was traditionally a pain and so vendors provide integrated development environments to help bridge the gap. Google has open-sourced their version of an embedded targeted environment designated as embedded-targeted libraries which they trademarked Pigweed.

Google trademarked Pigweed with the U.S. Patent and Trademark Office in February and it popped up on the Google Open Source Blog along with some details.

The repository contains what Google is calling modules but taking a better look reveals that it a little more than that. Packaged in a Python Virtual Environment is a number of tools including an ARM compiler, the clang-format tool and Python 3.8 interpreter which runs more than a few things. The modules that come with Pigweed assist developers by running micro-automations such as the pw_watch module that monitors files for change and triggers a build, test and even flash and debug on hardware. There is also a module that allows pre-submit checks such as linting and formatting.

Google still does not consider this offering production ready though from what we have seen so far, it is a great place for many to start experimenting with for their embedded development automation needs. Anyone tried it out yet?

If you have been inspired with the amazing powers of automation and want to dive in yourself, have a look at Software Development in BASH and Continuous Integration with Python.


File Systems For Tiny Devices

Sometimes you build a computer and use it every day. Sometimes you build a different type of computer and it sits alone on a mountaintop for years. The design considerations for these two setups are remarkably different, right down to the type of file system used. For small computers like [Jo] is using, and for the amount of time they sit alone in remote locations, he decided to build his own file system for them.

Known as JesFs ([Jo]’s embedded serial File system), the file system is for SPI Flash and intended for use in scientific data logging. It can be used on the chip-scale processors found in many development boards, and is robust enough to use in applications where remoteness is a concern. It has a small RAM footprint, is completely open source, includes wear leveling, and has a number of security features built-in as well.

Some of the benefits of using a file system on such a tiny chip aren’t immediately obvious unless you’re doing a lot of data logging, but it does allow you to change virtually any aspect of the firmware much more easily if everything is accessible as a file, and not something you would have to change by reflashing the whole chip, for example. There are also a number of traps that you can easily fall into when working with file systems for tiny devices.

Review: OSEPP STEM Kit 1, A Beginner’s All-in-One Board Found In The Discount Aisle

As the name implies, the OSEP STEM board is an embedded project board primarily aimed at education. You use jumper wires to connect components and a visual block coding language to make it go.

I have fond memories of kits from companies like Radio Shack that had dozens of parts on a board, with spring terminals to connect them with jumper wires. Advertised with clickbait titles like “200 in 1”, you’d get a book showing how to wire the parts to make a radio, or an alarm, or a light blinker, or whatever.

The STEM Kit 1 is sort of a modern arduino-powered version of these kits. The board hosts a stand-alone Arduino UNO clone (included with the kit) and also has a host of things you might want to hook to it. Things like the speakers and stepper motors have drivers on board so you can easily drive them from the arduino. You get a bunch of jumper wires to make the connections, too. Most things that need to be connected to something permanently (like ground) are prewired on the PCB. The other connections use a single pin. You can see this arrangement with the three rotary pots which have a single pin next to the label (“POT1”, etc.).

I’m a sucker for a sale, so when I saw a local store had OSEPP’s STEM board for about $30, I had to pick one up. The suggested price for these boards is $150, but most of the time I see them listed for about $100. At the deeply discounted price I couldn’t resist checking it out.

So does an embedded many-in-one project kit like this one live up to that legacy? I spent some time with the board. Bottom line, if you can find a deal on the price I think it’s worth it. At full price, perhaps not. Join me after the break as I walk through what the OSEPP has to offer.

Continue reading “Review: OSEPP STEM Kit 1, A Beginner’s All-in-One Board Found In The Discount Aisle”

Micropython And C Play Together Better

Python is a versatile, powerful language but sometimes it’s not the best choice, especially if you’re doing work in embedded systems with limited memory. Sometimes you can get away with MicroPython for these cases, but the best language is likely C or assembly. If you’re really stubborn, like [amirgon], and really want C and Python to play well together, you can make use of his new tool which can bring any C library to MicroPython.

As an example of how this tool is used, a “Pure MicroPython” display driver for ILI9341 on the ESP32, which means that everything was implemented in MicroPython. [amirgon] wanted to see how the Python driver would compare to one that’s already been written in C, and use it to showcase MicroPython binding. This tool also automatically converts structs, unions, enums and arrays to Python objects, and provides a means to work with pointers which is something that Python doesn’t handle in the same way that C requires.

[amirgon] hopes that this tool will encourage the adoption of Micropython by removing the obstacle of missing APIs and libraries in MicroPython. Since most libraries for systems like these are written in C, a way to implement them in Python is certainly powerful. We featured one use case for this a while back, but this is a much more generic fix for this coding obstacle.

Image via [Frank Stajano]


Debug Superpowers Bring An STM32 Back From The Dead

When a processor has a fault it can leave what looks to be precious little in the way of cause and effect. Debug-by-print-statement works surprisingly well in simple cases, but where in a desktop environment you would drop into a debugger to solve trickier problems this can be an onerous task on an embedded system. [Ross Schlaikjer]’s excellent blog post walks through setting up one of our favorite Open Hardware debug probes and shows us that with the right tooling in place, unexpected faults aren’t quite so impenetrable. Continue reading “Debug Superpowers Bring An STM32 Back From The Dead”

Qt Arrives For Small Computers

There was a time when writing embedded systems meant never having to deal with graphical user interfaces, and spending long hours trying to free up a dozen bytes of ROM to add a feature. Nowadays, an embedded system is likely to have a screen and what would have been a huge amount of memory even for a PC a scant decade ago. Qt has long been a popular choice for building software on desktop platforms, and — while not as popular — has even run on phones for a while. Now there’s Qt for MCUs which is clearly targeting the IoT market that everyone is trying to capture. You can see the glitzy video for the new product, below.

We generally like Qt, and the move recently has been towards an HTML-like markup language called QML instead of directly manipulating widgets. We guess that’s a good thing. However, Qt isn’t just for user interfaces. It provides a wide range of services in a straightforward way

Continue reading “Qt Arrives For Small Computers”

The Joy Of Properly Designed Embedded Systems

The ages-old dream of home automation has never been nearer to reality. Creating an Internet of Things device or even a building-wide collection of networked embedded devices is “easy” thanks to cheap building blocks like the ESP8266 WiFi-enabled microcontroller. Yet for any sizable project, it really helps to have a plan before getting started. But even more importantly, if your plan is subject to change as you work along, it is important to plan for flexibility. Practically, this is going to mean expansion headers and over-the-air (OTA) firmware upgrades are a must.

I’d like to illustrate this using a project I got involved in a few years ago, called BMaC, which grew in complexity and scope practically every month. This had us scrambling to keep up with the changes, while teaching us valuable lessons about how to save time and money by having an adaptable system architecture.

Continue reading “The Joy Of Properly Designed Embedded Systems”