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.
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.
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.
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ß!
@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.
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.
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