The Industrial Raspberry Pi Forum

Hallo, ich habe mich extra hier angemeldet, da ich keine Aussage dazu finden konnte, ob Android Things auf dem RevPi 3 laufen würde. Hat der RevPi 3 im Grunde den gleichen Schaltplan wie ein normaler RasPi 3 und Android Things sollte darauf lauffähig sein? Hat das schonmal jemand probiert?
Und falls es funktioniert: welchen Aufwand würde es bedeuten, die Erweiterungsmodule unter Android Things zum Laufen zu bekommen, bzw.: werden die Erweiterungsmodule von einem Standard-Linux-Kernel erkannt oder benötigt man dazu spezielle Treiber von Kunbus?

Hallo JamJam,
lies einfach mal den Blog von Anfang an, um den grundsätzlichen Aufbau vom RevPi und seinen Interfaces zu verstehen. Hier im Forum können wir nicht immer wieder dieselben Erklärungen wiederholen. Aber ich fasse gerne mal die Antwort zusammen und versuche es knapp zu erklären:
Nein, mit Android Things wirst Du beim RevPi wenig Vergnügen haben. Das liegt daran, dass Android Things die Schnittstellen I2C, UART, SPI und GPIOs nutzt, um mit peripherie zu sprechen. Diese Schnittstellen sind für embedded Systeme interessant, bei denen in einem gemeinsamen Gehäuse embedded Steuerung wie Raspi zusammen mit Peripherie-ICs oder Sensorik verbaut werden. Der RevPi ist aber für industrielle Steuerungssysteme ausgelegt, bei denen oft viele Meter Leitungen zwischen Steuerung und Sensoren bzw. Aktoren vorzufinden sind und dies auchnoch in einer oft stark EMV-verseuchten Umgebung. In solchem Umfeld sind I2C, UART oder SPI und schon gar GPIOs nicht interessant - sie würden weder die gängigen Normen (EN61131-2 etc.) erfüllen, noch würden sie eine störungsfreie Signalübertragung gewährleisten.
Aus diesem Grunde sind diese Schnittstellen, über die das Computemodul im RevPi wie ein Raspi auch verfügt, nicht auf Steckverbindungen geführt. Statt dessen gibt es einen Systembus, über den Erweiterungsmodule zyklisch ihre Daten mti dem Zentralgerät ("Core") austauschen. Hard- und Software sind offen gelegt und theoretisch kann man so auch selber Treiber entwickeln, die in den HAL von Android Things eingebaut werden könnten. Natürlcih müsste man dann auch die zugehörigen APIs bereitstellen. Aber mri wäre nicht bekannt, dass Google ein SDK für den HAL bereitstellt. Es geht ja bei dieser ganzen Abstraktionsgeschichte gerade darum, dass User angesprochen werden sollen, die mit dem SDK auf einem hohen Abstraktionslevel programmieren sollen - und nicht solche Entwickler, die Treiber in betriebssysteme einbinden können.
Aber wer weiß, vielleicht wird es irgendwann auch ein Android Things für RevPi geben... oder eine Alternative,die noch besser ist???

Hallo Volker, danke für deine ausführliche Antwort! Prinzipiell geht es mir erstmal darum, wie aufwändig sich eine Portierung von Android Things auf den RevPi Core gestalten würde. Dass dann noch die Integration der Erweiterungsmodule über den Kunbus-eigenen Systembus anstehen würde, ist natürlich noch eine ganz andere Geschichte. Wenn die RevPi-Linux-Treiber sich "ordentlich" in den Linux-HAL integrieren, bekommt man das prinzipiell auch auf Android portiert. Google stellt zwar keine "HAL-SDK" bereit, dennoch sollte der Kernel ansich dann auch im Android mit allen Schnittstellen arbeiten können. Inwiefern man dann von den Highlevel-Sprachen im Android Things auf die ganzen Schnittstellen der Revpi Erweiterungsmodule kommt steht noch auf einem ganz anderen Blatt. Interessant wär für den Anfang, zumindest die RevPi-DIO-Module über die Android-Things-GPIO-API ansteuern zu können...

Hallo JamJam,
noch mal von vorne: Android Things ist ein abstraction Laye für IoT mit embedded Systemen. IO ist dabei Kerngeschäft. Ohne IO kein IoT. Die Abstraktion der IOs für den Raspi wurde bei Android Things für UART, SPI, I2C udn GPIO vorgenommen. ALLE 4 Schnittstellen (also auch GPIO) stehen bei RevPi nicht für den Anschluss von Sensoren ode Aktoren zur Verfügung. Die DIO-Module haben rein gar nichts mti den GPIO eines Raspi zu tun. Es sind nicht einfach nur elektrisch umgeleitete GPIOs. Du kannst sie eher wie Speicherzellen im RAM sehen, die über PiControl mit Einsen und Nullen beschrieben werden können. Die einzigen IOs, die frei verwendet werden können und dirket über Linux eingebunden sind, sind die über USB udn Ethernet ansprechbaren IOs. Dadurch stehen zum Beispiel industrielle Sensoren, die mt Modbus etc. arbeiten zur Verfügung. Aber genau diese Art von IOs existieren für Android Things nicht, weil das System eben nicht für den industriellen Autometion Markt entwickelt wurde, sondern mehr die Smart Home udn Consumer Bereiche abdecken soll.

Hallo Volker, ich musste erstmal ne Weile drüber nachdenken, was du mir eigentlich sagen willst, ob wir aneinander vorbeireden oder ich die falschen Fragen stelle. Aktuell bin ich gar nicht an einer vollumfänglichen Portierung interessiert. RevPi-Core mit I/O-Modul würde für den Anfang vollkommen genügen. Vermutlich kennst du das Android Open Source Projekt nicht (früher hieß das mal "Platform Development Kit"). Sobald Android Things den Status "produktiv" erreicht hat, wird Google auch das unter AOSP anbieten. Das käme dann dem "HAL SDK" am nächsten, von dem du weiter oben gesprochen hattest. Prinzipiell könnte man also auch die RevPi-I/O-Module in der Android Things API erscheinen lassen (unter Android Things könnten diese dann bspw. als GPIOs mit aufgelistet werden, auch wenn sie elektrisch nicht direkt am Hauptprozesser hängen, sondern über "PiBridge" angesprochen werden...).

Hallo JamJam,
ichhabe das Gefühl, dass Du Dich noch nicht in die PiBridge Kommunikation eingelesen hast. Die Firmware auf den DIO Modulen ermöglicht nun mal keine andere Kommunikation als das PiBridge PÜrotokoll. Dies tausch zyklsich Daten zwischen PA und DIO aus. Es gibt keinen direkten Zugriff auf die elektrischen Aus- oder Eingänge, wie das bei GPIOs üblich ist. Es gibt lediglich ein PA, in welchem die Zustände der Ein- und Ausgänge zyklisch gespiegelt abgelegt sind. Jede Software kann sich dort bedienen, um IO Daten zu schreiben oder zu lesen. Dies geschieht über Linux Filezugriffe (open, seek, read/write, close) auf das PiControl device. Die Software muss dazu allerdings zyklsich pollen, weil es unter EN61131-3 keine Event basierte Verarbeitung gibt. Wenn Du dies irgendwie unter Android Things realisieren kannst, dann okay. Aber das geht eigentlich doch auch alles sehr einfach und ebenfalls stark abstrahiert mit Node Red oder schau Dir mal das Projekt von miprotek RevPiNodIO an, welches ebenfalls ein Absraktionslayer darstellt und auch bereits Events behandeln kann. Welchen Vorteil soll Android Things haben, wenn ich nur digitale IOs lesen und schalten kann, aber keine digitalen Sensoren und Aktoren über SPI, I2C, UART ansprechen kann?

Danke Volker, für deine Zeit du du hier investierst. Ich suche nach einer geeigneten Hardware (wie den RevPi), die als Hutschienengerät zur Anbindung von verschiedenen Protokollen im Smart-Home-Bereich geeignet ist. Aktuell sollen erstmal nur digitale Ein-/Ausgänge funktionieren (für den "einfachen" Start). Perspektivisch sollen dann ZigBee, Z-Wave usw. (über bspw. USB) angebunden werden können. Industriellen Standards muss das nicht genügen, es muss nur gut genug für den Schaltkasten bei Otto-Normal-Verbraucher sein.
AndroidThings hätte lediglich den Charme, dass man eine ausgereifte Softwareplattform mit mächtigen Hochsprachen und modernen Entwicklertools bekommt, sodass auch Hobby-Programmierer, die mal ne App für Android entwickelt haben, dafür Software schreiben könnten.
Alles, was speziell für den RevPi ist, könnte auch an der AndroidThings-API vorbei über eine eigene Bibliothek bereitgestellt werden. Gleiches gilt für den Zugriff auf USB-Geräte (ZigBee etc.), da stelle ich mir aber eher was gemeingültigeres vor, was nicht nur auf den RevPi zugeschnitten ist, sondern auf allen AndroidThings-Geräten funktionieren könnte...

Ah, jetzt verstehe ich schon eher, wohin die Reise gehen soll. Aber genau da würd ich mir an Deiner Stelle auch mal Node Red ansehen. Das ist extrem einfach und osger "Nicht-Programmierer" können sich damit einen Datenfluss bereitstellen.
Funktechnik wird es bei uns dann auch bald geben (hab hier im Forum schon mehrfach vom "RevPi Connect" Projekt geschrieben) und für die UV in Gebäuden wird der RevPi Compact sicher noch besser geeignet sein (niedriges Gehäuse und IOs schon gleich mit dem Core verbaut).
Generell ist der Anstz mit Android halt sehr "um die Ecke" für einen Raspi, weil der Raspi ja grade dafür entwickelt wurde, dass viele Menschen ihn ohne viel zu lernen programmieren können. Dafür wurde Python als Programmiersprache favorisiert und mit Scratch können sogar schon Grundschüler programmieren lernen. Raspi konnte durch diesen Ansatz tatsächlich die Ziele erfolgreich umsetzen, in GB die Zahlen der Infomatikstudenten zu erhöhen. Und nicht nur dort, sondern weltweit wurde durch den Raspi ein Informatikboom an den Unis ausgelöst. Inzwischen sind über 10 Mio Systeme draußen und ich schätze mal, dass das Potenzial an Androidprogrammierern nicht wesentlich höher liegen wird, als das Potenzial an Leuten die mit Python oder anderen Sprachen einen Raspi programmieren können. Die Ansätze, die Cloudcomputing und IoT Konzepte mit einbeziehen (Node Red oder Ubuntu Snap mit dem Appstore) sind erst kurz am Start aber es ist davon auszugehen, dass im Bereich von Steuerungen mit dem Raspi diese Systeme sicher nicht hinter Android Things zurückstehen werden, weil sie sehr offen sind und die "Raspi Gemeinde" genau wie die "Debian Gemeinde" eher eine sehr distanzierte Haltung gegenüber Großkonzernen wie Google haben. Aber man wird sehen...
An Deiner Stelle würde ich für dieses Projekt auch sehr gezielt auf dei Einbindung der Konfiguration des gesamtsystems schauen. Während bei Smartphones dies ja auch direkt in Android passiert, ist es bei einem offenen modularen System wie RevPi schwierig, die gesamte Logik der Konfiguration aller Bausteine in Android Things zu verlagern, da es ja noch N weitere Hardwaresysteme auf dem Markt gibt, die alle ebenso einfach mti Android Things konfiguriert werden müssen.
Bei Node Red gibt es für diesen Bereich z.B. das Konzept der "Configuration Nodes", mit dem die Konfiguration abgebildet werden kann oder zumindest eine einfache Schnittstelle zu vorhandenen Konfigurationstools wie PiCtory eingesetzt werden kann.
ich wünsche Dir jedenfalls viel Erfolg mit Deinem Projekt und bin gespannt, welche Wege Du einschlagen wirst.