So, to use the Uno Q to its full extent, I'd use C/C++, Python, HTML and Javascript, right? Long time ago I wrote PHP scripts into HTML code. I liked that concept. Things happened on the server side, not in the user's browser. If we want dynamic web pages to control the Uno Q, would it be possible to use PHP instead of Javascript? On the Q, there is some kind of a web server, right? It could possibly run PHP. Then again, that wouldn't get rid of Javascript, would it? Would Javascript still be the interface language between the Python script and the web page?

Then again, Streamlit turns the whole concept around all of a sudden. This is how AI described it, when I asked for clarification: Let me get this straight. If I have the MCU part with its C/C++ sketch, and I have the MPU part with its Python sketch, and I have the Web page doing the GUI stuff with Streamlit, the actual event loop is the Streamlit engine, which only uses the Python as kind of subroutines. Yes, you have hit the nail on the head. That is exactly how the architecture works, and it is the most common trap developers fall into when using Streamlit. Streamlit completely flips the traditional script of how Python programs run. The Streamlit Mental Model In a normal Python script, your code controls the event loop. In Streamlit, Streamlit controls the event loop, and your Python script is essentially one giant subroutine that gets executed from top to bottom every single time something changes on the web page. [1, 2, 3] Because I have some time critical parts in my program, both in the Python script and the MCU sketch, Streamlit can allow the Python script to have some functions set on a timer to be run on their own, not part of the "subroutine call" of the whole Python script. Though very messy, it makes sense.

[image] GolamMostafa: def main(): Bridge.provide("linux_started", linuxStarted) Bridge.provide("python_func", python_func) while True: time.sleep(1) if __name__ == "__main__": main() It is not clear to me why Bridge.provide() needs to be placed inside the main() function. Would it not have the same effect if it were placed before main() at the very laeft margin allowing Python to access it directly?

[image] GolamMostafa: Would it not have the same effect if it were placed before main() at the very laeft margin allowing Python to access it directly? I guess it makes no difference. I believe it's a C/C++ thing to have all executable lines inside main() and other functions, and only leave global variable declarations outside. Being at the steep beginner learning curve of Python myself, I have a hard time reading all the executable lines in the beginning of a Python script.

Thank you for the reply. We need to discuss this subtle thing in the forum to increase the UNO Q participation. We mat also discuss the difference of the following two frameworks: if __name__ == "__main__": main() and App.run(user_loop=loop)

[image] GolamMostafa: App.run(user_loop=loop) I asked AI and it confirmed that App is a class like thing, which has a method or function named run(). And one argument is called user_loop, which takes the value of a function pointer (talking C/C++ here). So, to use that exact line, you need to have a function named loop(), just like in an Arduino sketch: def loop(): # Your main loop starts here foo = bar App.run(user_loop=loop) You don't create a while True: loop yourself. You let the App do the looping of your loop(). My uneducated guess is that the App class handles the looping better, maybe giving processor time to other underlying processes between each loop.

[image] Johan_Ha: I asked AI and it confirmed that App is a class like thing, which has a method or function named run(). As run() is a method; so, App must be an object.

[image] GolamMostafa: 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++.

[image] Johan_Ha: maybe giving processor time to other underlying processes between each loop. 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.

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! [image] Johan_Ha: 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. If you ever find you are unable to resolve some confusion, just let us know and we'll try to help.

UNO Q: One board, four languages?

Official Hardware UNO Family UNO Q

sterretje October 6, 2026, 10:31am 33

@GolamMostafa

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

Topic		Replies	Views
UNO Q: Possible to connect Python (not containerized) with Arduino ? UNO Q	22	1166	August 27, 2026
Let us learn Arduino UNO Q step-by-step UNO Q	15	1570	August 26, 2026
Arduino UNO Q and Bridge Tool: any samples and documentation? UNO Q	36	3963	May 7, 2026
Is Arduino UNO Q really an upgrade? UNO Q	57	1572	October 23, 2026
UNO Q – Modulino sensors dashboard using App Lab, Bridge and WebUI UNO Q	59	1557	March 1, 2026

UNO Q: One board, four languages?

Related topics