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.

Bottom line: For hundreds of devices, users won’t have to write a single line of code to add them their systems. The automation code they do write can be extremely simple, done with graphical tools or in any language they want. Maintenance of the code is centralized in a small reusable set of microcontroller firmware and the Linux kernel, which is highly peer reviewed under a highly-regarded governance model.

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 wireless hardware is built around a TI CC1352 multiprotocol and multi-band Sub-1 GHz and 2.4-GHz wireless microcontroller. 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.

BeagleConnect is:

• Available for at least 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.

• Host-side: BeagleConnect board connects a CC1352 to a Beagle or other Linux host over USB to serial

• Provides long-range, low-power wireless communications

• Device-side: BeagleConnect board with a CC1352 is powered by a battery (coin cell or JST connector) or USB connector

• Provides 2 mikroBUS connectors for connecting any of hundreds of Click Board mikroBUS add-on devices

• Standard firmware on the host-side and target-side CC1352s transport the standard busses

• Paired with a Linux kernel driver

• Provides new Linux host controllers for SPI, I2C, UART, PWM, ADC, and GPIO with interrupts

• Two-step provisioning

• Enter provisioning mode by pressing the button on the host-side BeagleConnect

• Press the button on any powered device-side BeagleConnect to add it to the network

  • The device interfaces get exposed to the host via Greybus BRIDGED_PHY protocol

  • The I2C bus is probed for a an identifier EEPROM and appropriate device drivers are loaded on the host

  • Unsupported Click Boards connected are exposed via userspace drivers on the host for development

• Linux machine

• 2x CC1352R Launchpad

• Click BoosterPack 2

• 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.

• 802.15.4 provides the

• 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 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