So richten Sie EC-Master auf dem Qualcomm Dragonwing™ IQ-9075-Evaluierungskit ein
Das Qualcomm Dragonwing IQ-9075 EVK ist eine leistungsstarke Edge-AI-Plattform auf Basis des QCS9075-SoC. In Kombination mit dem acontis EC-Master und einem Echtzeit-Linux-Kernel wird es zu einem leistungsfähigen EtherCAT-MainDevice-Controller, der sich für Anwendungen in der Robotik und der industriellen Automatisierung eignet.
Diese Anleitung behandelt die komplette Einrichtung, vom Erstellen eines Echtzeit-Yocto-Images über das Laden von atemsys bis hin zur Optimierung von Linux für deterministische EtherCAT-Kommunikation.
Installation von Linux und EC-Master
Schritt 1: Einrichten des Host Computers
Führen Sie die folgenden Befehle aus, um Ihren Ubuntu-Build-Host vorzubereiten:
sudo apt update
sudo apt install build-essential chrpath cpio debianutils diffstat \
file gawk gcc git iputils-ping libacl1 locales python3 python3-git \
python3-jinja2 python3-pexpect python3-pip python3-subunit socat \
texinfo unzip wget xz-utils zstd
sudo apt install pipx
# Restart your shell session after running this command to ensure path changes take effect
pipx ensurepath
# The kas version is expected to be 4.8 or higher
pipx install "kas>=4.8"
Schritt 2: Das Qualcomm Yocto-Projekt herunterladen
Initialisieren Sie den Yocto-Arbeitsbereich mit dem Echtzeit-Linux-Manifest:
mkdir <WORKSPACE_DIR>
cd <WORKSPACE_DIR>
git clone https://github.com/qualcomm-linux/meta-qcom -b qli-2.0
kas shell meta-qcom/ci/iq-9075-evk.yml:meta-qcom/ci/linux-qcom-rt-6.18.yml:meta-qcom/ci/qcom-distro-kvm.yml
Schritt 3: Parametrierung Echtzeit-Kernel
Zwei wichtige Kernel-Boot-Parameter tragen dazu bei, unerwünschte Latenzen zu vermeiden, die durch das Energiemanagement verursacht werden:
- cpuidle.off=1 — Deaktiviert die Verwaltung des CPU-Leerlaufzustands vollständig und verhindert so, dass die CPU zwischen den Aufgaben in einen Ruhezustand wechselt. Dadurch wird die Latenz beim Aufwachen beseitigt, die bei zyklischen Echtzeitaufgaben zu Schwankungen führen kann.
- cpufreq.off=1 — Deaktiviert die dynamische CPU-Taktfrequenzanpassung. Die CPU läuft mit einer festen (in der Regel maximalen) Taktfrequenz, wodurch die mit Taktwechseln verbundenen Latenzspitzen vermieden werden.
Diese Parameter sind für die Erzielung konsistenter Zykluszeiten in EtherCAT-Anwendungen unerlässlich.
In einem Multi-Core-System können Sie einen oder mehrere CPU-Kerne ausschließlich für Echtzeitaufgaben wie die EtherCAT-Job-Task reservieren, wodurch verhindert wird, dass der Linux-Scheduler allgemeine Prozesse auf diesen Kernen ausführt.
Die entsprechenden Kernel-Parameter lauten:
- isolcpus=7 — Entfernt CPU 7 aus der Lastverteilung des Allzweck-Schedulers. Der Kernel wird keine regulären Prozesse auf dieser CPU ausführen, es sei denn, er wird ausdrücklich dazu angewiesen.
- irqaffinity=0-6 — Beschränkt die Verarbeitung von Hardware-Interrupts auf die CPUs 0–6. CPU 7 bleibt frei von Interrupt-Last, wodurch sich ihre Echtzeit-Reaktionsfähigkeit weiter verbessert.
Das Ergebnis: Auf CPU 7 wird ausschließlich Ihre EtherCAT Anwendung ausgeführt, wobei Störungen durch den Rest des Systems auf ein Minimum reduziert werden. Das Qualcomm Yocto Real-Time-Linux-Rezept isoliert die CPU 7. Qualcomm stellt einen Leitfaden mit dem Titel Get started with performance tuning and optimization zur Verfügung, der zusätzliche Schritte zur Optimierung des Kernels enthält. Um allgemeine Kernel-Parameter hinzuzufügen, bearbeiten Sie die Konfigurationsdatei:
<WORKSPACE_DIR>/meta-qcom/conf/machine/iq-9075-evk.conf
Um die CPU-Kernisolierung zu konfigurieren, bearbeiten Sie Ihre Kas-Konfigurationsdatei:
<WORKSPACE_DIR>/meta-qcom/ci/base.yml
Schritt 4: Kernelmodul atemsys und Netzwerktreiber Patches hinzufügen
Um sicherzustellen, dass der acontis Real-time Ethernet Treiber ordnungsgemäß funktioniert, sind Änderungen am Device Tree und an der SMMU erforderlich. Es wird ein Patch benötigt, damit Yocto die aktualisierten Quellcodes kompilieren kann. Legen Sie die folgende Patch-Datei im Verzeichnis „configs“ des Kernel-Recipes ab:
<WORKSPACE_DIR>/meta-qcom/recipes-kernel/linux/linux-qcom-6.18
Required patch:
0002-arm64-dts-qcom-add-atemsys-support-for-lemans-and-SM.patch
Register the patches in the .inc file under SRC_URI:
<WORKSPACE_DIR>/meta-qcom/recipes-kernel/linux/linux-qcom_6.18.bb
file://0002-arm64-dts-qcom-add-atemsys-support-for-lemans-and-SM.patch \
Schritt 5: Erstellen Sie das Echtzeit-Linux-Image
Das Yocto-Projekt ist nun bereit, ein Echtzeit-Linux-Image mit den erforderlichen Änderungen zu erstellen. Führen Sie den folgenden Befehl aus, um den Build zu starten:
kas build meta-qcom/ci/iq-9075-evk.yml:meta-qcom/ci/linux-qcom-rt-6.18.yml:meta-qcom/ci/qcom-distro-kvm.yml --target qcom-multimedia-image
Nachdem der Build abgeschlossen ist, befindet sich das Image dort:
build/tmp/deploy/iq-9075-evk/qcom-multimedia-image-iq-9075-evk.rootfs-xxx.qcomflash/
Schritt 6: System für Flashing vorbereiten
Schließen Sie ein USB-C-Kabel vom Host-Computer an den Flash-Anschluss der Platine an. Über dieses Kabel werden die Firmware-Images übertragen, die QDL während des Flash-Vorgangs auf das Gerät überträgt. Stellen Sie den Schalter Pin 3 auf „ON“, um den QDL-Modus (Qualcomm Download) zu aktivieren, sodass die Platine statt mit ihrem normalen Linux-Image mit dem Firehose-Loader bootet. Schalten Sie die Platine aus und wieder ein, damit sie neu startet und mit der neuen Schalterstellung im QDL-Modus hochfährt.
Verify QDL mode on host:
lsusb
# Expected: Qualcomm QDL mode
Schritt 7: Laden Sie das QDL-Flashing-Tool herunter
Laden Sie den Qualcomm Device Loader (QDL) für Linux x64 herunter:
wget https://softwarecenter.qualcomm.com/api/download/software/tools/Qualcomm_Device_Loader/Linux/Debian/latest.zip -O qdl.zip
unzip qdl.zip
chmod +x QDL_2.7_Linux_x64/qdl
export PATH="$PATH:$PWD/QDL/QDL_2.7_Linux_x64"
Stellen Sie sicher, dass die qdl-Software bei folgender Stelle registriert ist:
qdl –version
Anschließend aktualisieren Sie auch die udev-Regeln mit dem folgenden Befehl:
echo 'SUBSYSTEMS=="usb", ATTRS{idVendor}=="05c6", ATTRS{idProduct}=="9008", MODE="0666", GROUP="plugdev"' | sudo tee /etc/udev/rules.d/51-qcom-usb.rules
sudo systemctl restart udev
Schritt 8: Flash Provisioning UFS
Flashen Sie zunächst die UFS-Provisioning-Daten; dies muss nur einmal pro Board durchgeführt werden:
mkdir <provision_download_path>
cd <provision_download_path>
wget https://artifacts.codelinaro.org/artifactory/codelinaro-le/Qualcomm_Linux/QCS9100/provision.zip
unzip provision.zip -d provision
qdl --storage ufs prog_firehose_ddr.elf provision_1_2.xml
Schritt 9: Flash SAIL (NOR)
cd build/tmp/deploy/iq-9075-evk/qcom-multimedia-image-iq-9075-evk.rootfs-xxx.qcomflash/sail_nor
qdl --storage spinor prog_firehose_ddr.elf rawprogram0.xml patch0.xml
Schritt 10: Flash CDT
mkdir <cdt_download_path>
cd <cdt_download_path>
wget https://artifacts.codelinaro.org/ui/native/codelinaro-le/Qualcomm_Linux/QCS9100/cdt/qcs9075-iq-9075-evk.zip
unzip <downloaded_zip_file>
<qdl_download_path>/qdl --storage ufs prog_firehose_ddr.elf rawprogram3.xml patch3.xml
Schritt 11: Flash Linux Image
cd build/tmp/deploy/iq-9075-evk/qcom-multimedia-image-iq-9075-evk.rootfs-xxx.qcomflash/
sudo systemctl stop ModemManager
qdl --storage ufs prog_firehose_ddr.elf rawprogram*.xml patch*.xml
Der Flash-Vorgang ist abgeschlossen, wenn auf dem Terminal folgende Meldung erscheint: „Partition 1 ist nun bootfähig.“
Stellen Sie den Schalter an Pin 3 wieder auf die Position „OFF“, damit das Board normal bootet und nicht erneut in den Download-Modus wechselt. Schließen Sie ein Micro-USB-Kabel für den Zugriff auf die serielle Konsole an. Dieser Schritt ist optional, stellt jedoch die einfachste Möglichkeit dar, den Bootvorgang des Systems zu beobachten, weshalb wir ihn empfehlen.
Schalten Sie die Platine aus und wieder ein; die Bootsequenz sollte nun auf der seriellen Konsole angezeigt werden.
Schritt 12: Kernelmodul atemsys erzeugen und laden
Um einen direkten Hardwarezugriff zwischen dem Ethernet-Treiber und dem Ethernet-MAC zu ermöglichen, muss das atemsys-Kernelmodul kompiliert und geladen werden. Laden Sie atemsys von GitHub herunter: github.com/acontis/atemsys.
Cross compile it:
cd atemsys
export PATH=<WORKSPACE_DIR>/build/tmp/work/iq_9075_evk-qcom-linux/linux-qcom-rt/6.18.30/recipe-sysroot-native/usr/bin/aarch64-qcom-linux/:$PATH
make -C . ARCH=arm64 CC=aarch64-qcom-linux-gcc LD=aarch64-qcom-linux-ld.bfd AR=aarch64-qcom-linux-ar KERNELDIR=<WORKSPACE_DIR>/build/tmp/work/iq_9075_evk-qcom-linux/linux-qcom-rt/6.18.30/build modules
The module is loaded using the following command:
modprobe of_mdio
sudo insmod atemsys.ko
Diese Konfiguration ermöglicht dem Echtzeit-Ethernet-Treiber von acontis den direkten Zugriff auf die Hardware und macht überflüssige Software-Schichten überflüssig. Dadurch werden sowohl das Echtzeitverhalten als auch die CPU-Effizienz deutlich verbessert.
Schritt 13: EtherCAT auf dem IQ-9075 ausführen
Sobald die gesamte Einrichtung abgeschlossen ist, ist das System bereit, EtherCAT mit maximaler Leistung auszuführen. Um die Demo zu starten, laden Sie zunächst „atemsys“ wie in Schritt 12 beschrieben. Danach kann die Demo mit folgendem Befehl gestartet werden:
./EcMasterDemo -dw3504 1 1 iq-9075 -v 3 -perf -a 7 -sp -t 0 -f "eni64-DC_busshift_1000us_1000bytes_pdo.xml"
Es wird folgende Ausgabe angezeigt:
0000000000: EcMasterDemo V3.3.2.01 for Linux_aarch64 Copyright acontis technologies GmbH @ 2026
0000000000: Full command line: -dw3504 1 1 iq-9075 -v 3 -perf -a 7 -sp -t 0 -f "eni64-DC_busshift_1000us_1000bytes_pdo.xml"
0000000001: EC-Master V3.3.2.01 (Unrestricted) (Jul 14 2026 19:09:33) for Linux_aarch64 Copyright acontis technologies GmbH @ 2026
0000000001: emllDW3504(0x00000001): V3.3.2.01 (Unrestricted) (Jul 14 2026 19:09:55) for Linux_aarch64 Copyright acontis technologies GmbH @ 2026
0000001796: Bus scan successful - 64 slaves found
0000004709: Master state changed from <UNKNOWN> to <INIT>
0000005613: Master state changed from <INIT> to <PREOP>
0000008610: DCM in sync (cur/avg/max) [ns]: -5665/ -2195/ -19452
0000008610: DC slaves "in-sync" - Deviation: 0x0
0000008651: Master state changed from <PREOP> to <SAFEOP>
0000008671: Master state changed from <SAFEOP> to <OP>
Leistungsmessung
Einrichtung des Testnetzwerks
Der Testaufbau besteht aus einem EtherCAT-Netzwerk mit insgesamt 64 SubDevices. Diese SubDevices stammen von Beckhoff und Omron. Die SubDevices sind entweder über 100Base-TX (RJ45-Stecker) oder LVDS (E-Bus) angeschlossen. In der Standardkonfiguration werden zyklisch insgesamt 151 Byte Eingangsdaten gelesen und 46 Byte Ausgangsdaten geschrieben. Zudem wird eine präzise Synchronisation mithilfe von Distributed Clocks (DC) erreicht. Der zyklische Frame hat eine Gesamtlänge von 329 Byte, einschließlich des EtherCAT-Protokolls. Die Zykluszeit wurde auf eine Millisekunde festgelegt.
Netzwerk Timing
Das Netzwerk Timing muss auf Anwendungsebene implementiert werden, da die EC-Master-Bibliothek keine internen Tasks enthält. Die Vorteile dieses Ansatzes sind:
- Es treten keine Synchronisationsprobleme zwischen der Anwendung und der EC-Master-Bibliothek auf.
- Konsistente Prozessdaten ohne Verwendung von Sperren.
- Es sind verschiedene, anwendungsabhängige Netzwerk-Timings möglich.
- Einfach zu integrieren.
Für die meisten Anwendungen ist die Standard-Netzwerk-Timing passend. Der Zyklus beginnt mit der Verarbeitung aller empfangenen Frames. Die Frames werden im DMA-Speicher des Netzwerktreibers abgelegt. Zunächst werden die Daten auf ihre Richtigkeit überprüft, anschließend werden die Eingangsdaten aktualisiert. In der Anwendung werden dann die Ausgangsdaten berechnet und die Übertragung des zyklischen Frames eingeleitet. In der EC-Master-Verwaltung werden zahlreiche Zustandsmaschinen ausgeführt, um bei Bedarf weitere Aktionen auszulösen.
In der Beispielanwendung EcMasterDemo ist die Standard-Netzwerk-Timing implementiert. Alle Beispielprogramme können zudem die für jede EC-Master-Funktion (Job) benötigte Verarbeitungszeit ermitteln und diese in regelmäßigen Abständen melden. Für das oben beschriebene Netzwerk beträgt die durchschnittliche EC-Master-Verarbeitungszeit lediglich 15,1 µs.
PerfMsmt 'Cycle Time ' (min/avg/max) [usec]: 991.9/1000.0/1009.0
PerfMsmt 'Task Duration (JOB_Total + App)' (min/avg/max) [usec]: 13.3/ 18.0/ 40.1
PerfMsmt 'JOB_Total ' (min/avg/max) [usec]: 10.7/ 15.1/ 30.1
PerfMsmt 'JOB_ProcessAllRxFrames Duration' (min/avg/max) [usec]: 5.2/ 7.3/ 18.9
PerfMsmt 'JOB_SendAllCycFrames Duration ' (min/avg/max) [usec]: 3.2/ 4.4/ 11.0
PerfMsmt 'JOB_MasterTimer Duration ' (min/avg/max) [usec]: 1.7/ 2.4/ 10.0
PerfMsmt 'JOB_SendAcycFrames Duration ' (min/avg/max) [usec]: 0.1/ 1.1/ 10.1
PerfMsmt 'myAppWorkPd ' (min/avg/max) [usec]: 0.1/ 0.1/ 0.9
Messung der CPU-Auslastung und der Round-Trip-Zeit des EC-Master
Das flexible EC-Master Job-Konzept ermöglicht auch ein alternatives Netzwerk-Timing. Der Zyklus beginnt mit der Übertragung des zyklischen Frames, der die Prozessdaten enthält. Nachdem der Frame das Netzwerk durchlaufen hat, erfolgt die Verarbeitung, die in der Regel durch einen Interrupt ausgelöst wird. Darauf folgen die Anwendungsphase und die EC-Master-Verwaltung. Dieses Timing kann auch ohne Interrupt genutzt werden. In diesem Fall führt die Anwendung einfach eine Abfrage durch, bis der zyklische Frame wieder empfangen wird.
Das alternative Netzwerk-Timing wird in der Beispielanwendung EcMasterDemoSyncSm implementiert. Neben der Rechenzeit, die für die einzelnen EC-Master-Funktionen (Jobs) benötigt wird, wird auch die Round-Trip-Zeit ermittelt. Diese Zeit setzt sich aus den Verarbeitungszeiten für Senden und Empfangen sowie der Zeit zusammen, die der Frame benötigt, um das Netzwerk zu durchlaufen. Für das oben beschriebene Netzwerk beträgt die durchschnittliche Round-Trip-Zeit etwa 104,5 µs.
PerfMsmt 'Cycle Time ' (min/avg/max) [us]: 997.2/1000.0/1002.9
PerfMsmt 'Task Duration (JOB_Total + App)' (min/avg/max) [us]: 109.5/ 113.2/ 119.7
PerfMsmt 'JOB_Total ' (min/avg/max) [us]: 8.2/ 10.7/ 16.4
PerfMsmt 'JOB_ProcessAllRxFrames Duration' (min/avg/max) [us]: 0.6/ 0.7/ 5.2
PerfMsmt 'JOB_SendAllCycFrames Duration ' (min/avg/max) [us]: 2.7/ 4.1/ 5.2
PerfMsmt 'JOB_MasterTimer Duration ' (min/avg/max) [us]: 1.7/ 2.2/ 4.9
PerfMsmt 'JOB_SendAcycFrames Duration ' (min/avg/max) [us]: 0.1/ 1.0/ 5.5
PerfMsmt 'myAppWorkPd ' (min/avg/max) [us]: 0.1/ 0.1/ 0.3
PerfMsmt 'RoundTrip (TX+RX) ' (min/avg/max) [us]: 102.8/ 104.5/ 106.8
Bestimmung der Netzwerkauslastung
Neben der CPU-Auslastung sollten Sie auch die Netzwerkauslastung berücksichtigen. Die Bandbreite von EtherCAT beträgt 100 Mbit, was 12.500 KByte/s oder 12.500 Byte/ms entspricht. Dabei handelt es sich um die theoretisch mögliche Datenrate. Es ist jedoch zu beachten, dass neben dem Ethernet-Datenframe (IEEE 802.1) weitere Daten (Start-Delimiter, Präambel, Frame-Anfang, End-Delimiter) sowie die Interpacket-Lücke die Bandbreite etwas verringern. In der Praxis lassen sich deshalb maximal 12.000 Bytes/ms erreichen.
Die Berechnung der minimalen Netzwerklast, die durch zyklische Prozessdaten verursacht wird, ist relativ einfach. Bei einer Zykluszeit von einer Millisekunde kann die in EC-Engineer angezeigte Frame-Größe durch 12.000 geteilt werden. Für die oben genannte Konfiguration ergibt sich daraus eine minimale Last von 325/12.000 = ca. 2,7 %.
Die tatsächliche Auslastung ist jedoch höher, da zusätzlich zu den zyklischen Frames auch eine azyklische Kommunikation zwischen dem EC-Master und den SubDevices erforderlich ist. Da die azyklische Kommunikation sehr umfangreich werden kann, muss sie streng begrenzt werden. Die maximale Grenze kann über die EC-Master-API-Funktion emInitMaster() festgelegt werden.
Die durchschnittliche und die maximale Netzauslastung lassen sich ebenfalls bequem im EC-Engineer Diagnostic Tool einsehen. Die angezeigten Daten werden vom EC-Master fortlaufend berechnet.
Erhöhung der Netzwerklast durch Hinzufügen weiterer zyklischer Prozessdaten
Der Testaufbau mit 64 SubDevices weist ein relativ kleines Prozessabbild auf, mit 151 Byte Eingabedaten und 46 Byte Ausgabedaten. Ziel ist es nun zu untersuchen, wie sich die Größe der Prozessdaten sowohl auf die Netzwerkauslastung als auch auf die CPU-Auslastung auswirkt. Dazu werden mithilfe von EC-Engineer zusätzliche Variablen im Prozessabbild definiert. Diese werden ebenfalls zyklisch über das EtherCAT-Netzwerk übertragen. Bei Bedarf werden hierfür automatisch mehrere zyklische Frames generiert, die dann in die ENI-Datei aufgenommen werden.
Anzahl, Größe und Inhalt der zyklischen Frames werden in EC-Engineer übersichtlich angezeigt:
Messreihe
Ausgehend von der Standardkonfiguration wird die Größe der Prozessdaten schrittweise auf maximal 8064 Byte erhöht. Der EC-Master ermittelt die durchschnittliche Netzwerklast, und die Beispielanwendungen messen die Ausführungszeiten der EC-Master-Jobs sowie die Round-Trip-Zeit. Die Netzwerklast wird auf der Grundlage eines Maximalwerts von 12000 Byte/ms berechnet. Die Netzwerkzykluszeit beträgt 1 ms.
|
Process data size [Bytes] |
Num of cyclic frames |
Cyclic frame size |
Avg |
Avg |
Avg |
Avg. EC-Master |
Avg. EC-Master |
|
197 |
1 |
329 |
329 |
2.8 |
105 |
12.3 |
1.2 |
|
1024 |
1 |
1170 |
1170 |
9.8 |
209 |
14.0 |
1.4 |
|
2048 |
2 |
2214 |
2214 |
18.5 |
288 |
18.1 |
1.8 |
|
4096 |
3 |
4306 |
4306 |
35.8 |
470 |
25.2 |
2.5 |
|
8064 |
6 |
8370 |
8370 |
68.9 |
795 |
47.4 |
4.7 |
Fazit
EC-Master lässt sich in nur wenigen Stunden problemlos auf dem Qualcomm Dragonwing IQ-9075 Evaluation Kit installieren. Durch die Zuweisung einer eigenen CPU für die MainDevice-Anwendung wird eine noch bessere Echtzeitleistung erzielt. Dies führt zu einer stabileren Zykluszeit und damit zu weniger Jitter im EtherCAT-Netzwerk.
Der Betrieb eines EtherCAT-Netzwerks mit 64 SubDevices – von denen einige auch DC nutzen – belastet die sehr leistungsstarke Dragonwing IQ-9075-CPU nur äußerst geringfügig. Selbst bei einem deutlichen Anstieg der zyklischen Prozessdaten bleibt die durch den EC-Master verursachte Auslastung unter 5 %. Daher sollte bei der Auslegung eines Systems der Schwerpunkt in erster Linie auf der Netzwerkauslastung liegen. Allerdings werden auch hier selten Grenzen erreicht, da bei einer typischen Zykluszeit von einer Millisekunde etwa 12.000 Byte zwischen der Steuerung (MainDevice) und den Peripheriegeräten (SubDevices) übertragen werden können.