As run() is a method; so, App must be an object.
You're right. Thoug sometimes classes have these methods, which can be referred to directly through the class name, at least in C++.
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-clirunning 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 (likebridge) 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-clicompiles 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.
Ok, right now I have a very well working setup. I have a web based control page (local, not the web) where I build a playlist for my busker organ. I have a python script, which sends stuff to a javascript, which builds upp stuff in the html page. The javascript in turn sends stuff to the python script. The python script sends data to the MCU (running a c/c++ sketch), the MCU sends commands back to the python script.
Everything works just fine, but I still am very confused all the time, trying to figure out everything, what happens and where and when. Copilot has been to a great help, especially when I know very little Python.
Thanks for the update. It sounds like great progress!
If you ever find you are unable to resolve some confusion, just let us know and we'll try to help.
You may kindly post your app so that I can learn some of the language constructs.
I can resolve most of the confusion. It's just that there's a lot of it.
I might post the whole app somewhere, don't quite know yet if it's possible to pack into one. But the app builds up the web page, viewable on your phone, if you set up your Uno Q to connect to your phone hotspot. You can pick tunes to play, the Uno Q flashes a led while playing the tune, you can adjust angles et.c. All that without actually connecting the Uno Q to my busker organ. If you are interested in my solutions for the communication.
That would be an interesting experince for me.
Attached is a zip file of my project. I have no idea how the exporting works. But it should include all data files, too. One file named angles.txt with the open and close angles for each servo. And some 25 tunes coded in txt files.
If you run the app from App Lab, App Lab will open a browser window with the gui. When no tune is selected, the system will play a dummy tune consisting of some seconds of silence. One led goes yellow during the dummy tune play. When another tune is playing, a green led blinks with the music. The main page has a link to a tuning page, where I can adjust individual angles. Clicking the play buttons on the tuning page will abrupt a tune currently playing.
If your phone shares the same local net as your computer, you can get the IP of the Uno Q from App Lab and use that as an URL in your phone, if you want wireless control. The port number is 7000.
Hackordion App 1.zip (324.4 KB)
Here's the busker organ in action:
Your ZIP file of #30 was successfully downloaded, imported into App Lab, and run without any issues. A GUI interface appeared only once on my desktop, without any sound from my PC speaker. Anyway, your app (script and sketch) is a good source for me to learn the language constructs of Python and C++.
Thank you very much.
Q1: How much help (in % if any) have you taken from AI to prepare your app?
Q2: Which colours have you mixed for LED4 to emit yellow color?
I would like to suggest that you refer users to your topic UNO Q: Sharing Knowledge, Tips, and Practical Skills when asking for example code that does not directly relate to the topic at hand.
This will keep topics on-topic 
I will keep in mind. Thank you.
Copilot gave me some models of how to implement the push buttons in html, how to use Javascript to communicate with Python, how to use Javascript to build the table with 41 lines of servo angle values. Copilot also created some essential functions in Python. I'd say AI made 25% of everything. I have 18 months of chatting, where Copilot not only gave me code, but also was a good support with whom I discussed the over all design. Mainly how the MPU discusses with the MCU. Sometimes I convinced it that my idea was better, sometimes the opposite happened.
Red plus green make yellow. I used constant yellow, when the dummy tune plays. Constant green, when any other tune plays. And flashing green on the next rgb led for each note-on event. I think there's a blue light, too, when a routine is muting all notes.
There's no sound involved. No connection to the sound of your PC. Only I2C connection to PCA9685 servo controlling boards, further connected to 41 servos. I use PCA9685_RT lib, which seems to work even though nothing is connected.
So, Copilot (the AI) is helpful because you are a programmer and you know very well what you are asking for.
You have been chatting with AI for 18 months. With whom did the AI chat/discuss to get information for onward submission to you?