Der Umstieg auf ein RTOS auf dem RP2040

 (blog.brixit.nl)
1 Punkte von GN⁺ 2024-07-07 | 1 Kommentare | Auf WhatsApp teilen

Der Umstieg auf ein RTOS: Erfahrungen auf dem RP2040

Martijn Braam

  • Ein Artikel von Martijn Braam, der an Computerprojekten arbeitet
  • Arbeitet an mehreren Mikrocontroller-Projekten
  • Nutzt hauptsächlich Raspberry Pi Pico-Boards und hat damit gute Entwicklungserfahrungen gemacht

Projektüberblick

  • Bau eines Hardware-Controllers zur Steuerung von Videoequipment
  • Steuerung von PTZ-Kameras und Video-Switching-Geräten
  • Da der bestehende Controller eine schlechte Leistung bot, war ein neues Panel erforderlich

Hardware-Design

  • Enthält 9 RGB-Tasten, einen analogen Joystick und ein Display
  • Verwendet RS-485- und Ethernet-Kommunikationsmodule
  • Nach mehreren Hardware-Überarbeitungen wurde die Funktionalität vollständig umgesetzt

Anfängliche Software

  • Begann als cmake-Projekt mit dem pico-sdk
  • Der zweite Core wurde dem Wiznet-Modul zugewiesen, der erste Core übernahm die Benutzeroberflächen-I/O
  • Die Komplexität nahm zu, da mehrere Aufgaben gleichzeitig verarbeitet werden mussten

FreeRTOS

  • Mit FreeRTOS werden mehrere Aufgaben parallel verarbeitet
  • Es wurden verschiedene Tasks erstellt: Tasten, LEDs, Netzwerk, DHCP, mDNS, ATEM, VISCA
  • Probleme mit FreeRTOS: Bei der Verwendung von printf friert das System ein, außerdem fehlt Hardware-Abstraktion

Apache NuttX

  • Bietet eine Umgebung ähnlich zu Unix-Systemen
  • Nach der Ersteinrichtung steht eine echte Shell zur Verfügung
  • Hardware kann über das menuconfig/Kconfig-System konfiguriert werden
  • Aufgrund eines Problems bei der i2c-Bus-Konfiguration funktionieren die Grundfunktionen nicht
  • Dateisystempfade und eine Shell werden nicht benötigt

Zephyr

  • Bietet Python-Utilities für die Projektkonfiguration
  • Erfordert das Herunterladen eines 5-GB-großen git-Repositorys
  • Verlangt die Installation des Zephyr SDK, wobei auch eine vorhandene ARM-Toolchain genutzt werden kann
  • Die Unterstützung für Raspberry Pi Pico ist unzureichend, daher wurde versucht, andere Boards zu verwenden
  • Auch nach dem Beheben von Build-Fehlern und Warnungen funktionierte es nicht

Fazit

  • Mit FreeRTOS konnten einige Anwendungen erfolgreich gebaut werden
  • Eine alternative Implementierung für printf ist erforderlich
  • Es wird weiter mit FreeRTOS gearbeitet, um die gewünschten Funktionen umzusetzen

Zusammenfassung von GN⁺

  • Dieser Artikel behandelt den Umstieg auf ein RTOS in einem Mikrocontroller-Projekt
  • Verglichen werden die Vor- und Nachteile von FreeRTOS, Apache NuttX und Zephyr
  • Das Fazit lautet, dass FreeRTOS die am besten geeignete Wahl ist
  • Hilft dabei, die verschiedenen Faktoren zu verstehen, die bei der Auswahl eines RTOS zu berücksichtigen sind
  • Ähnliche Projekte mit vergleichbarer Funktionalität gibt es mit FreeRTOS und Zephyr

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-07-07
Hacker-News-Kommentar

  • Dieser Autor scheint zu erwarten, dass ein RTOS genauso funktioniert wie die Arduino-Umgebung

    • Viele Arduino-Systeme nutzen mbed oder FreeRTOS
    • Zephyr ist einfach zu verwenden und unterstützt auch den Pi Pico

  • Kurze RTOS-Zusammenfassung:

    • FreeRTOS: Wird von den meisten SoCs/Geräten unterstützt, aber die Treiber unterscheiden sich je nach SoC/Gerät
    • Zephyr: Unterstützt echte Hardware-Abstraktion und die meisten SoCs
    • NuttX: Die Unterstützung ist nicht besonders gut, aber wenn es läuft, ist es sehr cool

  • Das systemweite Installieren einer Toolchain nach traditioneller UNIX-Art ist schmerzhaft

    • Python als Werkzeug zu verwenden verursacht Versionsprobleme
    • Werkzeuge sollten statisch gelinkte Binärdateien sein

  • PlatformIO geht in die richtige Richtung

    • Es sollte Toolchain, SDK, Bibliotheken und Projektkonfiguration verwalten
    • Builds sollten überall reproduzierbar sein

  • Ich stelle ein RP2040-Projekt gerade auf Rust und Embassy um

    • Rust ist schwer, bis man sich daran gewöhnt hat, aber lohnend

  • Zephyr unterstützt den Pi Pico zu 100 %

    • Ich frage mich, ob die Dokumentation nicht geprüft wurde

  • ThreadX ist Open Source

  • Ich würde Hubris gern in einem echten Projekt einsetzen

    • Es bedeutet zwar mehr Schmerz mit C, ist aber Erlang/Elixir ähnlich

  • Ich denke, microPython ist der einfachere Weg

    • Kooperatives Multitasking auf Basis von async/await funktioniert gut

  • Ich habe einen einfachen Green-Thread-Timer selbst gebaut

    • Er unterstützt keine echte Prozessverwaltung, kann aber verschiedene Sensoren abfragen und Signale verarbeiten

  • FreeRTOS ist de facto der Industriestandard

  • Rust RTIC unterstützt rp2040 und ist sehr leichtgewichtig