Announcement: BeaglePlay® from BeagleBoard.org® brings fun to building with computers – BeagleBoard.org Blog
Documentation: BeagleConnect Freedom — BeagleBoard Documentation
Design: BeagleConnect / Freedom · GitLab
So I notice that there is a good old fashioned MSP430 on this board and that seems connected with the USB-to-UART bridge…But I feel like I’m missing some background on “why”…can you explain a bit of what is the function of the USB-to-UART bridge?
Is it something like this? By binding the USB to a UART, it ultimately allows the MSP430 to be accessed / programmed OTA?
The CC1352P7 doesn’t have USB… so… we used the MSP430F5503 to provide it.
The MSP430 can be programmed using its BSL over the USB or via a TAG-CONNECT JTAG connection. I don’t expect people to reprogram the MSP430 a bunch, but, I would certainly encourage you to. The firmware source and USB-based flashing tool are at MSP430 · GitLab.
Anyway, we wanted to make the CC1352 easier to program and we also wanted to utilize the WPANUSB driver for Linux to provide a bridge. The WPANUSB driver isn’t mainline yet, but it was furthest along when we got started. We might migrate to a thin-MAC solution as that has some backing from TI and might make the BeagleConnect Greybus stuff work better too as that would enable discovery and routing to be handled outside of the Linux kernel in a more transparent way. Right now, we use a userspace app called GBridge to perform the discovery and routing.
Anyway, the USB-to-UART bridge provides an easy way to connect your PC and get a serial console (Micropython REPL right now) and to reflash the CC1352 using another BSL Python script.
Hope this answers the question. If not, let me know so I can be more pointed in my answer.
Anyway, we wanted to make the CC1352 easier to program and we also wanted to utilize the WPANUSB driver for Linux to provide a bridge.
I see, I was thinking of it in the wrong direction… so the MSP430 is there to assist programming the CC13x - makes sense.
Is the CC13x running some type of zephyr firmware?
Also I don’t have any experience with WPANUSB. I understand on linux it creates a network device which you can then just use via normal networking tools (ping, route, etc)?
What is range of this? Reading about 802.15.4 seems to indicate that it can support many many devices on same network with low latency (and low bandwidth). But what is typical range that these nodes can be? Do they form mesh network or must they all connect to same “gateway”?
Still trying to wrap my head around Zephyr / Greybus / wpanusb.
From reading about wpanusb in the Zephyr github, I see:
… this exports ieee802154 radio over USB to be used in other OSes such as Linux
Can you explain this a bit? Is this exporting the radio to linux while its tethered via a USB cable? OR is this somehow exporting the radio from BeagleConnect to BeaglePlay over-the-air?
The WPANUSB app (on Zephyr/CC1352) and driver (on a Linux host) are meant to provide access to the radio, so, just the routing part.
Before there was BeaglePlay, this was the way to enable Linux to communicate with the CC1352 nodes. With BeaglePlay, we run the WPANUSB app on its CC1352, but we then run BCFSERIAL as the Linux driver for the radio, since we have a serial, rather than USB connection, to the CC1352.
The Greybus stuff runs partially as a userspace app (GBridge) on Linux and partially in the kernel. BeaglePlay’s Linux distribution ships with GBridge and if you run enable the Greybus server on BeagleConnect Freedom, the ports can be controlled from BeaglePlay.
The firmware that ships with BeagleConnect Freedom is running Micropython and an SMP server (mcumgr). We’ve got versions of the Micropython app that include the Greybus server, but we haven’t created the interface from Micropython to turn that server on and off, so that version of Micropython cannot actually access the header peripherals, since Greybus has control. We plan to fix that and ship out that updated firmware image.
Recently, we’ve been considering moving the GBridge portion of the design to the CC1352 on BeaglePlay. This will make hotplug discovery work much cleaner and simplify the security model as well.
Thanks for this explanation. Its now much clearer how it all fits together.
A last question regarding Greybus: From reading about 802.15.4 I see that there are a number of different “protocol stacks” that use it, Wi-Sun, Amazon Sidewalk, Zigbee, etc…My question is, does Greybus require any specific one of those or is it agnostic to the specific transport chosen?
That is: Can my BeagleConnect export its GPIO via Greybus to a BeaglePlay and the two devices are talking over Wi-Sun?
Our Greybus implementation uses bare 6LoWPAN over IEEE 802.15.4g. Using any of the “richer” protocol stacks would require additional coding.
Thanks. From cursory reading its unclear to me if 6LoWPAN is currently mesh or point-to-point? How will the Connect nodes operate?
6LoWPAN itself is point-to-point. Connect nodes will use the BeaglePlay as a sensor aggregator.
It is possible to implement other protocols to enable mesh.
