What is BeagleConnect Technology
Hello everyone. I have been a bit busy these past few months working to improve BeagleConnect™ Technology. While this work initially started as a Google Summer of Code 2023 project, I am now working part-time on this. While not everything is completed, I felt this was a good point to go through an overview of it before I start creating demos (which are actually reproducable without having to approach me). So here it goes.
BeagleConnect™ is a revolutionary technology virtually eliminating low-level software development for IoT and IIoT applications, such as building automation, factory automation, home automation, and scientific data acquisition.
While numerous IoT and IIoT solutions available today provide massive software libraries for microcontrollers supporting a limited body of sensors, actuators and indicators as well as libraries for communicating over various networks, BeagleConnect simply eliminates the need for these libraries by shifting the burden into the most massive and collaborative software project of all time, the Linux kernel.
BeagleConnect™ technology solves:
- The need to write software to add a large set of diverse devices to your system,
- The need to maintain the software with security updates,
- The need to rapidly prototype using off-the-shelf software and hardware without wiring,
- The need to connect to devices using long-range, low-power wireless, and
- The need to produce high-volume custom hardware cost-optimized for your requirements.
Now to get into more nitty-gritty details, we will first need some information about Greybus, which powers BeagleConnect™ Technolgy.
I will be taking information from the Greybus LWN article. So feel free to check it out.
Greybus was initially designed for Google’s Project Ara smartphone (which is discontinued now), but the first (and only) product released with it is Motorola’s Moto Mods. It was initially merged for potential use by kernel components that need to communicate in a platform-independent way.
The Greybus specification provides device discovery and description at runtime, network routing and housekeeping, and class and bridged PHY protocols, which devices use to talk to each other and to the processors. The following figure shows how various parts of the kernel interact with the Greybus subsystem.
There are three main entities in the Greybus network:
- AP: It refers to the host CPUs, i.e., CPUs running Linux in most cases. It is responsible for administrating the Greybus network via the SVC.
- SVC: The SVC represents an entity within the Greybus network that configures and controls the Greybus (UniPro) network, mostly based on the instructions from the AP. All module insertion and removal events are first reported to the SVC, which in turn informs the AP about them using the SVC protocol.
- Module: A module is the physical hardware entity that can be connected or disconnected statically (before powering the system on) or dynamically (while the system is running) from the Greybus network. Once the modules are connected to the Greybus network, the AP and the SVC enumerate the modules and fetch per-interface manifests to learn about their capabilities.
While Greybus is a great protocol, the implementation is tightly coupled with the UniPro transport. This makes it challenging to use Greybus in other modes of transport.
BeagleConnect™ Technology aims to use Greybus outside of the traditional Greybus network. This includes using transports other than UniPro (such as 6lowpan), using embedded devices running ZephyrRTOS as modules, emulating SVC in co-processor, etc. This makes BeagleConnect™ much more flexible than what traditional greybus seems to support. Here is a diagram of the general BeagleConnect™ setup:
The SVC is either emulated in userspace software in the SOC (gbridge) or in a co-processor (e.g., in BeaglePlay). The arbitrary transport can be anything from 6lowpan (for long range) to ethernet or optical cables (for max speed). Finally, greybus nodes such as BeagleConnect Freedom running Greybus Zephyr firmware allow the use of mikroBUS which opens a host of Plug and Play possibilities for peripherals.
Open-source: The Greybus Spec is open-source and a part of the Linux kernel. This makes it easy to use and personalize for your use case. Being part of the Linux Kernel also provides it a level of reliability that most similar solutions lack.
Network agnostic: BeagleConnect™ allows Greybus to be network agnostic. This means it can be used over networks like 6lowpan, which has incredible wireless range, or over optical networks for high-throughput, low-latency use cases.
Rapid Prototyping: Any device (e.g., clickboard) connected to the greybus node can be accessed from the Linux host. In this setup, only the Linux host needs to have device drivers. The greybus node (running ZephyrRTOS, nuttx, etc) does not need the device drivers. This allows being able to prototype devices by just creating a Linux driver instead of having to write drivers for each individual embedded OS.
Star topology IoT and IIoT networks: In most star topology IoT networks, the only job of peripheral nodes is to collect data from connected devices, convert it to a common format (such as JSON), and then send it to the central node for further processing. Using BeagleConnect™ Technology allows us to use a low-powered device for nodes (since the data does not need to be processed much). Additionally, nodes can be swapped much more easily since anything can be a Greybus node as long as it implements the protocol.
I have been working these past few months to move everything to the new architecture with gb-beagleplay driver (part of mainline 6.7). Most of the Zephyr patches that were needed are already upstreamed or have open PRs. So things should be more or less for tinkerers soon. I will also post updates on this blog, so feel free to follow the atom feed. You can also check out my GSoC23 Summary Post which provides an overview of my GSoC work along with some demos.
Consider supporting me if you like my work.