Kann ich auch das Heltec "WiFi Kit 32" in der neuen Version V3 verwenden?

Hallo Kasimir, ich benutze den Sketch Abfuellwaage Version 0.1.3

Hallo Beegood, leider klappt es auch mit der Version nicht. Gibt es einen Grund warum du keine Neuere nimmst?
Jetzt fällt mir nur noch die Frage ein, ob du die Arduiono IDE verwendest und wenn ja, auch hier die Frage nach der Version. Danke!

1 Like

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

1 Like

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.

1 Like

Welche GPIOs nehmen wir jetzt?

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

GPIOs für V2 vs. V3

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

wiring-Diagramme für den Heltec, Version 3

Externe 5V-Stromquelle

1 Like

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!

1 Like

Das kann ich bestätigen, zumindest auf meiner Maschine.

Workstation

Gegenprobe

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

CI: Add support for "Arduino core for the ESP32" version 2.0.6 · ClemensGruber/hani-mandl@1c7043a · GitHub

Vielen lieben Dank Clemens. Ich gedulde mich dann noch.

2 Likes

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!

1 Like

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. :slightly_smiling_face:
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!! :frowning: 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!

1 Like

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.

2 Likes