Hi @didilamken, bin auch gerade an der Platine, lass uns das gerne zusammen machen!! Fritzing ist zwar nicht “engineer’s first choice”, man kann neben einfachem Platinen-Design aber auch eine schöne breadboard-Ansicht zeichnen, um einfach zu zeigen wo welche Kabel hin sollen.
@einsiedlerkrebs hat am Donnerstag schon eine Platine als Prototyp gelötet, die als “Zwischenlage” zwischen das PyCom-Erweiterungsboard und den FiPy / LoPy passt. Man könnte damit etwas Platz sparen und ggf. auch die Platine mit FiPy ohne das Erweiterungsboard verwenden, falls man keine SD-Karte braucht.
Magst du schon mal die Pin-Belegung hier posten, damit wir die gleiche Belegung verwenden?
MIt C/C++ / Arduino und MicroPython schlagen auch bei mir zwei Herzen in der Brust. Da ich auch schon lange C/C+±Code für Arduino verwende und schreibe ist das naheliegend und war auch meine erste Wahl und so mit @caro noch Anfang des Jahres eigentlich ausgemacht.
Wir sehen aber gerade an verschiedenen Ecken, dass die ESP32-boards mit ihren zwei Kernen doch etwas komplexer und komplizierter sind als ein Arduino, bei dem nur alles seriell abgearbeitet wird und bei dem man sich wenig kümmern muss, dass Dinge sich nicht gegenseitig behindern. Alles hat schon mit dem ESP8266 angefangen, bei dem immer wieder das WLAN-Modul Kernel-Leistung brauchte, damit es nicht abgeschmiert ist. Man musste z.B. damals an diversen Stellen der HX711-lib ein yield();
einfügen, damit der kernel dem WLAN-thread auch wieder erlaubt hat zu schauen, ob über die Funkschnittstelle neues reingekommen ist.
Das ist aber nur ein Aspekt, da PyComs first choice MicroPython ist, entwickeln sie für ihre Hardware erst mal in MicroPython, ggf. gibt es dann jemanden, der die Dinge auch für das Arduino-Universum erschließte, wann das passiert und welche Qualität das hat ist aber nicht berechenbar. Wir haben gerade noch Probleme den neuesten LTE-Standard der FiPy-Module mit MicroPython zu erschließen, der ja eigentlich offiziell von PyCom unterstützt wird, aber selbst das ist noch tricky, wie und ob das überhaupt mit dem Arduin-Core finktionieren würde, wissen wir momentan gar nicht. Da ist die “sicherere” Bank auf den “offiziellen” MicroPython-Code zu setzen, der laut @Andreas auch allgemein die beiden cores meist besser unterstützt.
Ich weiß viele “wenn” und “aber”, wir sind auch hier bei der Nutzung der Technologie relativ weit vorne und nahe dran an Dingen, die noch nicht lange fertig oder gar noch in der Entwicklung sind. Das ist auf der einen Seite super toll, die “Speerspitze” zu sein, Dinge mit als erste für ein neues Anwendungsgebiet zu erschließen, manchmal aber auch frustrierend und demotivierend, weil Dinge noch nicht so funktionieren, wie sie sollen oder wir uns das wünschen. Es ist eben keine consumer-Elektronik, die wir hier einsetzen, und selbst die funktioniert manchmal ja nur holprig! ;-)
Langer Rede kurzer Sinn: Lass es uns mit MicroPython versuchen, @vinz von der Uni Bremen hat da auch schon gut vorgelegt, @Andreas ebenfalls.