Autoerkennung von RFID-Reader

Software
1

Wir wollen ESPuino ja dahingehend sukzessive umbauen, dass immer mehr Einstellungen im Webinterface getätigt werden können. @Joe91 hat sich diesbzgl. eines neuen Themas angenommen: RFID. Hier ist der PR dazu: Rfid at runtime by Joe91 · Pull Request #403 · biologist79/ESPuino · GitHub.
Vielen Dank an dieser Stelle für deine Arbeit!

Es hat das Ganze maximal komfortabel gelöst: Es gibt eine Autoerkennung, die wahlweise PN5180, RC522-SPI oder RC522-I2C initialisiert. Dabei wird der zuletzt erfolgreiche Wert im NVS gespeichert und damit beim nächsten Start die Initialisierung begonnen.

Wird kein Reader erkannt, so läuft das Ganze so ab:

I [3701] RFID: Auto-detecting reader type…
D [3701] RFID: Checking PN5180…
D [4772] RFID: PN5180 firmware read ok=1 version=0.0
D [4773] RFID: PN5180 not present or unreadable
D [4773] RFID: Checking MFRC522 (SPI)…
D [4835] RFID: MFRC522 (SPI) version=0x00
D [4835] RFID: Checking MFRC522 (I2C)…
D [4938] RFID: MFRC522 (I2C) version=0xFF
E [4938] RFID: No reader detected
E [4938] RFID: Failed to auto-detect reader type, using default
I [4949] RFID: Using reader type: 3 (PN5180)

LPCD ist auch abgedeckt. Was aktuell noch fehlt ist RFID-Gain für RC522.

RFID-Konfiguration
RFID-Konfiguration728×356 9.28 KB

Bei der Gelegenheit hat @Joe91 auch die Audio-Lib und auch das ESP32-Arduino aktualisiert. In diesem Zuge sind mir zwei Dinge aufgefallen:

a) Die serielle Konsole zeigt nur einen Teil der Ausgaben an - die Zeilen wirken vorne abgeschnitten. „Beheben“ kann man das, wenn man den Exception-Decoder deaktiviert.
b) Die Audioausgabe ist erheblich leiser. @Wolle Wir hatten länger kein Update mehr deiner Lib gemacht. Gab es in den letzten Monaten Anpassungen, die es begünstigen, dass die Ausgabe nun wesentlich leiser ist? Ich muss dazusagen, dass ich per Hardware-Einstellung den MAX98357a auf max. leise gestellt habe, aber auch mit dem MS6324, den wir für den Kopfhörer benutzen, zeigt sich das. Hab jetzt noch nicht versucht, das neueste ESP32-Arduino in Verbindung mit einer älteren Lib von dir zu betreiben.

Ich habe hier keine Reader mit RC522-I2C bzw. PN5180-LPCD. Ich erwarte, dass das von weiteren Leuten getestet wird, um diese Hardware abzudecken.

2

@Joe91 hat das Ganze jetzt noch erweitert.

a) rfid-gain für RC522 ist dazugekommen.
b) Eine Adaption hier und hier zum Erhalt der bisherigen Lautstärkekurven ist erfolgt.
c) Der Exception-Decoder wurde für’s Erste deaktiviert. Ich hoffe mal, dass sich da langfristig nochmal was ergibt, dass man das wieder aktivieren kann. Punktuell wird’s ja mal gebraucht.

3

So, die Autoerkennung ist jetzt gemerged im dev-Zweig. Auswirkungen hat dies auch auf die fertigen Firmwares, da hier die Notwendigkeit für die Unterscheidung zwischen RC522/PN5180 entfällt. Das reduziert die Anzahl der Binaries deutlich.

Ziel ist es, dass BT/noBT auch noch entfällt, wobei es aus meiner Sicht zusätzlich jedoch Sinn machen würde, Binaries in Englisch anzubieten. Also im besten Fall hätten wir dann für je alle vier Compile-Targets am Ende je zwei Binaries: Eines in Deutsch und eines in Englisch.

Die Adaption der Lautstärke ist über diesen Weg erfolgt. Der Exception-Decoder ist für’s Erste, wie gesagt, deaktiviert. Eine bessere Lösung haben wir derweil dafür leider nicht.

Ob LPCD und RC522-i2c funktionieren weiß ich nicht. Da es niemand testen wollte und ich es nicht brauche, ist es mir ehrlich gesagt auch egal.

4

ich bin zeitlich leider nicht zum Testen gekommen. Das hole ich aber noch nach, jetzt eben aus dem Dev.

LPCD und RC522-i2c nutze ich jedoch auch nicht.

Binaries in 2 Sprachen? Das Webinterface ist doch i18n. Ich verstehe nicht wo da welcher Mehrwert entsteht.

5

In der seriellen Ausgabe. Die haben wir sprachlich getrennt und das werde ich der Bequemlichkeit Willens auch nicht alles wieder rückgängig machen.

6

das hatte ich gar nicht auf dem Schirm, danke für die schnelle Antwort.
Achja, das mit dem zurückkurbeln versteh ich :slight_smile:

7

Ich verweise an dieser Stelle auch mal auf ESPuino around the globe. Nur um mal zu sehen, wohin ich ständig Kram verschicke.

8

Das ist ein super feature, und vielleicht ein Schritt näher an eine „universal“ firmware die auf allen Platinen läuft.

Meine Version mit PN5180 lief nach dem Update auf den neusten dev ohne Probleme weiter, also von meiner Seite keine Update-Schmerzen. Es wurde sofort korrekt erkannt und ich musste auch nichts manuell anpassen.

LPCD habe ich aus Stromspargründen seit längerem deaktiviert, da ich damit Probleme hatte. Habe das also leider auch nicht getestet.

PS: Zu dem Thema logging auf mehreren Sprachen: Das ist schon ein gewisser Luxus für so ein Projekt. Ich denke effektiv jeder, der sich die serielle Ausgabe anschaut, kann Englisch. Daher würde ich dazu raten, hier gleich eine Grenze zu ziehen und den Support für weitere Sprachen kategorisch auszuschließen.

9

Das sehe ich auch so, und zur Not bemüht man ein Übersetzungsprogramm. Mit englisch wäre ich auch fein. Im Worstcase würde man für jede Sprache einen Build machen und dann blähen sich die Builds auch wieder auf

10

Was bläht sich da auf?
Ein Build in Deutsch und einer in Englisch.

11

die Anzahl der Builds = Anzahl der Hardwareversionen x Anzahl der Sprachen
So hatte ich das zu mindestens verstanden

Keine Ahnung ob da noch weitere Sprachen dazukommen sollen.
Ich bin da aber entspannt - ich würde mit nur Englisch zurechtkommen. Deutsch ist aber auch gut…ich beherrsche beide Sprachen :slight_smile:

12

Im Grunde könnte man hingehen und und die Anzahl der automatisch gebauten Firmwares auf complete und lolin_d32_pro_sdmmc_pe reduzieren. Weil wer ttgo t8 nimmt, hat eh ein Custom-Board und wird selbst kompilieren müssen. Das dürften aber ohnehin nur wenige Leute sein (schätze ich). Und Lolin D32 pro ist ein ewig altes Profil noch aus der Anfangszeit, was nicht sonderlich viel kann.

Das würde die Anzahl der Firmwares dann (wenn BT immer einkompiliert ist) auf 2x2 reduzieren.