BeaglePlay (with BeagleConnect Freedom) RoadTest

Table of contents

RoadTest: Sign Up to Review the BeaglePlay, BeagleConnect Freedom and Sensors

Author: Fred27

Creation date:

Evaluation Type: Development Boards & Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: Other boards in the BeagleBoard range. Other SBCs like the Raspberry Pi.

What were the biggest problems encountered?: Lack of finished documentation

Detailed Review:


I'm going to start with a quick overview of how I'm going to approach this road test and a summary of my skill level and experience with all things BeagleBone. This is not because I think you want to know about me, but so you can see if this fits with what you would want to get out of a BeaglePlay / BeagleConnect Freedom.

As I've said in previous road tests for programmable devices (microcontrollers, FPGAs, etc.) we're all spoilt for choice when it comes to picking a suitable tool for the job. Everything is just so capable and so cheap for what you get. The changes are that whatever device you're thinking about using is more than capable of doing the job. In my opinion devices stand or fall depending on their usability. If the documentation and example code is lacking and you have to trawl through dense datasheets then there's probably a suitable competitor that will have you up and running more easily. Unless you're producing thousands of devices, your time and sanity is worth more than the materials. This road test will focus on how easy it is to get started using the sensors that the BeaglePlay / BeagleConnect Freedom are so obviously designed for. I plan to see if I can use devices connected directly to the Play (via mikroBUS, Grove or Qwiic) and then to remotely via the Freedom.

As far as my skillset goes, I'm a software developer who is perhaps 80% Windows / .NET and 20% Linux. I'm happy writing code in C (or Python) for the Pi or BeagleBone. I don't have any experience in merging device trees or anything like that - and I'd rather not have to learn. I'm guessing that I'm probably a reasonable fit for the target market for the Play / Freedom, especially as in a recent Webinar I heard Jason Kridner himself say that the purpose of these new boards is to avoid all that stuff. It should be far more plug-and-play than previous board. Excellent. Let's see if that's the case…

Getting started (hardware)

The Play comes in a similar box to the BeagleBone Black. As the BeagleBone Black is probably the one people are most familiar with that's the one I'll be comparing it to, although the BeagleBone range - White, Green, Blue, Pocket, etc. - are all quite varied. The board however doesn't stick to the old form factor that most of them share. It's pretty much square.

There's also a new Sitara processor the AM62x series. This has a quad core 64-bit ARM Cortex A53 running at 1.4GHz and alongside that there is a M4F @ 400MHz and 2 PRUs @333 MHz.

This is a significant bump up from the Black which had a single core 32-bit A8 with 2 PRUs running at 200Mhz. This is not the first 64-bit BeagleBone however. The AI-64 used a different processor - the Jacinta as opposed to the Sitara - and was targeted at a slightly different space to the other devices.


The first thing you'll notice is that the two main headers with loads of GPIO have gone and been replaced by one mikroBUS header, one Grove and one Qwiic. I must admit that I've never used Grove and never heard of Qwiic. Power and USB connectivity is unsurprisingly now via USB-C. There's a full size HDMI port compared to the microHDMI on the Black. The USB host remains but has flipped vertically.



There initially appears to be two ethernet jacks, but on closer inspection one of them is Single-Pair Ethernet (SPE) with a RJ11 jack.

The SPE seems like an odd choice. It comes as the 10Base-T1L variant which can also referred to as long-range SPE or industrial ethernet. (There's also a 10Base-T1S automotive variant but this isn't compatible.) To be honest I don't think I'll cover SPE in this road test. There don't seem to be many devices around - apart from obviously another BeaglePlay. RJ11 doesn't appear to be a standard SPE connector either. The only other hardware around seems to have standardised on a jack such as this. It would have made more sense to at least fit this in place of the RJ11.

A bit of reading reveals that the BeaglePlay can supply Power over Data Lines (PoDL) at  5V/250mA so could be used to power a remote sensor. Considering 10Base-T1L is point-to-point this would only work with one sensor; any switch would negate any PoDL.


One of the main features of the BeaglePlay seems to be its wireless capabilities. There's dual band Wi-Fi which requires two external antennas to be fitted. There's also an on-board CC1350 microcontroller which requires one 2.4GHz antenna for BLE and a second antenna for sub-1GHz networking.

I didn't fancy having 4 antennas dangling around whilst I was roadtesting, so for now I just plugged in an ethernet cable (and USB-C for power). Connecting an Ethernet cable to a BeagleBone Black meant you could connect (either as a web server or over SSH) to beaglebone.local. Guessing that the same might work here using beagleplay.local instead did the trick.

TagConnect debug header

Most users might not notice the change in the debug header. However, having played a bit with debugging the PRUs in the BeagleBone I spotted that the footprint for soldering on a TI 20-pin connector has gone. It's been replaced by a 10-ping TagConnect header for both the main Sitara AM62x processor and the wireless CC1352 co-processor.

I'd previously bought TI's XDS-110 debugger which worked well with the 20-pin header on the BeagleBone range. I was a little reluctant to stump up for the somewhat expensive for what it is TagConnect cable - especially as there's no obvious way to connect it to the XDS-110. Luckily, E14 super contributor Shabaz had made some XDS-110 to TagConnect adapters for a previous project and he very kindly sent me a PCB.

It didn't take long to solder up an adapter and I tried using TI's Code Composer Studio to test the debug connection - XDS-110 to adapter to TagConnect to BeaglePlay. CCS was quite happy to connect to the CC1352 for debugging but not it seems to the main AM62x. Maybe it's just a custom Target Configuration I need. I haven't dug any deeper yet, but it's a bit disappointing. Snapping open the BeagleConnect Freedom's case also reveals a similar header but despite being the same CC1352 this also refused to connect from CCS.


Ahead of receiving the kit I noticed that files were provided to 3D print your own BeaglePlay case. Great! I downloaded these and printed a copy. Whilst the design is nice, I found that even a slight amount of warping from my Ender 3 S1 Pro meant the case was hard to assemble. The buttons were also very difficult to insert. It seems the design might be better suited to a professional injection moulded case rather than consumer 3D printed. Great that it's provided though.

So, instead f using the case I decided to add the standoffs that are very helpfully provided in the box. To be honest they work very well, although I did notice (after I installed them) that you need to be careful near the eMMC flash.


Getting started (software)

I'm somewhat familiar with the BeagleBone range so I booted up from the onboard eMMC which comes preloaded with a Debian image. The guide explains how to connect to the BeaglePlay over USB and how to connect it to your Wi-Fi network. It didn't mention Ethernet, but using the trick about it all works the same way.


My plan for this road test was to try out some devices (Qwiic, Grove, mikroBUS) attached directly to the BeaglePlay and then see how easy it was to use a mikroBUS device “remotely” by attaching it to the BeagleConnect Freedom instead. This seems to be the sort of use case that this combo is aimed at.

Debian OS

The OS that's pre-loaded describes itself as " Debian Bullseye Xfce Image 2023-02-04" and checking online shows that there's no newer stable build available yet. This build is based on Debian 11.6 as opposed to the 11.3 for other Beagle boards. I noticed that there's no IoT (i.e. headless) images available which seems odd for a device that sems to be aimed at being used as a gateway. The usual "sudo apt update && sudo apt upgrade -y" had some updates including Kernel requiring reboot.

Visual Studio Code

I was quite pleased to see that the Cloud9 IDE from previous Beagles has been replaced by Visual Studio Code. I'm fairly familiar with VS Code and it's seems to have become the new across-the-board standard. Simply go to http://beagleplay.local:3000 (or use whatever IP address is relevant) and the web version of VS Code appears. Unfortunately, all the example code is still for the BeqgleBone Black. According to the BeagleBoard forum, updating these examples will take a back seat to getting documentation up to date. At the time of writing, neither are in any way complete.

Personally, I like to use the desktop version of VS Code on my PC and although undocumented, it's pretty easy t connect this to you BeaglePlay. All you need to do is install the “Remote - SSH” extension on your desktop VS Code installation and you can connect to the VS Code Server running on your BeaglePlay over SSH. A much nicer experience in my opinion - and you still get the remote terminal.
Connecting via the VS Code web interface image


The roadtest kit included 3 Grove sensors, so that seems like a good place to start. The first is an ADXL345-based accelerometer which interfaces to the BeaglePlay over I2C. As the Grove connector is on I2C bus 1, the device can be detected using “ic2detect -y -r 1”. There it is - sitting at address 0x53.

As this is a roadtest of the hardware rather than creating professional software, I took the simplest route to test the device. I grabbed a Pimoroni ADXL345 library intended for the Raspberry Pi, updated it to use I2C bus 1 (rather than detect what was available on the Pi), installed the smbus Python dependency and ran some test code. Success!

From the documentation and forum posts I've read, and comments I've seen in webinars, this is the experience that the BeaglePlay is aimed at - lowering the barrier to entry for getting something up and running. No device tree overlays, no length learning curve. This took me 10 minutes of effort and somebody else's library. We're off to a good start!

Buoyed by this quick success, I moved on to the two other provided sensors.

The light sensor and the temperature sensor are both analog devices. They're intended to be connected to an ADC input and the voltage scaled to give the appropriate reading. Now, here's where things got trickier. There's no documentation - or any mention at all - of using analog inputs on the BeaglePlay. I expect the Sitara AM62X will have some, but where?

I ended up going to the Open Source design file sand finding the schematics for the board.

This isn't low-barrier-to-entry territory, but what else could I do? It turns out that right at the bottom of the schematic the Grove ADC input is connected to an ADC102S051 ADC chip and this in turn connects to MCU_SPI1 on the processor. So, I don't need to know about the Sitara's ADC capabilities; I need to know about SPI…


Unfortunately, there is absolutely no info on the BeaglePlay's SPI. Nothing. Digging up info on SPI for previous BeagleBones is no help. Things have changed. There are no SPI devices under /dev any more. Due to the complete lack of info here, I've written the 2 analog devices off as a dead end - for now at least.


The variety of connectors on the BeaglePlay inspired me to try some Qwiic devices. I must admit I'd never heard of these but they seem to all be I2C devices so shouldn't be too hard to use. I spotted a couple of Python examples on and combined a few Qwiic devices - an OLED screen and a couple of light-up buttons - into a simple but non-trivial Python example. If you press one button then the other will light up and a message will be displayed on the screen.

#from __future__ import print_function
import qwiic_oled_display
import qwiic_button
import sys

def run():
    print("Testing Qwiic devices")

    # This expects a Qwiic OLED display to be connected
    oled = qwiic_oled_display.QwiicOledDisplay(0x3C)
    if not oled.connected:
        print("The Qwiic OLED Display isn't connected to the system. Please check your connection", file=sys.stderr)

    # This also expects 2 Qwiic buttons - the red one having had it's I2C address changed from the default
    green_button = qwiic_button.QwiicButton()
    red_button = qwiic_button.QwiicButton(0x70)

    green_pressed = False
    red_pressed = False


    while True:
        if green_button.is_button_pressed() == True and green_pressed == False:
            green_pressed = True
            red_pressed = False
            oled.set_cursor(0, 0)
            oled.print("Green pressed   ")
            print("Green pressed")

        if red_button.is_button_pressed() == True and red_pressed == False:
            red_pressed = True
            green_pressed = False
            oled.set_cursor(0, 0)
            oled.print("Red pressed   ")
            print("Red pressed")

if __name__ == '__main__':
    except (KeyboardInterrupt, SystemExit) as exErr:
        print("\nFinished Qwiic test")

mikroBUS (directly attached)

One of the reasons I wanted to explore the BeaglePlay and BeagleConnect Freedom is that I had a few mikroBUS devices already. I liked the idea that these were supposed to be pretty much plug-and-play and that they could be used on both devices. Unfortunately, mikroBUS seemed to be the most difficult to use.

I managed to stumble across some information on using device manifests on older BeagleBoards and I made some limited progress. I managed to go from my OLED-B click not working at all to getting it to at least power on and display some static on the screen. However, I really felt like I was stumbling around in the dark. As this was the antithesis of the proposed BeaglePlay experience, and because my minor successes felt like coincidence rather than progress, I don't feel comfortable writing up the steps I made. The best I can do is point you to this PocketBeagle-focused document and hope you have more luck.


mikroBUS (remote)

Well, considering I didn't get anywhere using these directly, I had no idea where to start using them remotely!

BeagleConnect Freedom

Once I realised there wasn't a lot I could do with mikroBUS on the BeagleConnect Freedom, that pretty much left me with running the sensor test example and just seeing temperature, humidity and light level being passed back to the BeaglePlay. Once again, this device is full of potential, but locked away behind a lack of documentation. The pairing of the BeaglePLay with this remote module was perhaps the most exciting aspect of the device. However, as it stands it seems very difficult to do anything othe than run a pre-built demo. I really hope thsi will change because I can see so much potential here. I just can't get to it at the moment.


I definitely intend to continue with the BeaglePlay. I haven't given up, but I think it might be sensible to wait for the documentation to be more than just placeholders. However, the longer they remain this way, the less confidence I have that they will suddenly become the sort of documentation that's clearly needed. This, for instance, is the section on expansion as I write this RoadTest. Empty. I'm hoping that at somepoint in the future someone reading this will think to them selves how out-of-date this review is and everything now fleshed out.


A couple of things I haven't touched on - that I hoped perhaps I would - is managing to code for the onboard Cortex M4F processor and the PRUs. There is no documentation on either, and to be honest the lack of available pins to connect to either device mean that the PRU at least has limited potential.


I think I can summarise the BeaglePlay with “nice hardware, shame about the documentation”. This might have been OK if it wasn't promoted as being easier to use that previous boards.

One thing that might be nice to see in the future would be another BeagleBoard using the Sitara AM62x processor but with a form factor more like the BeagleBone Black - i.e. lots of IO. I'm not saying this would necessarily be better that the Grove / Qwiic / mikroBUS on the BeaglePlay, it would just be nice to have the option.

  • It's seems there's another new BeagleBoard just out. As focus switches to the latest shiny thing, I think that might just put a nail in the coffin of hope that the documentation for this one will ever be completed. Rolling eyes

  • I  guess  that the  only  remedy   for  the  lack  of  documentation is  to    install  another layer  of  abstraction  like  NodeRed   or  home  assistant !

  • Good review, thank you.  I've said it before, I really like the beaglebone series of boards.  This model sounds like it has potential.  But.  It reminds me of the beaglebone-AI road test on e14 from a few years ago.  The members here at e14 did a great job, but it was a struggle due to the limited documentation.  (the beaglebone-AI was also a bit underpowered which they seem to have fixed with the beaglebone-AI64). 

    I am intrigued by the SPE port.  Looking around this is all too new, not much hardware is available.  There's a sparkfun board, but I'd agree with you, probably a second beagleplay makes the most sense to test it out.

  • You're right that it is all possible with a lot of background info. All you need is the processor datasheet and the Linux source code. However, this board was promoted as being easy to use without having to dig into this.

  • A great review, which was very easy to follow.

    I've recently been diving into SBC's other than the Raspberry Pi. This was mainly driven by stock out. Anyway, it has taken many painful months to learn that almost all have the same issue... namely “nice hardware, shame about the documentation”.

    On forums there is often a common response when questioning documentation. Namely, that is a Linux OS issue or please refer to the Linux kernel documentation or please refer to Debian documentation etc.

    So, I've learnt the hard way that issues like "there is absolutely no info on the BeaglePlay's SPI. Nothing." can be resolved by reading through Linux documentation. This also involves getting to know Device Tree Overlays, and this is where it gets messy as this relates to distro + board. It all depends on what is found in the /boot directory. Then once you have linked your "dtbo" file in the extlinux.conf you have to manually "bind" it to get it working. Basically messy to learn, but easy when you know how.

  • thanks for the review, it must be incredibly frustrating trying to write a review when you are road blocked by the documentation each turn you make.

  • Some interesting history! I never knew that BeagleBoard had comparable sales volume.

  • Hi Fred,

    Regarding "they could have had the sales volume of the Pi", interestingly, they did for a while (it was at a similar-ish volume, maybe half or a third of Pi), but the bottleneck was not customer demand, it was production capacity. Their answer was to throttle demand by raising prices! After that, Pi had huge traction, after all, it was low-cost enough to be in enough people's hands, and they seem to have recognized community importance quickly (even though they made a lot of missteps along the way too). Pi were soon saving millions (their claim, not mine) per year by relying on community support.

  • Hi Fred,

    Very useful review! I had been looking forward to reading about the BeaglePlay board, since, I also like TI hardware, but was curious if the documentation was usable. 

    Regarding the Freedom board, I too normally feel reasonably competent at working with new hardware, but struggled to find any documentation/pointers to help. That's definitely a good idea that they need a grad or two as you mention, to accelerate that.

  • I really with this wasn't the case, but I have to agree with you. In some ways the BeagleBone range has a lot going for it - more than the obvious competitor of the RaspberryPi. However, the excellent hardware is let down by poor documentation and support. It's frustrating because the "hard" bit of designing great hardware has been done. The easier (but not as much fun) bit of supporting it is lacking.

    This is something I've seen a few times with open source. The answer of "well, it's all open - you could contribute" may be great in theory but there's a steep and unsupported learning curve before you can effectively contribute and help others.

    I work for a company that uses Raspberry Pis for a few projects. I have suggested BeagleBones - especially when Pis were unavailable - but it's a difficult sell. Where the Raspberry Pi foundation have done well is the support and community. It's hard to advise against that. The main BeagleBoard guys seem to be from TI. In my opinion TI would do well to contribute a few bodies to filling the documentation gap. For the cost of a few graduate salaries they could have had the sales volume of the Pi.