Exploring Getting Started in Electronics satisfied my itch for quite a while. Eventually, I got a Commodore 64 and began connecting voice synthesizer ICs to it. My interest in computers and electronics flourished into an electrical engineering degree and a long career in the semiconductor industry.

Over this time, I’ve become more and more alarmed with the progress of technology. Now, to be clear, I love technology. I love innovation and invention. It is just that some things have evolved in a sort of tunnel-vision, without bringing everyone along.

As graphical user interfaces and mice took over computers, they rapidly became almost unusable by my mom. She typed well, but the dexterity to move a mouse aluded her. To satisfy the need to interact with locations on the screen, she adopted using a joystick and her productivity came to a crawl. How is it that such assumptions could be made impacting all computer users without any thoughtful provisions for what already worked?

Get on my calendar if you’d like to chat with me more about this story.

BeagleConnect™ uses the collaboratively developed Linux kernel to contain the intelligence required to speak to these devices (sensors, actuators, and indicators), rather than relying on writing code on a microcontroller specific to these devices. Some existing solutions rely on large libraries of microcontroller code, but the integration of communications, maintenance of the library with a limited set of developer resources and other constraints to be explained later make those other solutions less suitable for rapid prototyping than BeagleConnect™.

Linux presents these devices abstractly in ways that are self-descriptive. Add an accelerometer to the system and you are automatically fed a stream of force values in standard units. Add a temperature sensor and you get it back in standard units again. Same for sensing magnetism, proximity, color, light, frequency, orientation, or multitudes of other inputs. Indicators, such as LEDs and displays, are similarly abstracted with a few other kernel subsystems and more advanced actuators with and without feedback control are in the process of being developed and standardized. In places where proper Linux kernel drivers exist, no new specialized code needs to be created for the devices.

Because there isn’t code specific to any given network-of-devices configuration, we can all leverage the same software code base. This means that when someone fixes an issue in either BeagleConnect™ firmware or the Linux kernel, you benefit from the fixes. The source for BeagleConnect™ firmware is also submitted to the Zephyr Project upstream, further increasing the user base. Additionally, we will maintain stable branches of the software and provide mechanisms for updating firmware on BeagleConnect™ hardware. With a single, relatively small firmware load, the potential for bugs is kept low. With large user base, the potential for discovering and resolving bugs is high.

BeagleConnect™ utilizes the mikroBUS standard. The mikroBUS standard interface is flexible enough for almost any typical sensor or indicator with hundreds of devices available.

BeagleConnect™ Freedom wireless hardware is built around a TI CC1352 multiprotocol and multi-band Sub-1 GHz and 2.4-GHz wireless microcontroller (MCU). CC1352R includes a 48-MHz Arm® Cortex®-M4F processor, 352KB Flash, 256KB ROM, 8KB Cache SRAM, 80KB of ultra-low leakage SRAM, and Over-the-Air upgrades (OTA).

BeagleConnect™ utilizes open source hardware and open source software, making it possible to optimize hardware and software implementations and sourcing to meet end-product requirements. BeagleConnect™ is meant to enable rapid-prototyping and not to necessarily satisfy any particular end-product’s requirements, but with full considerations for go-to-market needs.

Each BeagleBoard.org BeagleConnect™ solution will be:

• Readily available for over 10 years,

• Built with fully open source software with submissions to mainline Linux and Zephyr repositories to aide in support and porting,

• Built with fully open source and non-restrictive hardware design including schematic, bill-of-materials, layout, and manufacturing files (with only the BeagleBoard.org logo removed due to licensing restrictions of our brand),

• Built with parts where at least a compatible part is available from worldwide distributors in any quantity,

• Built with design and manufacturing partners able to help scale derivative designs,

• Based on a security model using public/private keypairs that can be replaced to secure your own network, and

• Fully FCC/CE certified.

Log into a host system running Linux that is BeagleConnect™ enabled. Enable a Linux host with BeagleConnect™ by plugging a BeagleConnect™ gateway device into it’s USB port. You’ll also want to have a BeagleConnect™ node device with a sensor, actuator or indicator device connected.

TODO: Clean up images

Initiate a connection between the host and devices by pressing the discovery button(s).

New streams of self-describing data show up on the host system using native device drivers.

High-level applications, like Node-RED, can directly read/write these high-level data streams (including data-type information) to Internet-based MQTT brokers, live dashboards, or other logical operations without requiring any sensor-specific coding. Business logic can be applied using simple if-this-then-that style operations or be made as complex as desired using virtually any programming language or environment.

TODO: Actually, Node-RED will make these show up automatically as streams.

• BeagleConnect™ Freedom beta kit

  • Seeed Studio BeagleBone® Green Gateway

  • 3x BeagleConnect™ Freedom board, antenna, U.FL to SMA cable, SMA antenna and USB Type-A to Type-C cable

  • 1x MikroE ID Click

• microSD card (6GB or larger)

• microSD card programmer

• 12V power brick

• USB to TTL 3.3V UART adapter

• Ethernet cable and Internet connection

• 2x USB power adapters

• BME280-based Weather Click

• iAQ-Core-based Air Quality 2 Click

• x86_64 computer running Ubuntu 20.04.3 LTS

• For Linux nerds: Think of BeagleConnect™ as 6LoWPAN over 802.15.4-based Greybus (instead of Unipro as used by Project Ara), where every BeagleConnect™ board shows up as new SPI, I2C, UART, PWM, ADC, and GPIO controllers that can now be probed to load drivers for the sensors or whatever is connected to them. (Proof of concept of Greybus over TCP/IP: https://www.youtube.com/watch?v=7H50pv-4YXw)

• For MCU folks: Think of BeagleConnect™ as a Firmata-style firmware load that exposes the interfaces for remote access over a secured wireless network. However, instead of using host software that knows how to speak the Firmata protocol, the Linux kernel speaks the slightly similar Greybus protocol to the MCU and exposes the device generically to users using a Linux kernel driver. Further, the Greybus protocol is spoken over 6LoWPAN on 802.15.4.

• Linux kernel driver

• Provisioning

• Firmware for host CC13x

• Firmware for device CC13x

• Click Board drivers and device tree formatted metadata for 100 or so Click Boards

• Click Board plug-ins for node-red for the same 100 or so Click Boards

• BeagleConnect™ Freedom System Reference Manual and FAQs

• Click Board support for Node-RED can be executed with native connections on PocketBeagle+TechLab and BeagleBone Black with mikroBUS Cape

• Device tree fragments and driver updates can be provided via https://bbb.io/click

• The Kconfig style provisioning can be implemented for those solutions, which will require a reboot. We need to centralize edits to /boot/uEnv.txt to be programmatic. As I think through this, I don’t think BeagleConnect is impacted, because the Greybus-style discovery along with Click EEPROMS will eliminate any need to edit /boot/uEnv.txt.

• Make sure no reboots are required

• Plugging BeagleConnect into host should trigger host configuration

• Click EEPROMs should trigger loading whatever drivers are needed and provisioning should load any new drivers

• Userspace (spidev, etc.) drivers should unload cleanly when 2nd phase provisioning is completed

Good question. Blinking an LED is kind of the Hello, World of the hardware community. In this case, we’re less interested in the mechanics of switching a GPIO to drive some current through an LED and more interested in how that happens with the Internet of Things (IoT).

There are several existing network and application layers that are driven by corporate heavyweights and industry consortiums, but relatively few that are community driven and, more specifically, even fewer that have the ability to integrate so tightly with the Linux kernel.

The goal here is to provide a community-maintained, developer-friendly, and open-source protocol for the Internet of Things using the Greybus Protocol, and blinking an LED using Greybus is the simplest proof-of-concept for that. All that is required is a reliable transport.

There are a few technologies at the core of this demonstration, and far too much background information to describe adequately here, so they are simply listed below for brevity:

• Project Ara

• IPv6 (via 6LoWPAN)

• Zephyr support for IEEE 802.15.4

• Greybus originally from Project Ara

• Using Greybus for IoT

In short, Greybus is an application layer protocol that can be described as a ``bus transport'' in that it conveys bus-specific messages back and forth between Linux and a connected device. The physical bus is attached to the connected device, which could be running Linux or a variety of Real-Time Operating Systems. Meanwhile, on the Linux side, a virtual bus is created corresponding to the physical bus on the connected device. To the user, this virtual bus (be it /dev/gpiochip0, /dev/i2c5, etc) appears and functions exactly the same. Greybus is the protocol used to exchange bus-specific messages and data between Linux and the connected device.

The major advantage there is that drivers can be well maintained in Linux rather than buried in microcontroller firmware.

Greybus currently supports several busses, including:

• USB

• I2C

• GPIO

• PWM

• SPI

• UART

• SDIO

• Camera (V4L)

• LED (with various programmability)

• AUDIO (I2S)

#TODO: The agenda for the above falls a bit short of BeagleConnect

See the [Equipment] section for hardware requirements.

Download and install the Debian Linux operating system image for the Seeed BeagleBone® Green Gateway host.

1. Download the special mikroBUS/Greybus BeagleBoard.org Debian image from here. Pick the most recent directory and select the file beginning with bone- and ending with .img.xz. Today that file is bone-debian-11.2-iot-mikrobus-armhf-2022-03-04-4gb.img.xz.

2. Load this image to a microSD card using a tool like Etcher.

3. Insert the microSD card into the Green Gateway.

4. Power the Green Gateway via the 12V barrel jack.

5. Log onto the Seeed BeagleBone® Green Gateway using ssh or, with a serial to USB cable such as those made by FTDI[https://www.digikey.com/short/cfjmdbdd] plugged into J10 with the black wire of the FTDI cable toard the Ethernet connector. To use ssh, you will have to know the Green Gateway’s IP address that can be found from your router.

6. (If using WiFi) Use the connmanctl tool to gain an Internet connection.

Comamnd-line instructions below are to be issued into the BeagleBone® Green Gateway terminal, either via ssh or the serial console.

On the newly imaged BeagleBone® Green Gateway board:

1. Connect (or reconnect) a BeagleConnect™ Freedom board over USB

2. cc2538-bsl.py /usr/share/beagleconnect/cc1352/wpanusb_beagleconnect.bin /dev/ttyACM0 ^[2]

3. After it finishes programming successfully, reconnect the BeagleConnect Freedom board over USB

4. Test that the driver loaded and is talking to the newly added gateway radio

   debian@beaglebone:~$ iwpan wpan0 info
   Interface wpan0
           ifindex 10
           wpan_dev 0x200000001
           extended_addr 0x5a4f745eb7beac7f
           short_addr 0xffff
           pan_id 0xffff
           type node
           max_frame_retries 3
           min_be 3
           max_be 5
           max_csma_backoffs 4
           lbt 0
           ackreq_default 0

By default, the beta boards ship with a debug sensor broadcast per sensortest-main.c. You can use this to further test your gateway.

1. Power a BeagleConnect Freedom that has not yet been programmed via a USB power source, not the BeagleBone Green Gateway. You’ll hear a click every 1-2 seconds along with seeing 4 of the LEDs turn off and on.

2. In an isolated terminal window, sudo beagleconnect-start-gateway

3. sensortest-rx.py

Every 1-2 minutes, you should see something like:

The value after "2l:" is the amount of light in lux. The value after "4h:" is the relative humidity and after "4t:" is the temperature in Celcius.

#TODO: How can we add a step in here to show the network is connected without needing gbridge to be fully functional?

Do this from the BeagleBone® Green Gateway board that was previously used to program the BeagleConnect™ Freedom gateway device:

1. Disconnect the BeagleConnect™ Freedom gateway device

2. Connect a new BeagleConnect™ Freedom board via USB

3. sudo systemctl stop lowpan.service

4. cc2538-bsl.py /usr/share/beagleconnect/cc1352/greybus_mikrobus_beagleconnect.bin /dev/ttyACM0 ^[3]

5. After it finishes programming successfully, disconnect the BeagleConnect Freedom node device

6. Power the newly programmed BeagleConnect Freedom node device from an alternate USB power source

7. Reconnect the BeagleConnect Freedom gateway device to the BeagleBone Green Gateway

8. sudo systemctl start lowpan.service

9. sudo beagleconnect-start-gateway

#TODO: update the below for the built-in sensors

#TODO: can we also handle the case where these sensors are included and recommend them? Same firmware?

#TODO: the current demo is for the built-in sensors, not the Click boards mentioned below

Currently only a limited number of add-on boards have been tested to work over Greybus, simple add-on boards without interrupt requirement are the ones that work currently. The example is for Air Quality 2 Click and Weather Click attached to the mikroBUS ports on the device side.

/var/log/gbridge will have the gbridge log, and if the mikroBUS port has been instantiated successfully the kernel log will show the devices probe messages:

#TODO: this log needs to be updated

#TODO: bring in the GPIO toggle and I2C explorations for greater understanding

If flashing the Freedom board via the BeagleBone fails here’s a trick you can try to flash from a Linux host.

Use sshfs to mount the Bone’s files on the Linux host. This assumes the Bone is plugged in the the USB and appears at 192.168.7.2:

The Bone’s files now appear as local files. Notice there is already a /dev/ACM appearing. Now plug the Connect into the Linux host’s USB port and run the command again.

The /dev/ttyASM that just appeared is the one associated with the Connect. In my case it’s /dev/ttyACM0. That’s what I’ll use in this example.

Now change directories to where the binaries are and load:

Now you are ready to continue the instructions above after the cc2528 command.

Trying for different add-on boards

In order to see diagnostic messages or to run certain commands on the Zephyr device we will require a terminal open to the device console. In this case, we use tio due how its usage simplifies the instructions.

Install tio

sudo apt install -y tio

Run tio

tio /dev/ttyACM0

After flashing, you should observe the something matching the following output in tio.

The line beginning with *** is the Zephyr boot banner.

Lines beginning with a timestamp of the form [H:m:s.us] are Zephyr kernel messages.

Lines beginning with uart:~$ indicates that the Zephyr shell is prompting you to enter a command.

From the informational messages shown, we observe the following.

• Zephyr is configured with the following link-local IPv6 address fe80::3177:a11c:4b:1200

• It is listening for (both) TCP and UDP traffic on port 4242

However, what the log messages do not show (which will come into play later), are 2 critical pieces of information:

1. The RF Channel: As you may have guessed, IEEE 802.15.4 devices are only able to communicate with each other if they are using the same frequency to transmit and recieve data. This information is part of the Physical Layer.

2. The PAN identifier: IEEE 802.15.4 devices are only be able to communicate with one another if they use the same PAN ID. This permits multiple networks (PANs) on the same frequency. This information is part of the Data Link Layer.

If we type help in the shell and hit Enter, we’re prompted with the following:

So after hitting Tab, we see that there are several interesting commands we can use for additional information.

Zephyr Shell: IEEE 802.15.4 commands

uart:~$ ieee802154 help
ieee802154 - IEEE 802.15.4 commands
Subcommands:
  ack             :<set/1 | unset/0> Set auto-ack flag
  associate       :<pan_id> <PAN coordinator short or long address (EUI-64)>
  disassociate    :Disassociate from network
  get_chan        :Get currently used channel
  get_ext_addr    :Get currently used extended address
  get_pan_id      :Get currently used PAN id
  get_short_addr  :Get currently used short address
  get_tx_power    :Get currently used TX power
  scan            :<passive|active> <channels set n[:m:...]:x|all> <per-channel
                   duration in ms>
  set_chan        :<channel> Set used channel
  set_ext_addr    :<long/extended address (EUI-64)> Set extended address
  set_pan_id      :<pan_id> Set used PAN id
  set_short_addr  :<short address> Set short address
  set_tx_power    :<-18/-7/-4/-2/0/1/2/3/5> Set TX power

uart:~$ ieee802154 get_chan
Channel 26

uart:~$ ieee802154 get_pan_id
PAN ID 43981 (0xabcd)

Zephyr Shell: Network Commands

uart:~$ net iface

Interface 0x20002b20 (IEEE 802.15.4) [1]
========================================
Link addr : CD:99:A1:1C:00:4B:12:00
MTU       : 125
IPv6 unicast addresses (max 3):
        fe80::cf99:a11c:4b:1200 autoconf preferred infinite
        2001:db8::1 manual preferred infinite
IPv6 multicast addresses (max 4):
        ff02::1
        ff02::1:ff4b:1200
        ff02::1:ff00:1
IPv6 prefixes (max 2):
        <none>
IPv6 hop limit           : 64
IPv6 base reachable time : 30000
IPv6 reachable time      : 16929
IPv6 retransmit timer    : 0

• Zephyr environment is set up according to the Getting Started Guide

  • Please use the Zephyr SDK when installing a toolchain above

• Zephyr SDK is installed at ~/zephyr-sdk-0.11.2 (any later version should be fine as well)

• Zephyr board is connected via USB

This repository utilizes git submodules to keep track of all of the projects required to reproduce the on-going work. The instructions here only cover checking out the demo branch which should stay in a tested state. On-going development will be on the master branch.

Clone specific tag

cd ~
git clone --recurse-submodules --branch demo https://github.com/jadonk/beagleconnect

Add the Fork

cd ~/beagleconnect/sw/zephyrproject/zephyr
west update

Build and Flash Zephyr

Clone, patch, and build the kernel

cd ~
git clone --branch v5.8.4 --single-branch git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
cd linux
git checkout -b v5.8.4-greybus
git am ~/beagleconnect/sw/linux/v2-0001-RFC-mikroBUS-driver-for-add-on-boards.patch
git am ~/beagleconnect/sw/linux/0001-mikroBUS-build-fixes.patch
cp /boot/config-`uname -r` .config
yes "" | make oldconfig
./scripts/kconfig/merge_config.sh .config ~/beagleconnect/sw/linux/mikrobus.config
./scripts/kconfig/merge_config.sh .config ~/beagleconnect/sw/linux/atusb.config
make -j`nproc --all`
sudo make modules_install
sudo make install

Probe the IEEE 802.15.4 Device Driver

$ dmesg | grep -i ATUSB
[    6.512154] usb 1-1: ATUSB: AT86RF231 version 2
[    6.512492] usb 1-1: Firmware: major: 0, minor: 3, hardware type: ATUSB (2)
[    6.525357] usbcore: registered new interface driver atusb
...

$ ip a show wpan0
36: wpan0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 123 qdisc fq_codel state UNKNOWN group default qlen 300
    link/ieee802.15.4 3e:7d:90:4d:8f:00:76:a2 brd ff:ff:ff:ff:ff:ff:ff:ff

Set the 802.15.4 Physical and Link-Layer Parameters

ip a show lowpan0
37: lowpan0@wpan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN group default qlen 1000
    link/6lowpan 9e:0b:a4:e8:00:d3:45:53 brd ff:ff:ff:ff:ff:ff:ff:ff
    inet6 fe80::9c0b:a4e8:d3:4553/64 scope link
       valid_lft forever preferred_lft forever

Broadcast Ping

$ ping6 -I lowpan0 ff02::1
PING ff02::1(ff02::1) from fe80::9c0b:a4e8:d3:4553%lowpan0 lowpan0: 56 data bytes
64 bytes from fe80::9c0b:a4e8:d3:4553%lowpan0: icmp_seq=1 ttl=64 time=0.099 ms
64 bytes from fe80::9c0b:a4e8:d3:4553%lowpan0: icmp_seq=2 ttl=64 time=0.125 ms
64 bytes from fe80::cf99:a11c:4b:1200%lowpan0: icmp_seq=2 ttl=64 time=17.3 ms (DUP!)
64 bytes from fe80::9c0b:a4e8:d3:4553%lowpan0: icmp_seq=3 ttl=64 time=0.126 ms
64 bytes from fe80::cf99:a11c:4b:1200%lowpan0: icmp_seq=3 ttl=64 time=9.60 ms (DUP!)
64 bytes from fe80::9c0b:a4e8:d3:4553%lowpan0: icmp_seq=4 ttl=64 time=0.131 ms
64 bytes from fe80::cf99:a11c:4b:1200%lowpan0: icmp_seq=4 ttl=64 time=14.9 ms (DUP!)

Ping Zephyr

$ ping6 -I lowpan0 fe80::cf99:a11c:4b:1200
PING fe80::cf99:a11c:4b:1200(fe80::cf99:a11c:4b:1200) from fe80::9c0b:a4e8:d3:4553%lowpan0 lowpan0: 56 data bytes
64 bytes from fe80::cf99:a11c:4b:1200%lowpan0: icmp_seq=1 ttl=64 time=16.0 ms
64 bytes from fe80::cf99:a11c:4b:1200%lowpan0: icmp_seq=2 ttl=64 time=13.8 ms
64 bytes from fe80::cf99:a11c:4b:1200%lowpan0: icmp_seq=3 ttl=64 time=9.77 ms
64 bytes from fe80::cf99:a11c:4b:1200%lowpan0: icmp_seq=5 ttl=64 time=11.5 ms

Ping Linux

uart:~$ net ping --help
ping - Ping a network host.
Subcommands:
  --help  :'net ping [-c count] [-i interval ms] <host>' Send ICMPv4 or ICMPv6
           Echo-Request to a network host.
$ net ping -c 5 fe80::9c0b:a4e8:d3:4553
PING fe80::9c0b:a4e8:d3:4553
8 bytes from fe80::9c0b:a4e8:d3:4553 to fe80::cf99:a11c:4b:1200: icmp_seq=0 ttl=64 rssi=110 time=11 ms
8 bytes from fe80::9c0b:a4e8:d3:4553 to fe80::cf99:a11c:4b:1200: icmp_seq=1 ttl=64 rssi=126 time=9 ms
8 bytes from fe80::9c0b:a4e8:d3:4553 to fe80::cf99:a11c:4b:1200: icmp_seq=2 ttl=64 rssi=128 time=13 ms
8 bytes from fe80::9c0b:a4e8:d3:4553 to fe80::cf99:a11c:4b:1200: icmp_seq=3 ttl=64 rssi=126 time=10 ms
8 bytes from fe80::9c0b:a4e8:d3:4553 to fe80::cf99:a11c:4b:1200: icmp_seq=4 ttl=64 rssi=126 time=7 ms

Assign a Static Address

sudo ip -6 addr add 2001:db8::2/64 dev lowpan0

$ ip a show lowpan0
37: lowpan0@wpan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN group default qlen 1000
    link/6lowpan 9e:0b:a4:e8:00:d3:45:53 brd ff:ff:ff:ff:ff:ff:ff:ff
    inet6 2001:db8::2/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::9c0b:a4e8:d3:4553/64 scope link
       valid_lft forever preferred_lft forever

$ ping6 2001:db8::1
PING 2001:db8::1(2001:db8::1) 56 data bytes
64 bytes from 2001:db8::1: icmp_seq=2 ttl=64 time=53.7 ms
64 bytes from 2001:db8::1: icmp_seq=3 ttl=64 time=13.1 ms
64 bytes from 2001:db8::1: icmp_seq=4 ttl=64 time=22.0 ms
64 bytes from 2001:db8::1: icmp_seq=5 ttl=64 time=22.7 ms
64 bytes from 2001:db8::1: icmp_seq=6 ttl=64 time=18.4 ms

Hopefully the videos listed earlier provide a sufficient foundation to understand what will happen shortly. However, there is still a bit more preparation required.

Build and probe Greybus Kernel Modules

cd ${WORKSPACE}/sw/greybus
make -j`nproc --all`
sudo make install
../load_gb_modules.sh

Build and Run Gbridge

sudo apt install -y libnl-3-dev libnl-genl-3-dev libbluetooth-dev libavahi-client-dev
cd gbridge
autoreconf -vfi
GBNETLINKDIR=${PWD}/../greybus \
  ./configure --enable-uart --enable-tcpip --disable-gbsim --enable-netlink --disable-bluetooth
make -j`nproc --all`
sudo make install
gbridge

Now that we have set up a reliable TCP transport, and set up the Greybus modules in the Linux kernel, and used Gbridge to connect a Greybus node to the Linux kernel via TCP/IP, we can now get to the heart of the demonstration!

First, save the following script as blinky.sh.

Second, run the script with root privileges: sudo bash blinky.sh

The output of your minicom session should resemble the following.

The SensorTag comes with an opt3001 ambient light sensor as well as an hdc2080 temperature & humidity sensor.

First, find which i2c device corresponds to the SensorTag:

On my machine, the i2c device node that Greybus creates is /dev/i2c-8.

Read the ID registers (at the i2c register address 0x7e) of the opt3001 sensor (at i2c bus address 0x44) as shown below:

Read the ID registers (at the i2c register address 0xfc) of the hdc2080 sensor (at i2c bus address 0x41) as shown below:

The blinking LED can and poking i2c registers can be a somewhat anticlimactic, but hopefully it illustrates the potential for Greybus as an IoT application layer protocol.

What is nice about this demo, is that we’re using Device Tree to describe our Greybus Peripheral declaratively, they Greybus Manifest is automatically generated, and the Greybus Service is automatically started in Zephyr.

In other words, all that is required to replicate this for other IoT devices is simply an appropriate Device Tree overlay file.

The proof-of-concept involving Linux, Zephyr, and IEEE 802.15.4 was actually fairly straight forward and was accomplished with mostly already-upstream source.

For Greybus in Zephyr, there is still a considerable amount of integration work to be done, including * converting the fork to a proper Zephyr module * adding security and authentication * automatic detection, joining, and rejoining of devices

Thanks for reading, and we hope you’ve enjoyed this tutorial.