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…
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.
https://uk.farnell.com/phoenix-contact/1163797/spe-conn-r-a-jack-2pos-pcb/dp/3703701
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.
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.
https://git.beagleboard.org/beagleplay/beagleplay/-/tree/main/Enclosure
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. https://git.beagleboard.org/docs/docs.beagleboard.io/-/issues/37
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.
The OS that's pre-loaded describes itself as "BeagleBoard.org 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.
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.
https://forum.beagleboard.org/t/beagleconnect-freedom-quickstart-sensortest-rx-py/34555/7
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.
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.
https://git.beagleboard.org/beagleplay/beagleplay/-/blob/main/BeaglePlay_sch.pdf
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 Hackster.io 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)
return
# 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
green_button.LED_off()
red_button.LED_off()
oled.begin()
oled.clear(oled.ALL)
oled.clear(oled.PAGE)
oled.print("Ready...")
oled.display()
red_button.LED_on(32)
green_button.LED_on(32)
print("Ready...")
while True:
if green_button.is_button_pressed() == True and green_pressed == False:
green_pressed = True
red_pressed = False
green_button.LED_off()
red_button.LED_on(32)
oled.set_cursor(0, 0)
oled.print("Green pressed ")
print("Green pressed")
oled.display()
if red_button.is_button_pressed() == True and red_pressed == False:
red_pressed = True
green_pressed = False
red_button.LED_off()
green_button.LED_on(32)
oled.set_cursor(0, 0)
oled.print("Red pressed ")
print("Red pressed")
oled.display()
if __name__ == '__main__':
try:
run()
except (KeyboardInterrupt, SystemExit) as exErr:
print("\nFinished Qwiic test")
sys.exit(0)
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.
https://git.beagleboard.org/beagleconnect/manifesto
Well, considering I didn't get anywhere using these directly, I had no idea where to start using them remotely!
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.
https://docs.beagleboard.org/latest/boards/beagleplay/04-expansion.html#beagleplay-expansion
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.
Top Comments
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…
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…