Hi, Ich baue aktuell eine Firmware auf Basis von MicroPython. MicroPython bietet fast alles, was ich benötigen und nur selten muss ich etwas "tiefer einsteigen", um ein Feature zu entwickeln. Trotzdem habe ich mir überlegt, in Zukunft auf C/C++ basierte Entwicklung umzusteigen, da MicroPython vermutlich auch einiges an Ressourcen frisst und ich auf sehr günstigen Modulen, wie dem ESP32 entwickele. Was mich wundert ist, dass es zumindest den Anschein macht, dass die Portierung zwischen verschiedenen Plattformen gar nicht so einfach ist. Wenn ich meine Hardware auswähle, dann muss ich scheinbar vorher genau schauen, dass auch für die meisten meiner Features eine Plattform existiert mit entsprechenden Libs. Konkret ist mir das aufgefallen, da ich mir einen RTL8710 https://www.amebaiot.com/en/ameba-arduino-getting-started-rtl8710/ zugelegt habe. Scheinbar gibt es hier keinen offiziellen Port für die mbed Plattform, obwohl ein "Schwesterboard" RTL8195 offiziell "ARM mbed enabled" ist. Daraus habe ich gefolgert, dass der Aufwand, für eine Hardware eine neue Plattform zu unterstützen gar nicht so gering ist. Mich wundert das aber insbesondere, da sehr viele Boards/Module auf den gleichen MCUs (oder zuminderst der gleichen Architektur) wie z.B. dem Cortex M3 aufbauen. Grundsätzlich müsste das ganze grob wie in der angehängten Skizze aussehen. Demnach wären sollten in der Regel nur die "Adapter" zu schreiben sein und hier lässt sich doch bestimmt einiges wiederverwenden, insbesondere wenn man es mit dem gleichen MCU zu tun hat. Konkret interessiere ich mich aktuell für folgende Funktionalitäten. * WiFi * MQTT * Cooperative Scheduling (asnyc/await) oder auch Threads * HTTP(S) oder Einfach nur TCP Socket (Server) * TLS * CryptoLib (mit RSA, AES, SHA256) * UART Wie hoch ist in etwa der Aufwand (z.B in Zeilen Code) für ein Board wie den RTL8710 oder ESP32 (z.B 356-ESP32-DEVKITC) einen Port auf mbed zu entwickeln (unter der Annahme, dass es schon Arduino oder MicroPython Port gibt)? Welche Schritte sind hierzu (grob) durchzuführen und wo stecken die größten Aufwände? Ich hoffe meine Frage ist nicht zu schwammig. Wenn doch, kann ich gerne nochmal nachjustieren ;-) Viele Grüße
Angehängte Dateien:
-
hardware_abstraction.png
8,8 KB
:
Bearbeitet durch User
>unter der Annahme, dass es schon Arduino oder MicroPython >Port gibt Warum willst Du auf mbed wechseln, wenn es einen Arduino-Port gibt? Damit verbaust du dir einen eventuellen späteren Software-Umzug auf Espressif oder Risc V.
Gute Frage, also es gibt aktuell keine konkreten Gründe für einen Wechsel. Wenn würde ich eher von MicroPython auf Arduino wechseln wollen, obwohl ich aktuell mit MicroPython zufrieden bin. Ich wäre aber gerne auf einer Plattform, bei der es schon viele Libraries gibt und die viel Hardware unterstützt. Ob der Wechsel sinnvoll ist oder nicht, ist sicher auch eine Diskussion wert, ich Frage mich aber aktuell eher: 1.) Sehe ich das richtig, dass ein neuer Port mit erheblichen Aufwänden verbunden ist? 2.) Wie hoch sind diese Aufwände in etwas und wie setzen sie sich zusammen?
>Konkret ist mir das aufgefallen, da ich mir einen RTL8710
Welchen Compiler gibt es? Welches Entwicklungssystem wird normalerweise
dafür verwendet? Wo findet man den Source-Code zu dem Modul? Welche
Libraries gibt es schon dafür?
die Targets die von Mbed untertstützt werden findet man hier: https://github.com/ARMmbed/mbed-os/tree/master/targets Für den RTL8195 wird ein (angepasstes?) SDK verwendet, das scheint auch für andere wie RTL8712 zu sein. Da die Module recht ähnlich aussehen scheint eine Portierung nicht zu aufwändig zu sein, aber der Teufel steckt ja immer im Detail. Das RTL Modul sieht aber sehr interessant aus weil es viele Resourcen hat die man gerade für TLS braucht. Für 'Mbed enabled' Boards ist ein zusätzlicher µC mit dem CMSIS-DAP nötig, deshalb findet man in target mehr als in der Boardliste auf der Website aufgelistet ist. Für den Fall braucht man einfach einen ext. Debugger, auf die target Implementierung hat das aber keinen Einfluss. In Mbed gibt es Custom Targets, die kann man definieren ohne das mbed-os selber verändern zu müssen. Das ist für solche Erweiterungen sehr schön, früher musste man sich für eigene HW immer Branches machen und bei neuen releases die Änderungen wieder reinmischen. Habe nochmal nach Unterlagen zu den RTL Chips gesucht, das Problem ist wohl hauptsächlich das man chinesisch lesen können muss. Sehr spärlich was Realtek da liefert, wie bei Espressif. Und wenn die morgen was besseres rausbringen ist der Chip Ruckzuck nicht mehr lieferbar.
da hat doch schon jemand etwas zusammengetragen: https://www.cnx-software.com/2016/08/01/development-resources-for-realtek-ameba-rtl8710-rtl8711-and-rtl8195-wifi-socs/ https://www.cnx-software.com/2016/07/28/an-alternative-to-esp8266-realtek-rtl8710-arm-cortex-m3-wifi-iot-modules-sell-for-2-and-up/ Gegenüber der weiten Verbreitung der ESP hat der aber nicht viele Vorteile, eigentlich nur das er einen Cortex-M als Prozessorkern hat, wenn man den haben möchte. Der Chinese verkauft die auch ganz gerne: https://de.aliexpress.com/wholesale?catId=0&initiative_id=SB_20191207155037&SearchText=rtl87 und 2016 wurde der hier schon 'entdeckt': Beitrag "Totschläger für ESP8266?" Beitrag "W600 - WiFi SoC mit Cortex-M3 für 1.90$?"
Hallo, Johannes S. schrieb: > und 2016 wurde der hier schon 'entdeckt': > Beitrag "Totschläger für ESP8266?" > Beitrag "W600 - WiFi SoC mit Cortex-M3 für 1.90$?" ein W600 Modul habe ich hier im Einsatz. Einbindung in die ArduinoIDE ist rudmentär vorhanden, 0.2.6 vom April 2019 war die letzte Version, seitdem ist ewig Ruhe... Nach weiteren Programmierunterlagen dazu habe ich nie gesucht. Gruß aus Berlin Michael
Christof T. schrieb: > Mich wundert das aber insbesondere, da sehr viele Boards/Module auf den > gleichen MCUs (oder zuminderst der gleichen Architektur) wie z.B. dem > Cortex M3 aufbauen. Hier musst du vorsichtig sein. Die Architektur von ARM/Cortex umfasst nur den CPU-Kern und einige ganz wenige "Drumherum Funktionen" wie z.B. Interrupts. Alles andere, vorallem die gesamte Peripherie wird von jedem Hersteller individuell selbst entwickelt. So kann es vorkommen das z.B. ein Timer von einem bestimmten NXP völlig anders konfiguriert werden muss als z.B. einer von STM. Sogar innerhalb des selben Hersteller gibt es hier teilweise einiges an Unterschieden selbst wenn auf beiden Cortex M3 drauf steht. Daher je näher du der Peripherie kommst um so individueller wird deine Software. Erstrecht wenn du auch noch den vollen Funktionsumfang den diese bietet auch benutzen willst und nicht z.B. nur den 05/15 Standardmodus "Startwert gemäß CLK runterzählen und bei 0 -> IRQ" den fast jeder Timer kann nutzt.
Super, Danke für eure Antworten so weit. Das gibt mir einen besseren Überblick. Mal noch kurz zu einem konkreten Beispiel: Ein Driver für ein SPI SIM-Modul (nur für Netzwerk, nicht SMS,...) sollte m.E. für alle MCUs und Plattformen mit SPI Driver ohne (größeren) Anpassungen verwendbar sein. Der Driver für das Modul sollte mir Methoden anbieten, die mir einen Netzwerkadapter zurückgeben. Den kann ich dann wiederum nutzen, um Socketverbindungen zu erstellen. Ich schlimmsten Fall (wenn hier wenig standardisiert ist) würde ich erwarten, dass der Driver ein Mapping von einer SPI Abstraktion des "generischen Driver für das Modul" zur SPI Implementierung der Plattform enthalten muss und evtl. ein solches Mapping für den Netzwerkadapter. Was mich wundert, ist, dass es diese Abstraktionen "Netzwerkadapter" usw. nicht gegeben scheint. So habe ich gerade in den Arduino libs für den ESP32 gesehen, dass der Webserver direkt mit dem WiFiClient arbeitet. Stattdessen sollte diese doch eher eine Socket öffnen und im Hintergrund kümmert sich ein Netzwerkadapter um diese Sockets. Eine Abhängigkeit eines Webserver von einem WiFiClient finde ich eher schräg und da wundert mich dann auch nicht mein Eindruck, dass die Anpassungen unglaublich aufwändig sind. Anderes Beispiel wäre MQTT. Ein MQTT Client sollte m.E. bis auf minimale Anpassungen portierbar sein, da er nur eine Socketimplementierung benötigt (beim Paho Client ist dies auch z.B. der Fall), hier scheint die Anpassung in wenigen Zeilen machbar zu sein und sogar für alle Arduinos, für die es eine Socketimplementierung gibt wiederverwendbar zu sein. Ist Paho hier ein gutes Beispiel oder täuscht mich der Eindruck und andere Bibliotheken können auch schnell angepasst werden? Durch diese scheinbar fehlende Socket Abstraktion bei Arduino (zumindest ESP32 libs) kann ich dann im Falle von MQTT auch nicht so einfach meine WiFi Verbindung durch eine mobile Verbindung über das SIM Modul austauschen. =/
Deshalb benutze ich Mbed, das ist da sauberer. Das früher proprietäre Netzwerkinterface ist jetzt sehr kompatibel zu Berkeley sockets. Damit habe ich einen MQTT Client auf einem STM32F407 laufen. Am Webserver incl. Websockets arbeite ich gerade, funktioniert auch schon einigermaßen. Mbed hat auch eine Unterstützung für ESP oder Cellular als NIC, habe ich aber noch nicht benutzt. Die Module sind aber speziell, da läuft schon selber ein OS drauf und die IP Verbindungen werden in der Firmware abgehandelt.
Christof T. schrieb: > Demnach wären sollten in der Regel nur die "Adapter" zu schreiben sein > und hier lässt sich doch bestimmt einiges wiederverwenden, insbesondere > wenn man es mit dem gleichen MCU zu tun hat. > * Cooperative Scheduling (asnyc/await) oder auch Threads > * HTTP(S) oder Einfach nur TCP Socket (Server) Jain, ein RTOS Port wie z.B. embOS (oder auf FreeRTOS) ist immer Core und Compiler spezifisch. Das heißt ein embOS Cortex-M für Embedded Studio läuft auf jedem Cortex-M (einfacher ist es noch mit einem fertigen Board Support Package inklusive Projekt für die gewünschte IDE). Hier ist es schon so das 99% der Software wiederverwendet wird und nur ein kleiner Teil auf den Core/Compiler und das Device/Hardware angepasst werden muss. Bei Embedded Software wie USB oder TCP/IP Stack kann es zum Beispiel wie bei uns sein das der eigentliche Stack komplett in C geschrieben ist und damit Core/Compiler und Device/Hardware unabhängig ist. Dazu braucht man dann noch einen Treiber für das entsprechende Device und ein bisschen Anpassung an die jeweilige Hardware. Dein "Adapter" wäre hier der Treiber bzw. die Anpassung an die Hardware. Das kommt deinem Bild oben schon recht nahe, nur das man gerne versucht für bessere Effizienz möglichst wenig Layer zu haben. Mehr Layer bzw. Abstraktion hilft evtl. dem Anwender aber macht eine Portierung schwieriger.
Okay danke für eure Antworten. Das hilft schon mal deutlich weiter. Wahrscheinlich werde ich beim Portieren nochmal konkretere Fragen aufkommen, in dem Fall starte ich dann aber besser einen neuen Thread.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.