Forum: Compiler & IDEs Aufwand für die Portierung auf Plattformen wie Arduino, mbed, Micropython,.


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Christof T. (christof_t)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
von Christoph M. (mchris)


Bewertung
0 lesenswert
nicht lesenswert
>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.

von Christof T. (christof_t)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Christoph M. (mchris)


Bewertung
0 lesenswert
nicht lesenswert
>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?

von Johannes S. (jojos)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Johannes S. (jojos)


Bewertung
1 lesenswert
nicht lesenswert
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$?"

: Bearbeitet durch User
von Michael U. (amiga)


Bewertung
1 lesenswert
nicht lesenswert
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

von Irgend W. (Firma: egal) (irgendwer)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Christof T. (christof_t)


Bewertung
0 lesenswert
nicht lesenswert
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. =/

von Johannes S. (jojos)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Til S. (Firma: SEGGER) (til_s)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Christof T. (christof_t)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.