As a learning tool, PiBox opened my eyes to a wide variety of problems. The first was the problem of switching hardware platforms easily. Crosstool-NG makes this easy, but wrapping this inside the PiBox build system made it easy to experiment quickly with different configurations. This allowed me to switch originally from the BeagleBone to the Raspberry Pi and recently aided in a quick migration to supporting the Raspberry Pi 2, which has a slightly different processor configuration. Early versions of PiBox toolchains also have been used for PowerPC and Intel targets.
During early development, I had to deal with device handling during boot. To
reduce overhead and speed boot times, many embedded systems use mdev instead of udev for device handling. Decoding mdev events took some work and led to
Figure 6. The console UI is consumer-oriented, with few keystrokes required for navigation.
DEEP DIVE
Figure 7.
The WebUI supports user authentication and provides access to the webcam.
153 | March 2019 | https://www.linuxjournal.com
DEEP DIVE
custom scripting to deal with USB device hot plug events, which were critical to the Media systems.
A related issue invovled removing early boot messages while speeding boot times.
Boot times are still on the order of a minute or more (mostly due to network setup), but boot messages now are handled by the use of pslplash to show boot
Figure 8. The webcam image can be flipped so the camera can be mounted from above or below a window.
DEEP DIVE
processing. I also had to start X.org very early without starting any clients. This is due to timing issues that prevent keyboards from operating properly. X is later stopped and restarted. This circumvents the non-functional keyboard issues without the user noticing the workaround.
PiBox offers both a console UI-based on GTK+/Cairo and a JavaScript-based interface based on the Monkey web server and a PHP back end. I originally looked at building an HTML5 interface (and would still like to in the long run), but WebKit wouldn’t compile properly, and I didn’t want to waste too much time trying to address that issue. So I fell back to what I already knew how to do: build a GTK+-based UI.
Cairo presented an estoric problem that proved difficult to isolate. Cairo is used by GTK+ to paint icons in the navigation page. This code originally was tested on my Intel-based desktop and worked fine. On the target board, the icons failed to be displayed. After much trial and error, I discovered that Cairo was unhappy within non-square images on the ARM board. Making them square fixed the problem. This adds an odd requirement for app developers when creating the navigation icons for their apps.
The web UI required me to learn more about JavaScript, a language I enjoy more now that I understand it a better. Its interaction with back-end PHP is clean and easy to understand, but creating UIs can require carrying client libraries around from application to application, much like Java. It does offer the option of setting up direct connections from the client browser to non-web-based back ends, and that’s something I find very encouraging.
What I found less encouraging was the use of web-based media through proxies.
The only format that moves natively through http/https is motion jpeg (mjpeg), and on the Pi, this works only at a relatively low frame rate. Note that this is a USB webcam, not the onboard camera. I chose to use a webcam due to the relatively short ribbon cables provided for the onboard camera. The use case for the
webcam is as a backup camera for our trailer. The idea is to allow the camera to be physically distant from the Pi.
155 | March 2019 | https://www.linuxjournal.com
DEEP DIVE
Figure 9. pibox-network-config is available in the development platform (above) but takes on a different appearance in the Media systems (below).
DEEP DIVE
PiBox Media systems are designed to reduce user-managed wires. This includes networking, where WiFi rules. Unfortunately, not all WiFi dongles are created equal with all versions of the Linux kernel. After many months of trial and error, I managed to find that the Ralink RT5370 chip provided the most stable experience.
However, support was left in place for the variety of chips I tested. Handling USB WiFi dongles is done manually, outside of mdev, with the help of USB device IDs and a custom init script.
While researching WiFi dongles, I also improved the network configuration utility I wrote from scratch. This GTK+ application provides support for configuring WiFi or wired static and DHCP connections and also allows configuring the Media Server as a wireless access point for the closed network in our travel trailer. This utility is available in the Development Platform, but with GTK+ themes, inherits the look of the custom UI for the Media systems. The utility comes with a WiFi scanner and also provides the
libpiboxnet library. The library is used by piboxd, a dæmon that handles many functions including inbound requests from the web UI.
Summary
There are many other issues I covered over the years of PiBox development, including learning enough Blender to generate a 3D design for a sample enclosure—an experiment still in need of much refinement. But the design of the build system for the Development Platform has proven flexible enough for a variety of platforms. Cross-compilation turns out to be much simpler than I expected once you get a method identified. I use a common cross.sh script in many of the packages I build to simplify this process. I also found that the use of cdtools made it possible to create an all-encompassing metabuild that automates the download and build process for all packages at release time.
Future development plans include integration with remote sensors. I hope to create my own Iron Man home, with voice commands handled by my Jarvis project. Jarvis is a proof-of-concept voice-to-text-to-action-to-speech Java project. But the hope is to have it integrate with a back-end sensor management system, connected through a PiBox Media Server, to handle control of devices around the home.
157 | March 2019 | https://www.linuxjournal.com
DEEP DIVE
This entire project has been a one-man job, and I’m very much interested in others joining in, even if all they do is fork the project. I’d like to hear how I can improve the build systems, the Media systems and their UIs and apps. I’ve created as much documentation as I can on the wiki, and interested developers can follow progress on my Redmine issue tracker. All code is released as open source and is available from GitLab.com. ◾
Michael J. Hammel is a Software Engineer for NetApp living with his wife Brinda and two Golden Retrievers in Broomfield, Colorado.
When he isn’t working on embedded systems or other geekery, he likes to camp, walk his dogs around the park, and drink tea with his wife and revel in the joy of his daughter’s success. He has written more than 100 articles for numerous online and print magazines, and he’s the author of four books on GIMP, the GNU Image Manipulation Program.
Resources
• The Graphics Muse Development Wiki
• PiBox
• Cdtools
• PiBox on GitLab
• xjarvis
• Michael J. Hammel on GitLab
• “Building a Voice-Controlled Front End to IoT Devices”
by Michael J. Hammel, LJ June 2018
Send comments or feedback
via http://www.linuxjournal.com/contact or email [email protected].
TEXT PROCESSING IN RUST