Arduino UNO Q: MCU und Linux im App Lab
Im letzten Beitrag habe ich dir gezeigt, wie du dich per SSH mit dem Arduino UNO Q verbindest, das Debian-System aktualisierst und Python installierst. Damit haben wir die Linux-Seite des Boards kennengelernt und den UNO Q wie einen kleinen Server im Arduino-Format eingerichtet.
In diesem Teil wechseln wir die Perspektive: Wir arbeiten nun im Arduino App Lab und programmieren das Board direkt über die Entwicklungsumgebung.
Dabei schließen wir einen Modulino-Sensor über die Qwiic/I²C-Schnittstelle an und bringen ihn zum Laufen. Doch genau hier zeigt sich die eigentliche Besonderheit des Arduino UNO Q:
👉 Wir haben es nicht nur mit einem Mikrocontroller zu tun. 👉 Wir haben ein Board mit zwei Welten.
Auf der einen Seite steht die MCU, die klassisch mit Arduino-Style C/C++ (oder je nach Setup auch Python) programmiert wird und direkt mit der Hardware kommuniziert. Auf der anderen Seite läuft ein vollständiges Linux-System, auf dem wir Python, Dienste und später sogar Monitoring einsetzen können.
Der große Vorteil: Wir können beide Systeme relativ einfach miteinander verbinden und so das Beste aus beiden Ansätzen kombinieren – schnelle Hardware-Ansteuerung auf der MCU und flexible Weiterverarbeitung unter Linux.
https://youtu.be/TXO1ihzzNZk
In diesem Beitrag zeige ich dir:
- wie das Arduino App Lab aufgebaut ist - wie du Code auf der MCU ausführst - wie du einen Modulino anschließt und ausliest - und warum die Verbindung zwischen MCU und Linux so spannend ist
Rückblick
Wie du den Arduino UNO Q einrichtest und ein erstes kleines Programm ausführst, habe ich dir bereits im Beitrag „Arduino UNO Q – Wenn dein Mikrocontroller plötzlich ein Mini-PC wird“ ausführlich gezeigt.
Dort ging es vor allem um die Hardware, das Konzept hinter dem Board und warum der UNO Q eben kein klassischer Mikrocontroller ist, sondern eher ein kleiner Linux-Rechner im Arduino-Formfaktor.
Im zweiten Beitrag „Arduino UNO Q – Linux, Python & Monitoring in der Praxis“ haben wir uns dann mit der Linux-Seite beschäftigt und gelernt, wie du per SSH auf die Shell zugreifst und Python installierst.
Genau hier knüpfen wir nun an.
In diesem Beitrag zeige ich dir, wie du den Arduino UNO Q im Arduino App Lab programmierst – sowohl im klassischen Arduino-Style mit C/C++ auf der MCU als auch mit Python im Linux-System.
Das Arduino App Lab verstehen
Statt erneut jede Oberfläche im Detail zu erklären, schauen wir uns den tatsächlichen Workflow im Arduino App Lab an – denn genau hier unterscheidet sich der UNO Q deutlich von einem klassischen Arduino-Board.
Der typische Ablauf im Arduino App Lab
Die Arbeit mit dem Arduino UNO Q folgt einem klaren Schema:
- Board auswählen Verbindung über USB oder Netzwerk herstellen. - Projekt anlegen Neue App erstellen und Entwicklungsumgebung vorbereiten. - In C/C++ und/oder Python programmieren Je nach Anwendungsfall wird Code für die MCU oder für das Linux-System geschrieben – oder für beide. - Projekt auf den Arduino übertragen und starten Die App wird deployed und direkt auf dem UNO Q ausgeführt.
Dieser Ablauf ist zunächst vertraut – zumindest für alle, die schon einmal mit der klassischen Arduino IDE oder der Arduino IDE 2.x gearbeitet haben. Der Unterschied liegt jedoch nicht im Workflow selbst, sondern in der Architektur dahinter.
Der entscheidende Unterschied zur klassischen Arduino IDE
Bei einem klassischen Arduino-Board gibt es nur eine Zielplattform: den Mikrocontroller.
Beim Arduino UNO Q hingegen arbeiten wir mit zwei Systemen gleichzeitig:
- MCU – für hardware-nahe, zeitkritische Aufgaben - MPU (Linux) – für komplexere Logik, Netzwerk und Python-Anwendungen
Im Arduino App Lab können beide Seiten aus einem einzigen Projekt heraus programmiert und miteinander verbunden werden.
Das ist zunächst ungewohnt, aber genau hier liegt die Stärke des UNO Q.
Warum das so spannend ist
Wir können Aufgaben sinnvoll aufteilen:
- Sensoren und Hardware direkt auf der MCU ansteuern - Daten auf dem Linux-System weiterverarbeiten - Funktionen systemübergreifend ausführen
Damit entsteht ein hybrides System, das deutlich leistungsfähiger ist als ein klassischer Mikrocontroller – ohne den typischen Bastel-Charakter zu verlieren.
Vergleich mit dem Raspberry Pi
An dieser Stelle lohnt sich ein kurzer Vergleich mit dem Raspberry Pi – insbesondere mit dem aktuellen Raspberry Pi 5.
Ein Raspberry Pi 5 in der 16-GB-Variante liegt derzeit bei rund 210 €, während der Arduino UNO Q in der 4-GB-Version bei etwa 65 € liegt. Preislich bewegt sich der UNO Q also in einem deutlich niedrigeren Bereich.
Beide Geräte basieren auf einem Linux-System – doch der Ansatz ist unterschiedlich.
Raspberry Pi
Beim Raspberry Pi arbeiten wir ausschließlich auf einem Linux-System. Das bedeutet:
- Projekte werden direkt unter Linux umgesetzt - Typische Sprachen sind Python, C/C++, Rust, Go oder Node.js - Es gibt keinen separaten Mikrocontroller für hardware-nahe Echtzeitaufgaben
Raspberry Pi 4B - 2GB Version
Raspberry PI Modell 3 B+
Raspberry PI Model B+
Für viele Anwendungsfälle ist das vollkommen ausreichend. Gerade bei komplexeren Anwendungen oder Desktop-ähnlichen Projekten spielt der Raspberry Pi seine Stärken aus.
Allerdings bedeutet das auch, dass selbst einfache Hardware-Aufgaben vollständig im Linux-Kontext umgesetzt werden müssen.
Arduino UNO Q
Der Arduino UNO Q verfolgt einen hybriden Ansatz:
- Eine MCU für hardware-nahe, zeitkritische Aufgaben - Eine MPU mit Linux für Logik, Netzwerk, Dateisystem und Python
Dadurch entsteht ein System, das die Stärken beider Welten kombiniert.
Einfache Hardware-Logik kann klassisch im Arduino-Style umgesetzt werden, ohne sich sofort mit komplexen Linux- oder Multithreading-Konzepten beschäftigen zu müssen. Gleichzeitig steht bei Bedarf ein vollständiges Linux-System zur Verfügung.
Modulino anschließen – bewusst einfach gehalten
Über die bekannten Buchsenleisten des Arduino UNO Q können wir – ganz klassisch – Sensoren und Aktoren anschließen. LEDs, Buzzer, Taster oder Relais lassen sich wie gewohnt über die digitalen und analogen Pins verbinden.
Für diesen Beitrag möchte ich es jedoch bewusst einfacher halten.
Arduino bietet mit den sogenannten Modulinos kleine, kompakte Sensor- und Aktor-Boards an, die sich über die integrierte Qwiic-Schnittstelle (I²C) anschließen lassen. Der große Vorteil: Kein aufwendiges Verdrahten, keine zusätzlichen Widerstände – einfach anstecken und loslegen.
Arduino UNO Q mit Modulinos
Da der Fokus in diesem Beitrag nicht auf Schaltungsdesign oder Elektronik liegt, sondern auf der Programmierung und Architektur des UNO Q, nutze ich hier genau diesen Weg.
Da die Modulinos via I²C angeschlossen werden, können hier mehrere unterschiedliche Sensoren und auch Aktoren hintereinander verbunden werden!
Erstes MCU-Programm – Modulino Thermo auslesen
Damit wir das Modulino Thermo über die MCU ansprechen können, benötigen wir die passende Bibliothek. Arduino stellt hierfür die Bibliothek Arduino_Modulino bereit.
Diese Bibliothek enthält die Implementierungen für alle Modulinos – also nicht nur für das Thermo-Modul, sondern auch für weitere Sensor- und Aktor-Boards aus der Serie.
Zusätzlich installieren wir:
- Arduino_RouterBridge – für die Kommunikation zwischen MCU und Linux-System - MsgPack – zur strukturierten Datenübertragung über die Bridge
Auch wenn wir die Bridge in diesem Abschnitt noch nicht vollständig einsetzen, ist es sinnvoll, diese Bibliotheken direkt mit zu installieren. So ist das Projekt später problemlos erweiterbar.
Wie du das Modulino Thermo am Arduino UNO R4 ausließt und die Daten in die Cloud sendest habe ich dir im Beitrag Smarte Wetterstation mit dem Arduino Plug and Make Kit und Cloud-Dashboard ausführlich erläutert.
Der Code für die MCU wird unter sketch > sketch.ino abgelegt. Dort können wir wie in der Arduino IDE die Sketche programmieren.
#include #include "Arduino_RouterBridge.h" ModulinoThermo thermo; void setup(){ Monitor.begin(); Modulino.begin(); thermo.begin(); } void loop(){ float temp = thermo.getTemperature(); float hum = thermo.getHumidity(); char msg; formatEnvironment(temp, hum, msg, sizeof(msg)); Monitor.println(msg); delay(2000); } void formatEnvironment(float temperature, float humidity, char* buffer, size_t size) { snprintf(buffer, size, "T: %.2fC H: %.2f%%", temperature, humidity); }
Die Daten des Sensors (Temperatur und rel. Luftfeuchtigkeit) lassen wir im Seriellen Monitor ausgeben.
Das manche Werte hintereinander geschrieben werden lassen wir erstmal so denn später werden wir die Daten an die MPU senden und dort weiterverarbeiten.
Damit haben wir den ersten Meilenstein erreicht, die Daten vom Sensor wurden erfolgreich ausgelesen. Wenn wir die Daten jedoch noch visualisieren möchten, dann benötigen wir sowas wie den seriellen Plotter in der Arduino IDE.
visualisieren der Sensordaten aus dem Arduino App Lab im seriellen Plotter
Im Arduino App Lab gibt es sowas jedoch nicht, jedoch kann man die Arduino IDE parallel dazu öffnen und somit die Daten abgreifen und anzeigen.
Wir müssen dazu nur die Daten in einem bestimmten format absenden, jeder Sensorwert muss ein Label gefolgt von einem Doppelpunkt haben, anschließend wird der Sensorwert ausgegeben.
Quellcode - formatierte Ausgabe von Sensordaten für den seriellen Plotter der Arduino IDE #include #include "Arduino_RouterBridge.h" ModulinoThermo thermo; void setup(){ Monitor.begin(); Modulino.begin(); thermo.begin(); } void loop(){ float temp = thermo.getTemperature(); float hum = thermo.getHumidity(); char msg; formatEnvironment(temp, hum, msg, sizeof(msg)); Monitor.print(msg); delay(2000); } void formatEnvironment(float temperature, float humidity, char* buffer, size_t size) { snprintf(buffer, size, "T:%.2frnH:%.2frn", temperature, humidity); }
Damit können wir die Daten nun im seriellen Plotter der Arduino IDE anzeigen lassen.
Übergeben von Daten aus dem Mikrocontroller an das Linux-System
Bis hierhin haben wir den Modulino Thermo erfolgreich über die MCU ausgelesen und die Werte im Monitor ausgegeben.
Doch jetzt kommt der spannende Teil.
👉 Die Daten sollen das MCU-System verlassen. 👉 Sie sollen im Linux-System weiterverarbeitet werden.
Und genau dafür gibt es beim Arduino UNO Q eine integrierte Lösung:
Die RouterBridge
Die Bibliothek Arduino_RouterBridge ermöglicht die direkte Kommunikation zwischen der MCU und dem Linux-System.
Im einfachsten Fall bedeutet das: Die MCU sendet Daten – Linux empfängt sie.
Man kann sich das wie eine interne serielle Verbindung vorstellen, nur deutlich strukturierter und leistungsfähiger.
Minimalbeispiel: Daten von der MCU nach Linux senden
Erweitern wir unseren Sketch um eine einfache Übertragung:
#include #include ModulinoThermo thermo; void setup(){ Bridge.begin(); Monitor.begin(); Modulino.begin(); thermo.begin(); } void loop(){ float temp = thermo.getTemperature(); float hum = thermo.getHumidity(); char msg; formatEnvironment(temp, hum, msg, sizeof(msg)); Monitor.print(msg); Bridge.notify("measurement", temp, hum); delay(2000); } void formatEnvironment(float temperature, float humidity, char* buffer, size_t size) { snprintf(buffer, size, "T:%.2frnH:%.2frn", temperature, humidity); }
Hier passiert Folgendes:
- notify() sendet ein Ereignis an das Linux-System - Es wird kein Rückgabewert erwartet - Die Ausführung ist sofort abgeschlossen (non-blocking)
Damit verlassen unsere Sensordaten erstmals die MCU-Welt.
Linux-Seite: Messwerte in main.py empfangen
Im Arduino App Lab existiert die Datei main.py bereits automatisch. Sie ist der Einstiegspunkt für den Linux-Teil deiner Anwendung.
Wir ergänzen dort nun den Code, um die von der MCU gesendeten Messwerte zu empfangen.
import time from arduino.app_utils import * print("Arduino UNO Q - Temperatur & rel. Luftfeuchtigkeit vom Modulino Thermo") def loop(): # Der user_loop läuft dauerhaft, # die Bridge verarbeitet eingehende Events im Hintergrund. time.sleep(10) def on_measurement_received(temp: float, hum: float): print("Temperatur:", round(temp, 2), "°C") print("rel. Luftfeuchtigkeit:", round(hum, 2), "%") # Event "measurement" mit unserer Callback-Funktion verknüpfen Bridge.provide("measurement", on_measurement_received) # App starten App.run(user_loop=loop) Was passiert hier genau? - Die MCU sendet: Bridge.notify("measurement", temperature, humidity); - Der Linux-Router empfängt das Event. - Die Bridge ruft automatisch: on_measurement_received(temp, hum) auf. - Die Werte werden in der Linux-Konsole ausgegeben.