LilyGo TTGO T7

Hardware
1

In Sachen ESPuino wird dieser PCB von inzwischen doch von einigen Leuten verwendet. Hier kommt der Wemos Lolin D32 pro zum Einsatz.

Vorteile:

  • 16 MB Flash-Speicher
  • ESP32-WROVER in neuer Revision E
  • Bietet PSRAM
  • LiPo-Lademöglichkeit
  • Sparsamer Festspannungsregler (im Gegensatz zu Boards mit AMS1117)
  • Gute Verfügbarkeit in Deutschland
  • Gute Dokumentation
  • Integrierte Akkuspannungsmessung auf IO35.

Nachteile:

  • Integrierter SD-Slot, der uns leider nix bringt, weil er für SDMMC nicht genutzt werden kann.
  • Manchmal ein bisschen zickig, was allerdings im Normalbetrieb nicht notwendigerweise ein Problem darstellt.
  • IO5 ist mit einer LED belegt.
  • Kriegt man nur in China.

Das hat mich in Diskussion mit @tueddy jetzt doch mal dazu bewogen, mal über den Lilygo TTGO T7 nachzudenken. Er besitzt den gleichen Festspannungsregler (ME6211) und den gleichen LiPo-Laderegler (TP4054) wie der D32 pro. Schaltplan gibt es hier. Die Kosten sind vergleichbar.

Ich bin in Sachen LilyGo, das habe ich hier ja auch schon anderweitig geschrieben, ein bisschen voreingenommen. Man kriegt den T7 in Deutschland auch nur schlecht, d.h. man wird ihn in China bestellen müssen. Aber sei es drum: Ich werde ihn mir mal bestellen, einen Test-PCB (ähnlich der D32pro-Plattform) machen und schauen, wie er performt.

Vorteile:

  • 16 MB Flash-Speicher
  • Bietet PSRAM
  • LiPo-Lademöglichkeit
  • Sparsamer Festspannungsregler (im Gegensatz zu Boards mit AMS1117)
  • kompakt
  • Integrierte Akkuspannungsmessung auf IO35.

Nachteile:

  • IO19 ist mit einer LED belegt.
  • ESP32-WROVER in alter Revision B. Welche Nachteile das mit sich bringt ist mir jedoch unklar.
  • Kein SD-Slot. Macht aber nix, den bauen wir dann halt extern dran.
  • Bei der Pin-Beschriftung muss man erstmal durchsteigen. IO14 heißt zum Beispiel TMS, IO12 TDI und IO13 TCK.
  • Kriegt man nur in China.
  • Mit CH9102 noch ein weiterer USB/seriell-Konverter, der ins Spiel kommt.
2

So, das Develboard kam heute an. Auf jeden Fall ist es schön klein. Wobei klein hier kurz heißt, da es breiter ist als der Lolin D32 pro, den ich zum Vergleich hingelegt habe.

PXL_20220205_120056435~2
PXL_20220205_120056435~21920×1446 205 KB

PXL_20220205_120125080~2
PXL_20220205_120125080~21920×1446 193 KB

Ich werde den Schaltplan nehmen, den ich auch für den d32pro verwende. Nur muss ich die Konnektoren anders anordnen. Vielleicht mache ich auch noch 1-2 SMD-Kondensatoren dazu. Mal schauen.

Der Akkuanschluss ist für unsere Zwecke bisschen unpraktisch an der Unterseite, aber ist kein Showstopper. Ist auch kein jst mit 2mm sondern 1.25 glaube ich.

3

Tja, so ganz optimal ist das Board nicht, wie mir jetzt leider erst nach der Bestellung aufgefallen ist.

a) Auf 3.3 V ist eine rote LED eingebaut, die einen Vorwiderstand von 2k hat. Bedeutet: Auch im Akkubetrieb haben wir einen zusätzlichen Strom von 1,65 mA. Uncool. Abhilfe: Müsste man die LED auslöten.
b) Eine weitere (grüne) LED liegt auf IO19. Das, was beim D32 pro also der IO5 ist, ist hier der IO19. Blöd: Da liegt normalerweise RFID.MISO drauf. Und das ist definitiv nichts, wo man eine LED mit Vorwiderstand ebenfalls haben möchte.
@tueddy Können wir das inzwischen eigentlich, dass wir den PN5180 auf eine Pin-Konfiguration legen, die nicht Standard-SPI ist?

Habe gerade so ein bisschen Zweifel dran, dass es sinnig ist, hier viel Arbeit mit einem PCB reinzustecken.

4

Hmm LED auf MISO? Da kannst Du eine Disko aufmachen :wink:

Die PN5180 Bibliothek verwendet Standard SPI, ein anderes Pinout ist derzeit nicht möglich:

  void PN5180::begin() {
  ..
  SPI.begin();
  ..
5

Da könnte ich ja mit leben, aber ich habe so meine Zweifel, dass mit einer Last dran das MISO auch wirklich noch so funktioniert, wie man das gerne hätte. Aus der Erfahrung raus würde ich sagen: Das lässt man besser :slight_smile:

6

Moin,

ich habe vorhin mal einen Blick auf die Title-Implementierung geworfen und gesehen, dass wir da bei jedem Titelwechsel eine Heap-Allokation machen. Um Heap-Fragmentierung und Code-Duplikation zu vermeiden, habe ich daher mal eine Funktion geschrieben, die Audio_handleTitle() heißt.

Das habe ich mal via GIST hochgeladen, damit du dir das mal anschauen kannst:

(Ich finde den Namen GIST übrigens fies. In der Onkologie ist das die Abkürzung für Gastrointestinaler Stromatumor).

Also aus meiner Sicht arbeitet das so, wie es soll. Weswegen ich dir jedoch schreibe: Wenn eine Playlist fertig wird, dann wird auf der GUI kein Update durchgeführt, welches den Titel leert. Ich habe meine Anpassungen dann mal testweise rausgenommen, neu kompiliert und habe gesehen, dass das im Master-Branch auch so ist. Kannst du das bestätigen?

In der Web.cpp habe ich die Zeile 586 so angepasst:

if (gPlayProperties.title != NULL && strcmp(gPlayProperties.title, "") != 0) {

Also entweder ich habe was verpeilt oder es fehlt hier ein Event, das „Playlist fertig“ an die GUI pusht.

7

Ich teste das gern, Du hast aber den Inhalt Web.cpp anstelle von AudioPlayer.cpp hochgeladen…
grafik

8

Eieiei :rofl:

9

Ich kann das Problem reproduzieren, leider klappt Dein Fix noch nicht.
Getestet mit 1 Track, Modus Hörrbuch (kein! Endlos).
Bei Ende wird in der Konsole

Ende der Playlist erreicht.

angezeigt, Cover, aktueller Titel und Play-Schalter bleiben aber bestehen:

grafik
grafik293×633 84.4 KB

Hier sieht man auch schön den noch bestehenden Bug mit dem Zeilenumbruch im Lautstärkeregler…

10

Nene stop, ich habe das gar nicht gefixt. Mir ist das im Anschluss nur aufgefallen und ich war mir nicht sicher, ob ich was verkackt habe. Also fixen sollte mein Kram nur Code-Duplikation und wiederholte Heap-Allokation. Das passt aus meiner Sicht auch.
Also fehlt noch eine Aktion, die noch was in die GUI pusht, wenn die Playlist rum ist.

11

OK, das sind hier dann ja zwei paar Schuhe, Heap-Fragmentierung + WebUI-Aktualisierung.

Habe ein Hörbuch mit unterschiedlichen Titeln (50 Mal) durchgeklickert mit Deinen Änderungen:
Start:
Freier Heap: 59356 Bytes

Ende:
Freier Heap: 58708 Bytes

Da kann natürlich alles mögliche zuspielen, Audio, Web, MQTT usw.
Für mich sehen Deine Heap-Fixes soweit gut aus, kann man so einchecken.

Bezgl. Aktualisierung der Websteuerung kann ich Dir gern einen PR/PM zusenden. Wird vermutlich nur eine Zeile sein :sunglasses:

12

Ok, die Frage ist nur: Wie soll diese eine Zeile da in Web.cpp aussehen?

13

Hmm, das müsste ich erst genau testen, aber mal so auf die Schnelle.

Im Serial wird ja ausgegeben „Ende der Playlist errreicht“, das passt ja. Suche in danach im ganzen Projekt finde ich AudioPlayer.cpp Zeile 572

           if (gPlayProperties.currentTrackNumber >= gPlayProperties.numberOfTracks) { // Check if last element of playlist is already reached
                Log_Println((char *) FPSTR(endOfPlaylistReached), LOGLEVEL_NOTICE);

Da irgendwo würde ich jetzt

                // clear cover image
                gPlayProperties.coverFilePos = 0;
                Web_SendWebsocketData(0, 40);

für das leeren des CoverImage und

Web_SendWebsocketData(0, 30);

für die Aktualisierung von Titel/Schalter einsetzen.

Hoffe das ist nachvollziehbar für Dich?

14

Ich teste das einfach mal :slight_smile:

15

So, hab’s rausgehauen.

16

@biologist was hältst Du davon einen eigenen Thread „Firmware -Optimierung/Fehlerbehebung“ aufzumachen wo die Experten Alles reinwerfen können?

Ich meine mit „Experten“ alle die sich intensiver mit dem Code beschäftigen und vielleicht auch nur durch Kleinigkeiten den Code/Stabilität verbessern können? Also kein Ausschluss von Benutzern sondern Alles was tief reingeht - So eine Art Chat-Thread?
Unsere Diskussion ist hier irgendwie falsch aufgehängt im TTGO-T7. Nur so ein Vorschlag…

Schöne Grüße an alle ESPuino’!

17

Ja, ich hab’s tatsächlich geil verpeilt und dachte wir würden PNs schreiben :rofl:.
Da hatten wir ja nen Thread zum T7 und da habe ich irgendwie ins Falsche geclickt.

Man man man…

Aber ja, hätte gegen den Vorschlag nix einzuwenden.

18

Na dann wissen jetzt alle was auch hinter den Kulissen für dieses Projekt gearbeit wird, ist ja nichts geheim :wink: Schönen Abend!

1 „Gefällt mir“