Arduino
Webinar Date: February 12, 2026
Key Takeaways
- Unlock new potential: Learn how to effectively use UNO Q in conjunction with App Lab to streamline your prototyping efforts.
- Intelligence at the edge: Discover how to enable smart decision-making directly on your devices and enhance the capabilities of your projects.
- Accelerate your workflow: Discover techniques to enable intelligence at the edge, simplifying your application development process.
- Expert guidance: Gain insights from industry experts who will share best practices and answer your questions live.
Frequently Asked Questions
In real projects, how do you decide what runs on the Linux side (MPU) versus what must stay on the real-time MCU, and what are the “red flags” that tell you you’re about to put something in the wrong place?
-
A good rule is: anything that needs deterministic timing and must react “now” belongs on the MCU, while anything that benefits from compute, memory, files, networking, or higher-level stacks belongs on Linux. On UNO Q that maps perfectly to the “dual brain” promise: the MCU is your real-time reflexes for control loops, precise I/O, safety interlocks, and actuator timing, while the Linux side running on the MPU is your “thinking brain” for vision, UI, logging, AI inference, and richer connectivity flows.
-
The red flags are easy to spot: if you’re dealing with hard real-time constraints (tight PWM timing, closed-loop motor control, time-critical interrupts) and you try to do it on Linux, you’ll eventually hit jitter. If you’re doing heavy processing (camera frames, multiple sensors + dashboards, AI models) and you try to push it into the MCU, you’ll hit CPU/RAM limits and dev friction. UNO Q exists so you don’t have to compromise: compute and UX on MPU / Linux, precise control on the MCU, both on one board.
The presentation highlights RPC as the bridge between the two “brains”; what does that look like in practice when you’re moving data back and forth, and what latency/throughput should developers realistically expect?
-
Keeping simple, the RPC is the “conversation layer” between Linux and the MCU: the Linux side can call functions on the MCU as if they were local, and the MCU can expose read endpoints that Linux can trigger on demand. In practice, you treat the MCU as a reliable real-time I/O and control service, while Linux orchestrates higher-level logic, UIs, and AI decisions.
-
What developers should expect is that RPC is great for command-and-control and structured data exchange, not for pretending the two chips are one shared-memory system. You design it like a clean API: “set motor speed”, “read potentiometer array”, “arm safety relay”, “publish latest sensor snapshot”.
If a team already has Arduino Sketch code, what’s the simplest migration path to App Lab without rewriting everything, and what’s the first “hybrid” upgrade you’d recommend to feel the value fast?
-
The simplest path is to keep your existing sketch as-is on the MCU side, then add a small Linux-side python code in App Lab that talks to it through the provided libraries and bricks, when needed. The deck’s core message is that App Lab lets you combine Arduino sketches, Python scripts, and AI models into an app, so you don’t throw anything away—you mesh.
-
The fastest “feel the value” hybrid upgrade is to add something that would have been painful on a pure MCU board: a lightweight UI, data logging, or an AI-based decision step. For example, keep the sketch handling sensors and actuators, then add a Python script brick that logs data onto a real database (e.g influx, or sqllite) , serves a simple interface, or triggers actions when a condition is met. That immediately demonstrates “from sketch to AI, all in one place,” without a rewrite.
For vision and audio use cases, what does “AI-ready, vision-optimized” practically mean on UNO Q—what models run on-device, what performance constraints show up first, and when would you still involve the cloud?
- Practically, it means UNO Q is designed so you can run common edge-AI tasks locally and still keep real-time control. The actual list include examples ready to be used like face detection, person classification, anomaly detection, image classification, plus audio features like sound recognition and keyword spotting—explicitly framed as running directly on the board with no cloud required, and some other integrating external LLMs, that can be used a starting point, but ready to be evolved.
UNO Q talks about “going borderless” with Qwiic/Modulino and also classic UNO shields plus new high-speed connectors; how should someone choose the right expansion path for prototyping speed versus production realism?
-
If your priority is fast prototyping with minimal wiring risk, Qwiic/Modulino is the straight shot: it’s no-solder, polarized, chainable, and taps into a big ecosystem of plug-and-play sensors, buttons and actuators. That’s why the board ties it to accelerating prototypes with less wiring and fewer mistakes.
-
If your priority is reusing what you already have, UNO headers keep the classic shield ecosystem in play, which is gold for quick demos and legacy add-ons. And when you need “production-real” expansion for advanced peripherals—cameras, displays, audio, and high-speed GPIO access—the new carrier/high-speed connector path is the one that maps to the Linux side capabilities. In other words: Qwiic/Modulino for speed and breadth, UNO shields for compatibility, carriers/high-speed headers for advanced, high-performance I/O.
Does UNO Q support Yocto [open embedded] based build system?
- Out of the box is Debian, all tools run in Docker.. it’s designed to be generic to the host question.
When should I use Python coding instead of regular sketches?
- In Arduino’s App Lab’s current form, Python is used on the “Linux/Qualcommm” side, and your sketch is running on the little ST32U585.
Do I need to know Linux to implement voice recognition function?
- Not if you are just going to use a premade Brick
How do you interface Arduino sensors with the Linux side (database, parameters)?
- The out of box example uses influxdb in a docker container.
Can this Arduino work in hot climates like the desert?
- The UNO Q recommended operating temperature is -10C to +60C.
Is there a packaging case that can be used with the system, or do we have to design our own?
- Currently there are a number of 3rd party cases available, along with a few printable options.
Arduino UNO Q is compatible with Windows 10?
- Yes, if you install App Lab from the Arduino Website, they have a version for Windows 10 and 11 along with others.
Is there a book or guide for project with Arduino UNO Q?
- There are some great guides for the Uno Q on Maker.io:
Maker.io - Search for projects, platforms, products, posts, and more | Maker.io powered by DigiKey
Can this new uno be used to program other Arduino boards, leveraging the visual interface of the new UNO Q?
- It would be an interesting implementation, but since the Uno Q runs a full Linux OS, yes, you could install the Arduino IDE on the Q and use it to program other Arduino boards.
All these add on modules over I2C on single bus?
- Regarding Qwiic, yes, this is all on a single I2C bus
Which chipset of QCOM used…QCS2290 or 6490 or 610…?
- The Arduino Uno Q features the Qualcomm Dragonwing™ QRB2210.
Is there prebuild board support package available to start with?
- The latest BSP can be available from: https://www.arduino.cc/en/software/ (scroll down to Arduino Flasher CLI)
I was wondering if in the future there will be a Brick that helps with ROS 2?
- ROS 2 can be run on the Debian side; you can use the python bridge to talk to ROS today.
Is there a link to the GitHub bricks?
- Yes, please use the link below.
Is there any longer-range wireless functionality like Zigbee, etc.?
- The only Wireless functionality onboard is WiFi and Bluetooth, however additional, long-range wireless functionality could be added via expansion boards.
If I plan to utilize in industrial settings, how can I protect the source code and make sure it can’t be changed by anyone else?
- Once the STM32U585 is flashed, you would not need the Sketch source. For python on the Linux, side, you’ll need to do more Linux security. So multiple options, and levels… and guide here:
https://docs.arduino.cc/tutorials/uno-q/security-hardening-guide/
Possible to apply Linux security patches as they come out or needed?
- The current builds use a mostly mainline build; users are building more mainline kernels. See the Arduino forum for all the Linux patchset’s.
How many mini extension boards can be in that single chain?
- It would depend on power the power requirements of each extension board, if you are providing supplemental power to the extension boards, and if there are any addressing conflicts.
If PSU isn’t a limiting factor, what address range is available?
- I2C address range allows for up to 128 unique 7-bit addresses.
Are there new plug-in boards or shields available that are only compatible with UNO Q?
- Not currently. The “Shield” interface is common among most Arduino boards. There will be Carrier boards available soon that would only be compatible with the Uno Q. These would connect to the high-speed interfaces on the bottom of the board which connect directly to the Qualcomm processor.
What’s the line out audio?
- Audio out on the Uno Q would have to be thru the USB. USB to audio adapter. (or use the Arduino interface, but then this audio would be streamed from the STM32U585)
Is there a distance limit to the link cable?
- Qwiic (I2C) has a max recommended cable length of 1-3 meters depending on the electrical noise of the environment. However, there are ways to extend this, such as SparkFun’s QwiicBus boards: SparkFun QwiicBus Hookup Guide
Can the Arduino Uno Q run a Linux touchscreen interface directly, or should the microcontroller and Snapdragon CPU split the tasks between sensors and display?
- As long as the touchscreen supports HDMI/etc., then you can drive it from the Linux side and have touch. If your screen is small and simple, running from STMU585 is an option.
Does the Arduino UNO Q support Matter out of the box, and would I need an external radio for Matter over Thread? What’s the best way to use it in a smart-home setup?
- Out of the Debian side, something like this would be needed:
Do earphones need USB hub? Is it mandatory?
- After double checking the Uno-Q user manual, it says that the Uno Q has Bluetooth 5.1 which can be used for peripherals like keyboards, headsets, and serial devices.
What kind of USB hub will work?
- In our lab, we’ve had the best luck with Startech models, but I’m also pulling and testing any other ones I can find. I know the Apple ones do not work.
Uno Q is awesome no doubt, but we are having some confusion in Bridge.
- The Arduino Bridge over Linux’s RemoteProc layer is on the complex side, Arduino has done a good job at hiding some of the fun parts. It would best to ask that in Arduino’s forum, as that question/answer would get very complex for a webinar.
Can we run any LLM, or OCT?
- With 2GB or 4GB of memory, it would have to be a very small LLM (that memory is shared with co-processors).
Do you support unofficial Linux builds on the Dragonwing?
- The Dragonwing uses a mainline stable kernel, all the app’s run in docker, there is nothing stopping you from something else.
What are the different ways you can connect this board to ethernet?
- WiFi out of the box, USB network adapters.
Referral Webinar Link
If you would like more information from this webinar, please review the details below.