Wer ist Oliver? / Welcher Oliver. :-)
Das ist die offiziell von Heltec verlinkte Schematik. Etwas verwirrend finde ich hier, dass es LoRa-pins gibt, obwohl das board kein LoRa-Modul hat und es in der Vergangenheit auch Verwechslungen zu Board aus der Serie mit LoRa gab.
Ich meinte, ob du die gleiche Bibliothek für das Display nimmst.
olikraus · GitHub)/u8g2
Beim Code hatte ich mich bisher mit der Version Abfuellwaage Version 0.2.9 versucht.
Als Plattform benutze ich Arduino IDE 2.0.3
Bei mir compiliert (mit Warnungen, läuft aber durch) der aktuelle code auf master (v0.2.9) nur mit dem Arduino ESP32 core 1.0.6, mit dem 2.x-er core nicht.
Nun habe ich versucht den Heltec V3 als ESP32 Dev Module anzusprechen, das geht aber nicht, Hochladen wird quittiert mit:
A fatal error occurred: Invalid head of packet (0x47)
Wenn ich den Heltec V3 als board auswähle (board installieren, falls es bei euch nicht auftauch), bringt der seinen eigenen ESP core mit (vermutlich >2) und ich habe Compilierungsfehler.
D.h. ich werde jetzt erst mal versuchen den aktuellen code oder besser gleich den im develop-Branch (v0.2.12) etwas upzudaten und den mit ESP core 2.x lauffähig zu bekommen … stay tuned!
[edit] Ich habs mir es jetzt erst mal etwas einfacher gemacht und die compiling errors auf Standard gesetzt, war von einer früheren debug session noch auf Weitere.
Nun compiliert der code mit Wifi Kit 32(V3) als board und lädt den code auch hoch, allerdings bleibt – wie oben berichtet – das Display dunkel.
Wir haben im code für die alte Version (V1 / V2) pins verwendet, die momentan (V3) komplett anders belegt sein können, daher müssen wir an die weiteren Pins ran:
Nun habe ich so gut wie alle pins neu zugeordnet – ich habe das erst einmal vorläufig gemacht, muss nochmal checken, ob die so passen – und es läuft eigentlich ganz passabel (Servo habe ich noch nicht angeschlossen):
Zwischenfazit: Die neue Verison V3 des “WiFi Kit 32” von Heltec funktioniert generell als HaniMandl-Basis, allerdings müssen der code und die physikalischen Anschlüsse geändert werden.
Neben real world testing :-) habe ich bisher bei der Zuordnung von ESP32-pins zu Hardware immer einen Blick auf
geworfen. Dort ist gut dokumentiert, welche pins z.B. beim booten toggeln und so schon einmal eine Servo unintendiert ansteuern oder welche pins anderweitig belegt sind oder nur inputs sind … Die Doku ist allerdings für einen ESP-WROOM-32 o.ä. jedenfalls wird dort z.B. GPIO 34, 35, 36, 39 als INPUT ONLY gekennzeichnet, was bei unserem board nicht sein kann, da die onboard LED (s. pinout-Grafik oben) an GPIO 35 hängt.
Laut WiFi Kit 32 (V3) – Heltec Automation > [weiter unten auf tab datasheet klicken] > [scrollen zu Tabelle 1.1] ist bei unserem neuen board ein ESP32 S3 verbaut, während die V2 einen ESP32-D0 hatte.
Also RTFM für den S3, https://www.espressif.com/sites/default/files/documentation/esp32-s3_datasheet_en.pdf ab Seite 18 und auch GPIO & RTC GPIO - ESP32-S3 - — ESP-IDF Programming Guide latest documentation … tbd
| Heltec V2 | Heltec V3 | Anmerkung | |
|---|---|---|---|
| // Rotary Encoder | |||
| const int outputA | 33 | 47 | |
| const int outputB | 26 | 48 | |
| const int outputSW | 32 | 26 | |
| // Servo | |||
| const int servo_pin | 2 | 33 | |
| // 3x Schalter | |||
| const int switch_betrieb_pin | 23 | 40 | |
| const int switch_vcc_pin | 19 | 41 | // <- Vcc |
| const int switch_setup_pin | 22 | 42 | |
| // Vext controll | |||
| const int vext_ctrl_pin | 21 | 36 | // Vext control pin |
| // Taster | |||
| const int button_start_vcc_pin | 13 | 7 | // <- Vcc |
| const int button_start_pin | 12 | 6 | |
| const int button_stop_vcc_pin | 14 | 5 | // <- Vcc |
| const int button_stop_pin | 27 | 4 | |
| // Wägezelle-IC | |||
| const int hx711_sck_pin | 17 | 38 | |
| const int hx711_dt_pin | 5 | 39 | |
| // Buzzer - aktiver Piezo | |||
| static int buzzer_pin | 25 | 2 |
Da ich dazu leider etwas unwissend bin, wie bekomme ich denn mein Heltec ESP 32 V3 zum laufen? Ich habe null Ahnung von Programmieren. Gibt es da evtl ein fertiges Programm fürs Arduino?
Hi Marci, bisher leider noch gar nicht! Wir sind gerade dabei den code bzw. die zu verwendenden pins auszutüfteln, ich denke in ein paar Tagen sollten wir etwas weiter sein und du kannst dann nachbauen.
Hallo Kasimir,
Die genaue Referenz auf die verwendete U8g2 Bibliothek findet sich hier:
Viele Grüße,
Andreas.
Es funktioniert auch mit der aktuellen U8g2-Version!
Das kann ich bestätigen, zumindest auf meiner Maschine.
CI: Update versions of GHA recipes by amotl · Pull Request #34 · ClemensGruber/hani-mandl · GitHub klappt wunderbar, siehe CI: Update versions of GHA recipes · ClemensGruber/hani-mandl@95acd62 · GitHub.
CI: Add support for "Arduino core for the ESP32" version 2.0.6 by amotl · Pull Request #35 · ClemensGruber/hani-mandl · GitHub klappt nicht mit Arduino ESP32 Core v2, zumindest auf meiner Maschine.
Environment Status Duration
-------------------------- -------- ------------
heltec-arduino-esp32-1.0.6 SUCCESS 00:00:10.985
heltec-arduino-esp32-2.0.6 FAILED 00:00:05.639
Kurioserweise kompiliert die v2 Variante aber in einer anderen Umgebung, und die v1 schlägt fehl, also genau andersherum?
Environment Status Duration
-------------------------- -------- ------------
heltec-arduino-esp32-1.0.6 FAILED 00:00:59.186
heltec-arduino-esp32-2.0.6 SUCCESS 00:01:04.815
Vielen lieben Dank Clemens. Ich gedulde mich dann noch.
Heureka! Jetzt sehe sogar ich nicht mehr schwarz! (Arduino IDE, ESP32S3 Dev Modul) Der Code 0.2.9 wird kompiliert (nur Warnungen, keine Fehler) und hochgeladen. Das Display zeigt an, was es soll.
Danke für eure Geduld und Energie!
Im ersten Versuch hat der Heltec V3 mit unserem modifizierten code (pin Zuordnung, s.o.) funktioniert, allerdings ist die Reaktionszeit von Display / Waage und auch Eingabe über rotary / Buttons deutlich träger, zäher als mit einem Heltec V2, die ich gerade parallel mit identischem code (0.2. 8 9) getestet habe. Allerdings ist der Heltec V2 schon etwas länger bespielt worden, kann sein, dass da ein anderer Arduino ESP32 core verwendet wurde. Ist in einem Gehäuse festgeklebt, daher komme ich zum Umprogrammieren nicht leicht ran. Den V3 mit einem core < 2.x zu testen geht aber nicht, da es da den ESP S3 noch nicht gab. Also weiter schauen, hatte mir das etwas einfacher vorgestellt.
Hallo Clemens, da möchte ich doch gleich mal eine Rückmeldung geben. Im Prinzip scheint es bei mir mit dem Code 0.2.8 zu funktionieren! Super!
Wenn ich allerdings versuche den Öffnungswinkel im Automatikmodus kleiner zu stellen, stürzt das Programm bei unter 41% ab und bootet neu. Kann allerdings auch an meinen fliegenden Verkabelungen liegen, oder es ist ein Bedienfehler meinerseits. Morgen werde ich das Ganze mal in ein Gehäuse einbauen und mich erneut versuchen.
Hallo Clemens, ich bin wild am Rumprobieren, allerdings ohne für mich klare Erkenntnisse. Gibt es einen Grund, dass du Version 0.2.8 verwendet hast? Habe aus versehen wieder 0.2.9 verwendet und blicke bei den verwendeten Bibliotheken für 0.2.8 und 0.2.9 nicht mehr durch. Hier also meine Bitte: Falls du weiterkommst, kannst du bitte noch mal die Version plus die entsprechenden Bibliotheken nennen?
Und falls meine Ungeduld nervt, sorry!
Habe es auch zum Laufen bekommen. Nutze die Version 0.2.9 Ob das Display träger ist als V2 kann leider nicht sagen, da ich die V2 nicht kenne.
Glückwunsch! Da kann die neue Ernte ja kommen. 
Kannst du denn den Öffnungswinkel kleiner als 40° einstellen?
Zur “Beruhigung”, ich habe das – Absturz und reboot – beim Drehen des rotarys auch und denke, es liegt nicht an der fliegenden Verkabelungen oder anderen Dingen, und es liegt auch nicht an den 41%, sondern an Problemen in Zusammenhang mit dem rotary / hardware interrupts und der “neuen” Arduino ESP32 core ≥ 2.0, siehe auch: Was muss ich bei Verwendung von zwei Netzteilen (eines für Servo, zweites für Microcontroller) beachten? - #9 by clemens
Bei mir läuft der code stabil, wenn ich die Zeile ca. 307 (je nach code-Version) auskommentiere
// if ( rotating ) delay (1); // wait a little until the bouncing is done
Das delay in der ISR-Funktion ist an sich schon eine schlechte Idee, stammt allerdings aus code snippets, die wir damals gefunden haben und die bisher auch funktioniert haben.
Ob mit der Auskommentierung das bouncing nun schlimmer wird kann ich noch nicht eindeutig sagen, konnte da nix beobachten, allerdings habe ich ja immer noch das Problem mit der allgemeinen Reaktionszeit, was ggf. auch ein bouncing verhindert. Sprich wir müssen erst die Geschichte mit der Reaktionszeit lösen.
Sorry, typo, meine Datei war falsch benannt, habe die 0.2.9 verwendet! Bibliotheken sind alle identisch, ob 0.2.8, 0.2.9 … 0.2.12 …
Ich befürchte noch nicht!! 
Produktiv würde ich das noch nicht nutzen, die Waage reagiert so träge, dass vermutlich die Abfüllung ungenau oder mit Honigüberlauf “funktioniert”. Den Fehler müssen wir noch finden … werde dafür nochmal die verwendeten pins für die Waage tauschen und mir die ISR-Abfrage anschauen und auch nochmal den Zeitverbrauch für einen Mess-Durchlauf ansehen. @aholzhammer meinte, dass im Handbetrieb eine Schleife 180 ms inkl. Messung dauert. Mal schauen wie weit wir davon weg sind. Dann würde ich zu debug-Zwecken die Messung deaktivieren, um zu schauen, ob das der Grund der Verzögerung ist oder die Abfrage des rotary / irgendwas mit ISR. Wer mittesten möchte, gerne!
Toll, vielen Dank für das Teilen und die Vorlage dieses Fundes. Hier sollten wir definitiv etwas tun und ein neues Pflaster draufkleben, ähnlich zu Spring cleaning with multiarch support by amotl · Pull Request #123 · bogde/HX711 · GitHub. In diesem Fall scheint es um ein Synchronisationskonstrukt per Spinlock zu gehen?
The use of such a lock is a kind of busy waiting.
Ob bei dem angewendeten delay() “busy wait” der korrekte Begriff ist, kann angezweifelt werden ;]. Zweifelsohne gehört das so jedoch eher nicht in eine ISR Routine – wir müssen sehen, ob wir anders synchronisieren können.
Bin etwas weiter gekommen mit der Analyse, etwas langwierig das ganze. :-( Ein Problem ist definitiv der zähe Programmablauf. Wie gesagt sollte eine Schleife im manuellen Betrieb “normal” bzw. mit bisheriger Hard- und Software ca. 180 ms dauern. Wenn man in Zeile 116 den debug-output mit level 4 aktiviert:
#define isDebug 4
bekommt man die Durchlaufzeiten im Seriellen Monitor angezeigt.
Handbetrieb: Gewicht 0 Winkel 59 Dauer 629 servo_aktiv 1
Leider ist mein subjektiver Eindruck richtig und unser Heltec V3 ist aktuell fast 4x langsamer als die alte Version!
Habe jetzt einen Heltec V2 (!) mit identischem code und als board (1. Test) Heltec V2 (Heltec board definition) bzw. dann auch (2. Test) ESP32 Dev Module (allg. ESP32 board definition) versorgt und die Durchgangszeit gemessen, auch da spuckte die Serielle beides mal ca. 630 ms aus!!
Nun habe ich die allgemeine ESP32 board definition verwendet, allerdings auf den ESP core 1.0.6 downgegradet, sonst alles gleich und sieh, nun ist der Durchlauf mit 174 ms “normal”, es liegt also nicht an irgendwelchen pins, sondern am ESP32 core. Pfff, Problem also etwas weiter eingegrenzt, aber ich habe aktuell keine Lösung oder weitere Idee, wie ich weiter eingrenzen könnte.
Leider können wir als workaround – wie oben schon mal geschrieben – auch nicht einfach den ESP Arduino core 1.x nehmen, da der den ESP32 S3 noch nicht unterstützt, wir müssen also beim core > 2 bleiben und da schauen, was klemmt.
[edit] Mit ESP Arduino core 2.0.3 habe ich die langen Reaktionszeiten, mit core 2.0.2 noch nicht. Bringt uns aber auch nicht weiter, da in 2.0.2 der ESP S3 auch noch nicht verfügbar ist.
So, ich hab’s Heureka! Wir haben bisher das Display über Software I2C angesprochen mit (Zeile 156):
U8G2_SSD1306_128X64_NONAME_F_SW_I2C u8g2(U8G2_R0, /* clock=*/ 15, /* data=*/ 4, /* reset=*/ 16);
bisher hatte ich nur die pins geändert, alles andere so gelassen, funktionierte, aber eben langsam. Nun habe ich auf Hardware I2C (HW in contructor, Achtung, pin order ist dann 'ne andere, zuerst kommt Reset!) umgestellt und mit
U8G2_SSD1306_128X64_NONAME_F_HW_I2C u8g2(U8G2_R0, /* reset=*/ 21, /* clock=*/ 18, /* data=*/ 17);
bekomme ich auch wieder die 180 ms
21:15:43.161 -> Handbetrieb: Gewicht 0 Winkel 0 Dauer 179 servo_aktiv 0
was für ein act! Aber es scheint jetzt zu funktionieren. Servo noch nicht dran, ggf. gibts da noch Überraschungen.