The Raspberry Pi compute module is a powerful piece of hardware, especially for the price. With it, you get more IO than a normal Pi, plus the ability to design hardware around it that’s specifically tailored to your needs rather than simply to general-purpose consumers. However, this comes at the cost of needing a way to interface with it since the compute module doesn’t have the normal IO pins or ports, but [Timon] has come up with a handy development board for this module called the Piunora which solves a lot of these prototyping issues.
The development board expands the compute module to the familiar Arduino-like form factor, complete with IO headers, USB ports, and HDMI output. It doesn’t stop there, though. It has an M.2 connector, some built-in LEDs, a camera connector, and a few other features. It also opens up some other possibilities that would be difficult or impossible with a standard Pi 4, such as the ability to run the Pi as a USB gadget rather than as a host device which simplifies certain types of development, which is [Timon]’s intended function.
As a development board, this project has a lot of potential for the niche uses of the compute module when compared to the standard Raspberry Pi. For embedded applications it’s much easier to deploy, with the increased development costs as a tradeoff. If you’re still unsure what to do with the compute module 4, we have some reading for you. And Timon’s previous project is a great springboard.
Cameras are getting smarter and more capable than ever, able to run embedded machine vision algorithms and pull off tricks far beyond what something like a serial camera and microcontroller board would be capable of, and the upcoming Vizy aims to be even smarter and easier to use yet. Vizy is the work of Charmed Labs, and this isn’t their first foray into accessible machine vision. Charmed Labs are the same folks behind the Pixy and Pixy 2 cameras. Vizy’s main goal is to make object detection and classification easy, with thoughtful hardware features and a browser-based interface.
The usual way to do machine vision is to get a USB camera and run something like OpenCV on a desktop machine to handle the processing. But Vizy leverages a Raspberry Pi 4 to provide a tightly-integrated unit in a small package with a variety of ready-to-run applications. For example, the “Birdfeeder” application comes ready to take snapshots of and identify common species of bird, while also identifying party-crashers like squirrels.
The demonstration video on their page shows off using the built-in high-current I/O header to control a sprinkler, repelling non-bird intruders with a splash of water while uploading pictures and video clips. The hardware design also looks well thought out; not only is there a safe shutdown and low-power mode for the Raspberry Pi-based hardware, but the lens can be swapped and the camera unit itself even contains an electrically-switched IR filter.
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.
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?
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.
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.
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.
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”→