UNO Q: One board, four languages?

Official Hardware UNO Family UNO Q
22

As run() is a method; so, App must be an object.

23

You're right. Thoug sometimes classes have these methods, which can be referred to directly through the class name, at least in C++.

24

If I upload the following blank app from App Lab, what are the underlying/background tasks the Linux/MPU and Zephyr/MCU execute?

Sketch:

void setup() 
{

}

void loop() 
{

}

Script:

import time

from arduino.app_utils import App

print("Hello world!")

def loop():
    time.sleep(10)

App.run(user_loop=loop)

Answer from Gemini
When you click Run on a totally blank app in Arduino App Lab on the Arduino UNO Q, even though you haven't written any custom code, a highly synchronized dance occurs between the high-performance Linux microprocessor (MPU) and the real-time microcontroller (MCU).

Because an App Lab project inherently binds these two architectures together, a blank app triggers a baseline set of background orchestrations, initialization scripts, and daemon processes across both domains.

1. On the Linux Subsystem (Qualcomm MPU)

The quad-core Qualcomm processor running Debian Linux acts as the master orchestrator. When you launch a blank app:

  • App Lab Orchestration Engine: The App Lab environment (or arduino-cli running in the background) intercepts your "Run" command. It checks the file tree of your app.

  • Python Interpreter Initialization: Linux spawns a process to spin up the Python interpreter and points it toward your app's default main.py. For a blank app, this script essentially just imports base libraries (like bridge) and enters an empty execution thread.

  • The Bridge Library Daemon: The Arduino Bridge/RPC (Remote Procedure Call) library service is initialized on the Linux side. Even if no data is being sent, it opens up the internal high-speed communication bus (SPI/UART channels mapped inside the Linux Devicetree) to listen for the MCU.

  • Networking & OS Housekeeping: Standard Debian services continue to run in the background, managing Wi-Fi/Bluetooth connections, file systems (eMMC storage), memory optimization, and mDNS network discovery for App Lab remote communication.

2. On the Real-Time Subsystem (STM32 MCU + Zephyr RTOS)

Simultaneously, the STM32U585 microcontroller runs the open-source Zephyr RTOS kernel. Even with a completely empty sketch (setup() and loop() are empty), Zephyr executes essential deterministic background operations:

  • The Loader & Firmware Compilation: If a blank sketch (sketch.ino) exists in your App Lab project subfolder, arduino-cli compiles it against the Arduino Zephyr core and flashes/loads it onto the STM32.

  • Zephyr Kernel Boot & Scheduling: The Zephyr kernel boots up, initializes its multi-threaded scheduler, and registers hardware clocks, timers, and power management configurations via its Devicetree.

  • Peripheral Idle State Configuration: Zephyr configures the base states of the physical hardware headers, internal buses, the onboard 8x13 LED matrix, and RGB user LEDs—putting them into a safe, waiting idle state.

  • Microcontroller RPC Daemon: Just like Linux, the MCU initializes its half of the Arduino Bridge RPC library. Zephyr runs a background thread that constantly polls or listens to the internal communication bus, waiting for Python commands or data requests from the MPU.

  • The Main Empty Loop Executer: Once the framework is ready, Zephyr repeatedly executes the core Arduino loop() thread at the hardware level, passing through empty instructions while maintaining low-latency readiness.