Ein wenig Software bekomme ich hin, für die großen Ideen brauche ich aber jemanden der Lust hat meine Idee umzusetzen.
Deshalb hier eine super Idee, stürzt euch drauf.
Die Hardware der einzelnen TonUINOs ist durch die super Dokumentation ja fast identisch.
Ein paar Anpassungen, aber meist von Leuten die in der Lage sind sich selbst zu helfen.
Alles andere ist per #define zu lösen, was auch scheinbar ganz gut funktioniert.
Wie praktisch wäre jetzt ein Programm, das die vorhandene Hardware nutzt und beim press auf forward die Datei mp3/0008.mp3 spielt.
Und wenn einer V+ drückt, spielt sie die 0009…
Wenn eine Karte erkannt wird, spielt sie die 10, danach die Nummer die als letztes Byte auf der Karte steht
Ihr versteht? Also anstatt, „was steht in der Konsole, wenn du dies, das oder jenes machst“
einfach ein
„Spiel dieses Programm auf und versuche was nichts auslöst“
Ich habe sowas auch schon überlegt, aber du kannst dabei aber nicht unterscheiden warum der Track nicht gespielt wird. Das kann ja daran liegen, dass die SD-Karte falsch befüllt ist, die Software nicht an den Player angepasst ist oder weil der Button nicht funktioniert.
Deshalb hilft es am Ende kaum etwas. Vor allem musst du zum Aufspielen der Testsoftware den TonUINO auch mit dem Computer verbinden. Ob du dann Software aufspielst oder die Konsole startest ist dann auch egal.
Der Nachteil ist auch, dass die TonUino Software durch das Testprogramm überschrieben wird. Wenn dann die Probleme auf Diskrepanzen zwischen Hard und Software zurückzuführen sind, führt das kaum zum Ziel, weil ja dann die Software quasi nicht mehr vorhanden ist. Es würde nur Sinn machen, um die vorhandene Hardware auf Funktion zu prüfen, kann aber nicht viel beitragen um Hardwareprobleme aufzudecken, die durch Inkompatibilitäten zur Software entstanden sind.
Ein denkbares Scenario wäre aber ein Testprogramm zu schreiben, das unter Verwendung der in der aktuellen Touino-Software verwendeten Bibliotheken die Hardwarekomponenten einzeln in einem vorgegebenen Prüfablauf testet.
z.B.
alle Tasten hintereinander weg auf Shortpress und Longpress abfragen.
den RFID Reader auf Schreib unf Lesefunktion prüfen.
den DF-Player auf die Grundfunktionen prüfen:
Zählen der Ordner, wenn unterstützt
Zählen der Tracks in einem Ordner
Abspielen von Tracks im Ordner
Prüfen der Funktion „Abspielen von Adverts“
dabei Kontrolle ob hier z.B ein nexttrack aufgerufen wird
oder andere Meldungen kommen
Lautstärkeänderungen
Das ganze möglicherweise bei unterschiedlichen Konfigurationen.
Um eine Ausgabe über die Konsole wird man wohl nicht herumkommen, denn wenn z:B der DF-Player nicht funktioniert, erhält man auch keine akustischen Meldungen.
Nicht gleich entmutigen lassen und die Idee „beiseite packen“.
Ich denke ein ganz ordentlicher Teil deiner Idee ist schon in der LOG-Funktion über die Konsole enthalten.
Das ganze schwächelt m. M. nach durch die etwas magere und im Forum sehr verstreute Dokumentation der Konsolenausgaben.
Ich habe schon versucht, bei „Debugging mit der Konsole“ von @Gute_Laune zumindest bei den Com-Errors des DF-Players etwas „nachzulegen“.
Da gibt es bestimmt noch weitere wertvolle Hinweise, die wir dort sammeln können.
Das ganze Thema „Fehlersuche“ würde schließlich durch einen strukturierten Leitfaden, der systematisch und logisch den Fehlersuchenden (auch Laien) quasi „bei der Hand“ nimmt und durch die einzelnen Schritte führt, „alltagstauglich“ werden und wohl auch viel Zeit des Suchens ersparen.
Ein entsprechend aufgebautes listenartiges Dokument würde im ersten Schritt schon sehr helfen. Die „Königsdisziplin“ wäre dann eine Flowchart-ähnliche Dartsellung mit Anweisungen, Prüfungen und Verzweigungen.
Ich habe da schon einiges (noch nicht „druckreif“) im Kopf und würde mich daran versuchen. Wenn Ihr also Lust habt, nur immer her mit Euren Ideen und vor allem Eurem Know-How
@raznz_snasna
Moin Stefan,
bin, wie ich schon schrieb, dabei, ein „Kochrezept“ zur Fehlersuche zu konzipieren.
Daraus ist nun eine Aufbau- und Inbetriebnahmeanleitung mit integrierten/ anschließender Fehlersuche geworden.
Bei den einzelnen Bauphasen bediene ich mich z. Zt. bei den, in der Arduino IDE, mitgelieferten Beispielprogrammen zu den Baugruppen Arduino, RC522 und Df-Player. Für die Buttons gibt es da auch noch etwas.
Alles zusammengenommen kommt schon einer Testsoftware ziemlich nahe. Ich werde versuchen, mit meinen Möglichkeiten alles zusammen in einen Sketch zu integrieren. Mit einem derartigen Sketch könnten dann die Baugruppen und ihre (Grund-) Funktion gezielt getestet werden. Nicht unbedingt besser, aber ich denke schneller und zielführender als Interpretationen des Verhaltens eines kompletten Tonuino.
Das Dokument ist noch nicht reif zur Veröffentlichung. Bei Interesse lasse ich mir aber schon gern per PN „in die Karten gucken“. Vorschläge und Anregungen nicht nur gewünscht sondern fast schon erbeten
Ja, die Idee mit der LED-Signalisierung werde ich weiter verfolgen, da ich das Programm " Blink" schon verwende, um Datenverkehr zwischen PC und Arduino zu prüfen (einfach durch erfogreiches flashen) und auch noch die Funktionsfähigkeit des Arduino zu bestätigen (indem es tatsächlich blinkt"
In Teil 2 läuft dann die Versionabfrage und ein Selbsttest des RC522-Moduls. Ein positives Ergebnis könnte man durch Änderung der Blinkfrequenz bzw. Rhytmus anzeigen.
Für den DF-Player und die Buttons dann ähnlich. Mal sehen, wie dann eine aussagefähige Blinksignalisierung aussehen könnte (die ich auch noch programmieren kann).
Etwas gedämpft ist meine Zuversicht hinsichtlich des DF-Players durch das Thema „TD5580A“
So, jetzt habe ich ein paar Codeschnipsel aus den diversen mitgelieferten Beispielprogrammen (zu Arduino, RC522 und dem DF-Player) zusammengesucht und so kombiniert, dass nun einige grundlegende Tests laufen und auch die Ergebnisse mit der on-board LED des Arduino signalisiert werden können.
So recht sind mir für die Blinkerei aber noch keine klar identifizierbaren und unterscheidbaren Codes eingefallen. Deshalb immer noch parallel dazu die Ausgabe der Ergebnisse in der Konsole.
Da das Programm ja ohnehin extra auf den TonUINO geladen werden muss, ist ein PC mit Konsolenausgabe sowieso verfügbar.
Dieses Programm dient hauptsächlich zur Prüfung der Verdrahtung und der Kommunikation zwischen den Modulen:
Prüfung 1:
Verbindung und Kommunikation zwischen Arduino und dem PC
Prüfung 2:
Verbindung und Kommunikation zwischen Arduino und RFID-Kartenleser
Prüfung 3:
Verbindung und Kommunikation zwischen Arduino und DF-Player
Prüfung 4:
Verbindung und Funktion zwischen Arduino und den Tasten
(z. Zt. noch nicht implementiert)
Eine wirklich 100%ige Kontrolle der Module auf Funktionsfähigkeit kann die SW natürlich nicht leisten - nur eben bestätigen, dass alle Module korrekt verdrahtet sind und die erforderliche Kommunikation zwischen den Modulen funktioniert.
Wer Lust und Zeit hat, kann das Programm als Testversion gerne herunterladen und austesen. Vorschläge und Hinweise sind erbeten und willkommen.
----------------------------------------------------------------------
RC522 Test: OK
----------------------------------------------------------------------
----------------------------------------------------------------------
DFPlayer Mini Test
Initialisierung DFPlayer ... (kann 3~5 Sekunden dauern)
DFPlayer Mini online.
----------------------------------------------------------------------
----------------------------------------------------------------------
Button Test START (innerhalb von 2 Sekunden eine Taste drücken)
Lautstärke - gedrückt
ZURÜCK-Taste gedrückt
Pause-Taste gedrückt
VOR-Taste gedrückt
Lautstärke + gedrückt
Button Test ENDE
----------------------------------------------------------------------
Testzyklus abgeschlossen
Reset des TonUINO und neuer Testdurchlauf
----------------------------------------------------------------------
Zum testen bitte oben die ZIP-Datei nochmals herunterladen (ist aktualisiert)
!!! ACHTUNG !!!
Die Prüfung des DF-Players funktioniert anscheinend nicht mit jedem Chipsatz.
Ein Player mit Chip GD3200B wird mit Verbindungsfehler angezeigt obwohl er prima funktioniert.
Ein Player mit Chip MH2024K-24SS hingegen führt zu posittivem Testergebnis (wie oben gezeigt).
Player mit anderen Chipsätzen konnten bisher nicht getestet werden.
