Arduino Uno Q Support/Examples

[TMRh20]

Describe the behavior you would like

The Arduino Q MCU works fine with RF24, although it requires some modifications to the examples. It also utilizes python on the MPU side, so a "Bridge" API exists to pass information to/from the MPU.

Propose an implementation or solution

We could add examples to the library to demonstrate usage with the Arduino Q since it is an official Arduino board and does not work out of the box with any of our examples. It would probably be worthwhile to show simple bridge API coupled with RF24 passing info from the MCU to the MPU/Linux.

Describe alternatives you have considered

Add examples for the Q to higher level libraries instead, or not at all

Additional context

No response

[2bndy5]

Do the Linux examples not work/apply on the Arduino Q?

[2bndy5]

It would seem that the encodeRadioDetails example is a perfect starting point. It requires a Python side (no special python libs required) to show printDetails() output from a string of bytes containing data from the radio's registers.

• The hexadecimal string of bytes is currently transferred with Serial.print(), but it shouldn't be too hard to #ifdef the Bridge API instead of Serial.print() calls.
• The python script is currently designed to be a CLI app that takes the byte string as a positional arg. I think the print_details() function would become the callback for the bridge API and import argparse (and related API) would be moved into if __name__ == "__main_": conditional bock.

---

For all other examples, it would be pretty tedious to create examples. All user input during setup() should be done in python side. During loop() the switching of roles (and stdout) is all that needs migration.

[TMRh20]

Do the Linux examples not work/apply on the Arduino Q?

Nope, the Q MPU doesn't have direct GPIO or SPIDEV access to the MCU functionality. The MCU portion has to run RF24 Arduino, and you use a 'bridge' API to transfer data between the MCU and MPU.

I was really just thinking of adding a single GettingStarted example, since users should be able to extrapolate usage with other examples from that.

Arduino Side:

1. Need to #include <Arduino_RouterBridge.h>
2. Use Monitor instead of Serial
3. Add Bridge.begin(); to setup()
4. Add Bridge.notify("RF24Callback", payload); to main sketch RX node section
5. Minor changes to bypass/modify user input sections

Python SIde:

import time
from arduino.app_utils import *

print("Python Bridge Example for RF24 GettingStarted example!")

def RF24Callback(payload: float):
    print(payload)

Bridge.provide("RF24Callback", RF24Callback)

def loop():
    """This function is called repeatedly by the App framework."""
    # You can replace this with any code you want your App to run repeatedly.
    time.sleep(10)
    print("Python")
    

# See: https://docs.arduino.cc/software/app-lab/tutorials/getting-started/#app-run
App.run(user_loop=loop)

[TMRh20]

Ahh, I see what you are getting at with encodeRadioDetails, I will take a closer look at that one.

[2bndy5]

My one problem with their approach to this new hardware design: How is one supposed to transfer structured data?

I'm having trouble finding proper documentation for this Bridge API. It seems the they use a server/client to implement the Bridge.

This app lab is likely written in go, but it seems they are keeping the source proprietary (which explains why each instance of the word "Python" in the tutorials is accompanied by a ®).

So, non-OSS and the complexity... I'm not loving this new direction of Arduino under Qualcomm leadership.

[TMRh20]

Hehe I don't think too many people are impressed by the Q, but it seems like it can do some interesting things.

The bridge seems to be a simple serial interface running at 115200 baud using RPC. I found this documentation: https://docs.arduino.cc/tutorials/uno-q/user-manual/#bridge---remote-procedure-call-rpc-library

[2bndy5]

No one is self-hosting AI; Espressif must be laughing at the Uno Q because consumers could have avoided the complexity and did any AI thing using an ESP32.

Sounds like they basically made a Linux SBC (featuring a Qualcomm CPU - surprise surprise) with a STM32U585 (literally the same chip used in the "black pill" board) attached to a dedicated TTY port. Years ago, my robotics club (in college) used the same approach to control a robot over WiFi, comprised of a RPi 3 and Arduino Uno (ironically).

I tried looking into how the app lab uses after-market "Bricks", but the API there seems to be largely undocumented. I did find the arduino/app-bricks-py lib, which is not available via pip install BTW. I also found that arduino/arduino-router lib, but it does seem very well fleshed out (or maybe its just confusingly documented in the README). I couldn't find that Bridge library code (arduino-libraries/Arduino_RouterBridge, so thanks for the lead there.

[2bndy5]

Maybe now is a better time to assess zephyr support in the RF24 stack (at least up to Mesh layer). I gave up on that idea years ago because I wasn't fully grasping their use of DTS (Device Tree Specifications) for hardware allocation (similar to Linux's Device Tree Overlays). It seems their docs have since improved on the DTS front: See Arduino Uno Q board Zephyr support.

[TMRh20]

How is one supposed to transfer structured data?

It looks like the bridge API allows multiple arguments at least, so you can break down the data structures etc and send as multiple arguments. I think that's the best one can do.

So where do we start, or should I ask, DO we start lol?

[TMRh20]

I just confirmed the Q won't even work as a RF24Mesh client, it requires #define SLOW_ADDR_POLL_RESPONSE 10 on the master node.

This seems weird to me though, thinking the MCU should be plenty fast with SPI and GPIO, but its just not.

[2bndy5]

Well it's not just the MCU at play with the Uno Q. I'm not surprised the mesh layer needs to be slowed down.

If the encode radio details example is easily adapted, then I think that would be plenty enough.

For the higher network layers, we might have to explicitly declare limited support for the Uno Q.

Cutting out the Linux part of the Uno Q is why I'm more inclined to add zephyr support instead. This Uno Q might be a canary in a coal mine (a bad sign for future offerings from Arduino).

Mbed support should be possible too, but that is complicated by the fact that some Arduino cores wrap mbed API with Arduino API. Also, mbed is no longer operated by arm. Mbed has become a hard fork driven by a community that arm previously fostered.