Refactoring der DEV Version

Ich habe ein paar Stunden verbracht und die DEV Version umgeschrieben.
Der Code ist jetzt lesbarer und C++ hat Einzug gehalten.
Ich habe mich bemüht, das alte Verhalten nicht zu ändern, außer dass nach dem Startup und nach dem Karte auflegen als Feedback ein kurzer Ton kommt.

Hier ist der PR

Es würde mich freuen, wenn mein Code Verwendung findet.

3 „Gefällt mir“

Klingt spannend. Lässt sich das in die Bestandsvarianten rein mergen? Wenn man z.B. den Affenfork oder den von Thomas L. benutzt? Oder ist der Umbau so grundlegend?

Ich glaube nicht, dass sich das so einfach mit dem Fork von @marco-117 oder @Thomas-Lehnert mergen lässt. Die sind beide ja auch jeweils relativ weit verändert.

Das wäre eine immense Arbeit. 5000 Codezeilen sind nicht Mal eben überarbeitet.

Dadurch, dass der neue Code viel einfacher wartbar ist, kann man die Features in den anderen Forks relativ einfach nachimplementieren. Welches Feature wäre denn am wichtigsten? Ich könnte ja dann mal probeweise das Feature auf einem Branch nachimplementieren.

Aber allgemein ist es immer blöd so viele Forks zu machen ohne zu mergen.

Aber, sagt mir einfach die Features und ich gebe mein bestes.

Hi @Boerge1, hab kurz rein geschaut. Sieht gut aus. Schön strukturiert. Hab mich spontan wohl gefühlt ;o). Da währe mir die ein oder andere Änderung leichter von der Hand gegangen.

Mir gings weniger um konkrete Features. War aus reinem Interesse, um die Leistungsfähigkeit von Github einzuschätzen.

Die Forks gibt es teilweise auch deshalb, weil es bei gewissen Funktionen zwei Meinungen gibt.
Ich speicher in meinem Fork die Fortschritte auf der RFID, das Original im EEPROM. Es gibt für beides Pro und Contra.

Mein komplettes Design, Eingaben zu erkennen und auszuwerten ist völlig anders als im Original.
Mir war es wichtig möglichst einfach unterschiedliche Eingabemedien einzubauen. Das macht es aber unter umständen für Einsteiger zu kompliziert. Welches Medium nehm ich? Wie bau ich das ein?
Da ist es einfacher bei drei/fünf Buttons zu bleiben. Der Rest ist eh mehr spielerei.

1 „Gefällt mir“

Ich finde, das wichtigste Feature, welches die original Software nicht bietet ist „Pause wenn Karte weg“.

1 „Gefällt mir“

Habe ich den Code richtig verstanden und das Feature „Pause wenn Karte weg“ soll folgendes machen:

  • Wenn die Karte entfernt wird, geht er in Pause
  • Wenn Pause/Play Button gedrückt wird, geht es an der Stelle weiter
  • oder wenn wieder eine Karte aufgelegt wird (auch wenn es die gleiche Karte ist) fängt es wieder von vorne an

Ist das so richtig?

Für obiges Verhalten ist das der PR

Das ganze ist ohne #ifdef implementiert, so dass man es ganz einfach in die Settings (EEPROM) packen kann.

Nicht ganz, wenn wieder eine Karte aufgelegt wird, muss unterschieden werden:

Ok, habe den PR erweitert. Jetzt wird weitergespielt wenn die Karte wieder aufgelegt wird.

1 „Gefällt mir“

Ich habe noch einen Bug gefixt (es wurde keine Pause gemacht, wenn die Karte entfernt wurde bevor der Track gestartet ist) und es gibt jetzt auch das Setting im EEPROM dazu.
Viel Spaß!

Ich habe dann meine beiden Pull Requests gemergt

  • neuer Mode: Hörbuch einzeln (es wird nur ein Titel gespielt und der Fortschritt wird gespeichert)
  • Pause wenn Karte entfernt wird

Wer will, kann das ja verwenden.
Wer neue Feature braucht, kann sich melden.

@Thorsten hat ja hier mal gespoilert, vielleicht gibts da eine Möglichkeit zur Zusammenarbeit?

Ansonsten, ich verwende @Thomas-Lehnert s Fork, weil ich einen LED-Ring verwende und da die Animationen gut implementiert sind, und mir die Akkustandüberwachung wichtig ist.

Hallo in die Runde,

ich habe an meiner Variante weitergearbeitet und alles mit einer State Machine implementiert.

Die Main Loop läuft jetzt jederzeit stabil mit 50 ms, so dass zusätzliche Feature (wie LED, …) damit leicht zu implementieren sind. Auch wird das Admin Menü jetzt nach einer Einstellung nicht mehr verlassen, sondern man kann mit der nächsten Einstellung weitermachen. Und man kann das Admin Menü nun an jeder Stelle abbrechen.

Der C++ Compiler benötigt jetzt die Option „-std=gnu++17“. Das kann man in der platform.txt einstellen. Einfach bei der Variablen „compiler.cpp.flags“ die Option „-std=gnu++11“ nach „-std=gnu++17“ ändern.

Viel Spass beim Ausprobieren!

1 „Gefällt mir“

Wie schon oben beschrieben habe ich weiter daran gearbeitet und habe jetzt eine stabile Version nach DEV gemergt. Damit ist das alles im Pull request

Folgende neuen Features sind implementiert:

  • völlig neues Logging
  • es lassen sich viele Sachen in der Datei const.hpp konfigurieren
  • Implementierung einer State Machine
  • alle Tracks werden beim Auflegen der Karte in eine Queue geschrieben und nicht erst beim nextTrack ermittelt
  • neuer Mode für Short Cut und Karte: wiederhole die letzte Karte
  • ein Short Cut lässt sich jetzt löschen (nach Auswahl des Short Cuts einfach das Admin Menü abbrechen)
  • Konfigurationsdateien für VS Code + plattformio

Achtung: es ist jetzt c++17 erforderlich. Wer nicht plattformio verwendet, muss die Datei plattform.txt editieren
compiler.cpp.flags=-c -g -Os {compiler.warning_flags} -std=gnu++17 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -MMD -flto

1 „Gefällt mir“