Ich glaube, ich konnte die Vorteile des Schreibens von Gerätetreibern in eingebetteten Systemen für bestimmte Geräte, wie z. B. GPIO, nicht vollständig verstehen, wenn es für dieselbe Aufgabe alternative Möglichkeiten gibt.
Der Zugriff auf die GPIOs erfolgt über Sysfs und den Gerätebaum.
- Schreiben Sie ein neues Gerätebaum-Overlay und aktivieren Sie es
- Gehen Sie zu /sys/class/gpio
- Exportieren Sie den erforderlichen Pin und beginnen Sie mit seiner Verwendung (über einfache Shell-Aufrufe oder innerhalb der C/C++-App).
Schreiben Sie Ihren eigenen Treiber.
- Coden Sie die tatsächlichen Funktionalitäten.
- Stellen Sie den Treiber einem Knoten (wie /dev/tty) im Benutzerbereich zur Verfügung.
- Schreiben Sie einen weiteren C/C++-Code, um auf den Treiber zuzugreifen (der Zugriff ist auch über einfache Shell-Aufrufe möglich)
- Wenn Sie neue Funktionen benötigen, ändern Sie zuerst den Treiber und dann Ihren Code. (Warum?)
Verwenden Sie direkt /dev/mem;
- Schließen Sie mman.h ein und verwenden Sie das Objekt /dev/mem, um den GPIO-Status festzulegen oder abzurufen.
Also,
- 1 -> wird veraltet und langsam sein. (Ok, absolut vorteilhaft für schnelles Prototyping)
- 2 -> Wie ist das schneller als 1? Der erste ist doch auch ein anderer GPIO-Treiber, oder?
- 3 -> Ist das nicht der beste und schnellste Weg?
Ich habe oben mehrere Fragen gestellt, aber hier ist meine wichtigste Frage: Warum sollte ich nicht direkt die dritte Lösung wählen?
Antwort1
Der Vorteil von Option 2 besteht darin, dass Sie die Anfrage an einer einzigen Stelle validieren können. Angenommen, Sie können bei einer Spülmaschine sicherstellen, dass der Türsensor anzeigt, dass die Tür geschlossen ist, bevor Sie das Wasser aufdrehen. Natürlich können Sie den Leuten sagen, dass sie den Türstatus prüfen sollen, bevor sie das Wasser aufdrehen, aber werden sie das auch alle tun?
Ein möglicher Nachteil der Optionen 1 und 3 sind die Berechtigungen. Es hängt davon ab, wie ausgefeilt das eingebettete Gerät ist, aber Sie möchten vielleicht, dass verschiedene Benutzer-IDs verschiedene Dinge tun. Beispielsweise könnte ein Heimrouter eine andere UID haben, die einen HTTP-Server betreibt, der die Web-Benutzeroberfläche ausführt, und einen anderen Daemon, der die LEDs auf der Vorderseite betreibt. Obwohl es für GPIO-Treiber möglich ist, eine feinkörnige Zugriffskontrolle zu haben, verfolgen die meisten einen Alles-oder-Nichts-Ansatz. Mit Option 2 können Sie auf feiner Ebene entscheiden, welche Benutzer auf welche Einrichtungen zugreifen können.
Der Nachteil von Option 2 besteht darin, dass sie komplizierter ist und normalerweise Code im Kernel erfordert.