Fragen zum DFPlayer mini (Lexikon)

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • mac5150 schrieb:

      ...wenn "Play Random" aktiviert ist, kein Befehl senden, der umgesetzt wird.
      Meinst du den Befehl 0x18 Set random playback?
      Auch bei diesem Befehl kann das Modul über die serielle Schnittstelle gesteuert werden und nimmt alle Befehle an oder gibt Resultate zurück (z.B. die Anzahl der am Medium enthaltenen Dateien).


      Und nein, das vermute ich nicht, das habe ich soeben auf einem Steckbrett (nur das Modul und einen FTDI-RS232-USB Adapter) ausprobiert (wie auch schon das von meinem vorigen Post dazu).

      Wäre auch irgendwie unlogisch wenn keine weiteren Befehle angenommen werden sollten.
      IMHO kann man das Modul sogar aus dem Sleep-Mode wieder aufwecken (was ich aber jetzt nicht ausprobiert habe).

      Kann es sein, dass an deinem Modul noch weitere Hardware angeschlossen ist (zB. Steuertasten)?
      Denn die habe ich nicht. Ich verwende nur das nackte Modul (da steht auch nur DFPlayer Mini drauf und ist von Banggood) in der Standardbeschaltung und Steuerung nur über die RS232-Schnittstelle.

      Wird der Befehl auch mit CRLF abgeschlossen? Sonst hätte ich da keine Idee mehr außer, dass sich das Modul "verschluckt" und dann in der Folge einfach keine weiteren Befehle annimmt.
    • @Zitronenfalter Zuerst einmal vielen Dank für Deine Mühe.
      Mein Freund Willie und ich haben gestern den ganzen Abend lang mit dem Modul experimentiert.
      In das angehängte Programm haben wir Deine komplette neue "Library"einkopiert:


      Steuerschaltung für Tourbus T3 - V3-4 .bas


      Versuchsaufbau:

      • ATMega32 @8 MHz, 5 V; genaue Beschaltung s. Programmanfang
      • I2C-LCD
      • 9er Tastenfeld via Widerstandsnetzwerk am Mega-ADC (in einigen Projekten schon erfolgreich genutzt)
      • DFPlayer mini; Beschaltung exakt gemäß Deinem Lexikon-Eintrag; 2 GB SD-Karte mit 20 MP3s

      Was uns aufgefallen ist:
      Da nichts Genaues dazu erwähnt war, blieb der Busy-Pin des Players beim 1. Versuchsaufbau unbeschaltet.
      Der 1. Versuchsaufbau exakt nach Beschreibung brachte das Ergebnis:
      Keine Reaktion des Players auf serielle Befehle.
      Eine nachträgliche Beschaltung des Busy-Pins mit einer LED sollte eigentlich nur den Zustand (aktiv/inaktiv) angezeigen.
      Plötzlich wurden auch Befehle angenommen.
      Ergebnis:
      Der DFPlayer mini lässt sich ohne Beschaltung des Busy-Pins - entweder LED - 1k - GND oder 1k - GND nicht ansprechen.
      Busy - 10k - GND, Busy - einen definierten Input-Pin des Mega32 oder Busy - LED - 1k - Vcc lässt ihn auch inaktiv bleiben.
      Mit dem FTDI bist Du doch auch nur an RX und TX gegangen?

      Mit beschaltetem Busy-Pin lassen sich Kommandos ausführen und auch Daten wie Mp3_getcurrentdevice() abfragen.
      Die LED geht aus, wenn ein Kommando abgearbeitet wird.
      Sobald das Kommando abgearbeitet ist, geht die LED wieder an, und es werden weitere Kommandos angenommen.
      Sobald Deine Sub Mp3_playrandom() (ja, 0x18) aufgerufen wird, die ja endlos abgearbeitet wird (LED ständig aus), geht nichts mehr.
      Der Player spielt munter weiter und nimmt keine seriellen Kommandos mehr an.
      Wir haben die entsprechende Zeile für den automatischen Randomstart (792) auskommentiert, um das Tastenfeld zu testen; es funktioniert tadellos;
      Lautstärke auf Maximum setzen, File 6 abspielen in beliebiger Aufrufreihenfolge und beliebig oft.
      Mp3_playrandom() lässt sich nur einmal aufrufen.
      Was nicht funktioniert, ist, die Wiedergabe via Call Mp3_stop() zu stoppen. Weder den einzelnen Song 6 noch die Shuffle-Funktion.
      Auch das Verändern der Lautstärke wird nicht angenommen, wenn geshuffled wird.

      Fragen:
      Wie soll der Busy-Pin ohne angeschaltete Test-LED korrekt gehandhabt werden?
      Wie kann die Wiedergabe unterbrochen werden?


      Viele Grüße
      Mathias & Willie

      Heisenberg bei einer Radarkontrolle:
      Polizist: "Wissen Sie, wie schnell Sie waren?"
      Heisenberg: "Nein. Aber ich weiß genau, wo ich jetzt bin!"

    • mac5150 schrieb:

      Da nichts Genaues dazu erwähnt war, blieb der Busy-Pin des Players beim 1. Versuchsaufbau unbeschaltet.
      Wie soll der Busy-Pin ohne angeschaltete Test-LED korrekt gehandhabt werden?

      Unbeschaltet kann und soll der Pin dann bleiben, wenn man den nicht benötigt.
      Und noch als Hinweis, das ist vom Modul aus gesehen ein Low-aktiver Ausgang was bedeutet, befindet sich das Modul im Abspielmodus geht dieser Ausgang auf Low, wird nicht abgespielt ist dieser High.
      Das bedeutet dann auch im Umkehrschluss:
      • Soll die LED das abspielen anzeigen, ist diese (über einen Vorwiderstand) gegen Vcc zu schalten.
        Der Eingangsport eines µC wird gegen Low gezogen.

      • Soll die LED den Ruhemodus anzeigen. ist diese (über einen Vorwiderstand) gegen GND zu schalten-.
        Ob der Strom aber ausreichend ist eine LED korrekt zu treiben, sei dahingestellt.

      mac5150 schrieb:

      Eine nachträgliche Beschaltung des Busy-Pins mit einer LED sollte eigentlich nur den Zustand (aktiv/inaktiv) angezeigen.
      Plötzlich wurden auch Befehle angenommen.

      Ein äußerst unlogisches Verhalten. Bei längerem Überlegen würde ich meinen, dass das Modul über diesen Pin Strom saugt und das Modul erst dadurch (voll) funktioniert. wenn das so ist gibt es aber IMHO nur noch drei Möglichkeiten.
      • Das Modul ist nicht korrekt angeschlossen (es sind da ja z.B. zwei GND-Pins die aber meinen Versuchen zur Folge ohnehin intern verbunden sind)
      • Das Modul ist einfach defekt
      • Es ist (zumindest "innerlich") KEIN DFplayer mini - Modul
      Ich habe jetzt ein noch original verpacktes Modul ausprobiert und das funktioniert bei mir genauso wie das erste von mir verwendete sofort erwartungsgemäß.

      mac5150 schrieb:

      Mit dem FTDI bist Du doch auch nur an RX und TX gegangen?
      Ja, VCC mit Diode in Reihe weil das Modul keine 5V mag, 2x GND, Lautsprecher sowie RX und TX.
      RX sogar direkt ohne Vorwiderstand oder Entkoppeldiode was wohl solange egal ist solange man das nur am Steckbrett hat und Nebengeräusche die wohl bei direkter Verbindung zu einem µC entstehen, so diese im Versuchsaufbau überhaupt Auftreten an der Stelle vernachlässigbar sind. Im Echtbetrieb ist die entsprechende Pegelanpassung oder Entkopplung jedenfalls vorzusehen!

      Busy habe ich am Steckbrett gar nicht beschalten, weil auf dem Modul ja auch noch eine LED drauf ist (bei einem Modul bkau, beim nächsten war die orange), die den Zustand anzeigt (bei Befehl 0x18 (Random Loop) leuchtet diese LED übrigens dauernd, bis das ich mit dem Stopp-Befehl das abspielen beende).

      Übrigen, falls das nicht bekannt, ist, das Modul sendet auch "ungefragt" die eine oder andere Statusmeldung zurück.

      Ich habe übrigens auch versucht, das Modul nur an jeweils einen GND-Anschluss anzuschließen. Selbst dann funktioniert alles einwandfrei.
      Und wohlgemerkt ausschließlich mittels über die serielle Schnittstelle übertragene Kommandos weil ich gar keine Tasten angeschlossen habe.
      Sende ich z,B. den Startbefehl für einen Track mehrmals hintereinander wird der ausgewählte Track selbstverständlich erwartungsgemäß sofort ebenso oft neu gestartet obwohl dieser ja noch abgespielt wird.

      IMHO wäre alles andere ja auch nicht nicht sinnvoll, der serielle Empfang muss einfach immer funktionieren weil alles andere dann nicht brauchbar wäre.
      Würde es da entsprechende Einschränkungen geben, könnten verschiedene Befehle gar nicht existieren oder funktionieren und wären einfach sinnlos (welchen Sinn würde ein möglicher Stopp-Befehl haben wenn man den nicht während dem Abspielen absetzen könnte?).
      Darüber hinaus würde ich davon ausgehen, sollten entsprechende Einschränkungen vorhanden sein, würden diese zumindest mit einem Satz im Datenblatt erwähnt werden oder man würde zu diesem doch weit verbreiteten Modul dazu irgend etwas im Internet finden.

      Als Quintessenz ergibt sich für mich nur noch, wenn von den oben bereits erwähnten drei Punkten keiner zutreffen sollte, solltest du einfach beherzt ein anderes Modul ausprobieren.

      Auf meinen steht jedenfalls auf allen DFplayer Mini (aber sonst auch nicht mehr) drauf und die sind nicht nur von BangGood) und die verhalten sich auch so, wie es die diversen im Netz auffindbaren Datenblätter beschreiben.

      Ich würde an deiner Stelle einfach ein anderes Modul versuchen. Das muss einfach funktionieren.
    • Update: Mehrere Module - leider aus derselben Quelle getestet: Eines funktioniert nicht mal mit den Player-Tasten, der Rest hat den oben beschriebenen Fehler.
      Vielleicht kommt ja Ersatz schon vor Weihnachten.

      Viele Grüße und ein dreifach donnerndes Ho!
      Mathias & Willie

      P.S. @Zitronenfalter was hat denn der eifrige Stefan gelöscht? Gerne per PN.
      Heisenberg bei einer Radarkontrolle:
      Polizist: "Wissen Sie, wie schnell Sie waren?"
      Heisenberg: "Nein. Aber ich weiß genau, wo ich jetzt bin!"

    • Da hast du offenbar Pech mit der Lieferung. Ich denke, dass die "neuen" endlich funktionieren werden, tun sie hier bei mir ja auch.

      Kannst du was zu meiner Bibliothek sagen (ist die jetzt besser verständlich), oder warten wir noch, bis du die neue Lieferung hast?

      mac5150 schrieb:

      was hat denn der eifrige Stefan gelöscht?
      Da hatte sich nur die Forensoftware etwas verschluckt und meinen Antwortpost gleich dreimal veröffentlicht und ich hatte um Entfernung der überzähligen Post ersucht. Also nix böses ;)
    • Böses hätte ich nie erwartet!
      Eher eine OT-Überreaktion... ;)

      Deine Bibliothek ist klasse! Ich werde sie noch etwas erweitern, wenn Du erlaubst.
      Bitte warte noch die Lieferung ab. Ich möchte noch mit Ordnern und Ads experimentieren und dazu Beispielprogramme
      auf Basis des Mega8 ff beisteuern.

      LG
      Mathias
      Heisenberg bei einer Radarkontrolle:
      Polizist: "Wissen Sie, wie schnell Sie waren?"
      Heisenberg: "Nein. Aber ich weiß genau, wo ich jetzt bin!"

    • Update: a_64_3a718cae Willie und ich sind happy. Wir Beide haben jetzt DFPlayer mini Module, die tun, was sie sollen!
      Nein, noch keine Neulieferung. Die bisher Halbfunktionierenden verrichten jetzt klaglos ihren Dienst (eines ist wirklich defekt, hat auch auf externe Tasterschaltung nicht reagiert).
      Wie kommt's?
      Willie und ich haben uns überlegt, dass saubere serielle 3V3 Signale sinnvoll wären.
      Diese Problematik sind wir unterschiedlich angegangen:


      1. Willie
      Willie braucht die zusätzlichen Pins seines 5V Mega32. Daher hat er für den DFPlayer mini einen 3V3 Spannungswandler und einen Pegelwandler verbaut:

      Willie Player an 3.3V.jpg

      Funktioniert prächtig!
      Auch mit dem Vorschlag, Vcc des Players via Diode auf +5V zu legen, läuft alles:

      Willie Player über Diode an 5V.jpg

      Bemerkenswert ist, dass sich die Lautstärke des angeschlossenen Lautsprechers trotz höherer Eingangsspannung nicht verändert hat.
      Unser Schluss: Mehr Spannung bringt nix.


      2. Ich
      Ja, ich wollte es mir eigentlich einfach machen und alles auf 3V3 auf dem Steckbrett aufbauen. µC (328P), I2C-LCD und DFPlayer mini.
      Der Ärger mit dem 3V3 LCD ist für Interessierte im entsprechenden Thread nachzulesen... a_67_e210de67
      Jetzt funktioniert alles. Genau so, wie gewünscht.


      @Zitronenfalter Da Du Dir die Mühe gemacht hast, uns eine schöne "Library" zur Verfügung zu stellen, ist es klar, die korrigierte und auch
      erweiterte Datei nebst Kommentaren und Beispielprogrammen / -soundfiles hier Dir "zurückzugeben".

      Dauert noch etwas - das Testen braucht seine Zeit und da wartet Silvester...

      LG
      Mathias & Willie
      Heisenberg bei einer Radarkontrolle:
      Polizist: "Wissen Sie, wie schnell Sie waren?"
      Heisenberg: "Nein. Aber ich weiß genau, wo ich jetzt bin!"

    • Hallo zusammen,

      ich führe gerade die Befehle aus den verschiedenen mir vorligenden Datenblättern zum DFPlayer mini zusammen.
      Eine sch...öne Arbeit, die ich mir da aufgehalst habe a_67_e210de67 . Teils widersprüchliche Angaben. Egal. Wird durchgezogen und getestet.
      Bei der Lektüre der Datenblätter fiel mir auf, dass der DFPlayer mini ein kleines Plappermäulchen ist. Er gibt offenbar viele Meldungen zurück,
      die man sicherlich auswerten und sinnvoll einsetzen könnte:
      Bloß wie? ?(
      Mein Test-Setup: USBASP@3V3, ATMega328P, I2C 2004 LCD (da hätte ich gerne die Ausgaben...), DFPlayer mini und kleiner Lautsprecher.


      Hat jemand ein paar Zeilen Code, mit dem ich das "Geplappere" abfangen, evtl. speichern und auf dem LDC anzeigen kann?
      Basis ist die "Library" von @Zitronenfalter, ergänzt durch µC-Definition, I2C-LCD und eine Test-Do-Loop-Schleife; nicht wert, es hier zu posten.

      Viele Grüße
      Mathias
      Heisenberg bei einer Radarkontrolle:
      Polizist: "Wissen Sie, wie schnell Sie waren?"
      Heisenberg: "Nein. Aber ich weiß genau, wo ich jetzt bin!"

    • mac5150 schrieb:

      Bei der Lektüre der Datenblätter fiel mir auf, dass der DFPlayer mini ein kleines Plappermäulchen ist. Er gibt offenbar viele Meldungen zurück,die man sicherlich auswerten und sinnvoll einsetzen könnte:
      Bloß wie?
      Das ist mir durchaus bekannt, allerdings hatte ich festgestellt (und da konnte ich kein Muster erkennen, dass die eine oder andere "Info" auch mehrfach kam.
      Man bekommt z.B. auch was zurück wenn ein Track fertig/gestoppt ist (und soweit ich mich jetzt erinnere kam das dann und wann auch mindestens zeimal).
      Was man zurückbekommt ist vom Aufbau das gleiche Datentelegramm was auch gesendet wird.
      Die Informationen stecken dann in den beiden Datenbytes. Was die Daten aussagen, ergibt sich durch das zurückgegebene Befehlsbyte.

      Wie die die Informationen auslesen kannst ersiehst du bei jenen Befehlen meiner LIB, die Informationen holen (das sind jene die mit GET beginnen wie z.B.
      GetCurrentDevice:
      Inputbin #255 , aSend(0) , 10
      MP3_GetCurrentDevice = aSend(6)
      InputBin holt hier zehn Bytes vom seriellen Buffer, in aSend(6) steht hier die relevante Information
      Je nach Befehl kann auch aSend(5) wichtig sein (dies ist das HighByte der Info)
      Alle anderen Bytes sind IMHO irrelevant (aSend(3) enthält noch das Befehlsbyte, der Rest entspricht der Beschreibung, die empfangene Prüfsumme ist logischerweise auch anders soll sie ja zum gesendeten Datentelegramm passen.

      Das mehrfache im Buffer könnte man insofern abfangen, indem man vor dem senden eines Befehls zuerst den Buffer löscht, den Befehl sendet, zehn Zeichen holt. Ob das auch immer funktioniert ist aber immer noch Glückssache.
      Weil ich mir auch das folgende Szenario vorstellen könnte:
      • Buffer wird gelöscht
      • Modul sendet genau in diesem Moment z.B. den Stopp (mit Pech mehrmals, kommt eventuell auch auf das Modul an, meine hier tun das jedenfalls)
      • Befehl wird gesendet
      • Modul sendet die Antwort
      Und schon stimmt wieder was nicht weil im Buffer noch Teile enthalten sein können die nicht der eigentlichen Antwort entsprechen.
      Man müsste dann die empfangenen Bytes noch auf deren Plausibilität überprüfen bzw. überlesen und das nächste Telegramm auswerten.
      Dann passt es wieder, nur ob man diesen Aufwand für dieses kleine Modul treiben möchte :D
      Auf der sicheren Seite ist man IMHO dann, wenn man die GETs im Ruhemodus (es wird nichts abgespielt) ausführt.
      Das wäre der geringste Aufwand, (man könnte ja auch noch das BUSY auswerten und den Befehl dann "verweigern" oder einen entsprechenden Wert zurückgeben um das weiter auswerten zu können.
      Möglichkeiten gibt es da genug ;)

      Ach ja, um das auf LCD ausgeben zu können, muss das Ergebnis entsprechend umgewandelt werden, weil die meisten Ergebnisse im nicht druckbaren Bereich sind.
      Im Befehl MP3_GetStatus habe ich eine Möglichkeit aufgezeigt wie man Informationen aufbereiten kann die man dann wiederum mit Select Case auswerten könnte oder man schreibt den Befehl gleich so um, dass der entsprechenden Text zurück gibt. Das ist alles Geschmackssache.
    • Vielen Dank für Deine ausführliche Antwort!

      Die Get-Befehle (auch die neuen) funktionieren jederzeit 1A.
      Schau' mal hier (Ausschnitt aus meiner "Datenblatt-Zusammenführungs-Datei"):

      CMD [hex]BedeutungParameter (16 Bit)Bedeutung Parameter und WeiteresUnterschiede / FragenChecked?Sub/Func ZF-Library (*=mac5150)


      Plappermaul…

      0x3ASpeichermedium wurde angeschlossen1, 2, 41 = USB, 2 = TF-Karte, 4 = PC
      0x3BSpeichermedium wurde getrennt1, 2, 41 = USB, 2 = TF-Karte, 4 = PC
      0x3CEnde abgespielter Datei Nr. … auf USB-Medium1 – 255
      0x3DEnde abgespielter Datei Nr. … auf TF-Karte1 – 255
      0x3EEnde abgespielter Datei Nr. … auf Flash-Medium1 – 255



      Mir geht es darum, das "Geplappere" abzufangen und auszuwerten, das im Hintergrund läuft. Das ist nicht unbedingt abhängig vom Busy-Pin, so wie ich es verstanden habe.

      LG
      Mathias
      Heisenberg bei einer Radarkontrolle:
      Polizist: "Wissen Sie, wie schnell Sie waren?"
      Heisenberg: "Nein. Aber ich weiß genau, wo ich jetzt bin!"

    • mac5150 schrieb:

      Mir geht es darum, das "Geplappere" abzufangen und auszuwerten, das im Hintergrund läuft. Das ist nicht unbedingt abhängig vom Busy-Pin, so wie ich es verstanden habe.
      Ehrlich gesagt verstehe ich jetzt nicht, was du unter "geplappere" verstehst.
      Erkläre mal bitte genauer was da im Hintergrund laufen soll.

      Die einzigen "ungefragten" Datentelegramme" (die "berühmten" zehn Byte) kommen doch nur wenn ein Track beendet wurde.
      Wurde das Modul aufgefordert einen Loop zu spielen, kommt bei halt jedem einzelnen Trackende des Loops ein Telegramm.
      Ansonsten kommt doch nur was auf Aufforderung zurück (zumindest bei den Modulen die ich hier habe).
      Soll heißen, ist das Modul ruhig ist auch die Kommunikation ruhig und da ist gar kein "geplappere" (zumindest ich sehe da nichts mit dem Terminalprogramm :D ).

      EDIT
      Ich vermute, du meinst, das was da am Anfang kommt wenn das Modul erstmals stromversorgt wird.
      Das kann man natürlich entsprechend verarbeiten, der Befehl MP3_Init ist da wohl ein Ansatz.


      Function MP3_Init() As Byte
      Local fX As Byte
      MP3_hSetCmd
      MP3_aSend(MP3_Array3) = &H0C ' Reset
      MP3_Clear_SerialBuffer
      MP3_hSendCmd
      #IF MP3_COMPORT = 0
      Inputbin #254 , MP3_aSend(MP3_Array0) , 10
      #ELSE
      Inputbin #255 , MP3_aSend(MP3_Array0) , 10
      #ENDIF
      If MP3_aSend(MP3_Array3) = &H3F And MP3_aSend(MP3_Array6) <> 0 Then
      MP3_Init = 1
      Else
      MP3_Init = 0
      End If
      End Function

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Zitronenfalter ()

    • Zitronenfalter schrieb:

      Die einzigen "ungefragten" Datentelegramme" (die "berühmten" zehn Byte) kommen doch nur wenn ein Track beendet wurde.
      Wurde das Modul aufgefordert einen Loop zu spielen, kommt bei halt jedem einzelnen Trackende des Loops ein Telegramm.
      Ich bin ja noch am Anfang mit der Datenblattzusammenführung...
      Es wäre aber wertvoll für mich, wie ich z. B. bei Trackende das Telegramm direkt abfange und ggf. andere Befehle gebe.
      Momentan ist das so gelöst, dass mit einem Timer die Tracknummer abgefragt und auf Veränderung überprüft wird.
      Nicht besonders elegant.

      LG & Nachti
      Mathias
      Heisenberg bei einer Radarkontrolle:
      Polizist: "Wissen Sie, wie schnell Sie waren?"
      Heisenberg: "Nein. Aber ich weiß genau, wo ich jetzt bin!"

    • mac5150 schrieb:

      Es wäre aber wertvoll für mich, wie ich z. B. bei Trackende das Telegramm direkt abfange und ggf. andere Befehle gebe.
      Ich sehe da nur zwei Möglichkeiten
      1. Entweder man wertet das BUSY-Signal aus und fragt bei einer Pegeländerung die serielle Schnittstelle ab oder
      2. man kontrolliert ob Daten im seriellen Buffer anliegen
      Beides muss IMHO in einer Schlefe oder als Timer ablaufen, andere Möglichkeiten sehe ich da jetzt nicht.
      Erschwerend kommt noch dazu, dass man unterscheiden muss ob eine Hardware- oder Software-Schnittstelle verwendet wird weil bei einer Softwareschnittstelle ein Buffer gar nicht möglich ist.

      Eine Softwareschnittstelle könnte man eventuell an einem INT-Port lösen und so per Interrupt feststellen, dass an der Schnittstelle eine Pegeländerung stattgefunden hat und man das Datentelegramm nun sofort auswerten kann (nachdem es erst mal eingelesen wurde).

      Ich frage mich aber schon wieder, ob dieser Aufwand gerechtfertigt ist :D .

      Ich würde einfach das BUSY-Signal auswerten, das ist sicher die einfachste Lösung,
    • Hallo zusammen,

      ich kann Snickers nicht mehr sehen! (Wenn's mal wieder länger dauert...)

      Die verschiedenen Datenblätter habe ich in einer Tabelle zuerst befehlsmäßig nebeneinandergestellt und dann veri- oder falsifiziert.
      Da gab es ziemliche Unterschiede :cursing:
      Die letzte Version meiner Arbeitstabelle hänge ich an; vielleicht freut sich jemand, dass ich die Befehle ins Deutsche übersetzt habe. DFPlayer mini Kommandos 1.2.zip

      Zur "Library": Wenig Korrektur aber viele Befehle hinzugefügt. Davon wurden (fast) alle getestet (s. Tabelle)

      Zum DFPlayer mini: Erstaunlich, was das Käferchen alles kann. Schade, dass viele Befehle über die FAT-Nummer und nicht über die Dateibezeichnung laufen.
      Das funktioniert aber in den nummerierten Ordnern.

      @Zitronenfalter Hier die überarbeitete Library. Ich hoffe, Du findest sie akzeptabel. DFPlayer mini Library 1.1.bas
      Auf jeden Fall haben Willie und ich mächtig dazugelernt - auch dafür ein herzliches Dankeschön.

      Ich habe auch noch ein selbstablaufendes Demoprogramm "verbrochen", das ein paar Funktionen zeigt: MP3playerMini-BASCOM Mac 1.6.bas
      Konfiguration siehe Header und hier der Inhalt der SD-Card: SD.zip

      Es bestehen auch noch Fragen, doch die in einem anderen Post.

      Viele Grüße
      Mathias
      Heisenberg bei einer Radarkontrolle:
      Polizist: "Wissen Sie, wie schnell Sie waren?"
      Heisenberg: "Nein. Aber ich weiß genau, wo ich jetzt bin!"

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von mac5150 ()

    • mac5150 schrieb:

      Hier die überarbeitete Library. Ich hoffe, Du findest sie akzeptabel.
      Ja, ich habe die aber auch nochmal überarbeitet und jetzt sogar soweit ergänzt, dass sich jetzt alle Befehle die ihr aus den verschiedenen Datenblättern zusammengesucht habt enthalten sind.
      Inwieweit die einzelnen Befehle aber tatsächlich funktionieren, kann nur die Gemeinschaft sagen, da nicht jeder ermittelte (vor allem speziellerer) Befehl auf jedem Modul was da inzwischen so herumschwirrt auch funktionieren wird.
      Als Beispiel nenne ich mal das neue MP3_GetVersion welches bei deinen Modulen xFF zurückgeben wird, bei meinen aber wiederum x05 zurück gibt.

      Außerdem hat es sich ergeben, dass in der neuen LIB jetzt der einige wenige Befehle umbenannt wurden (was IMHO der einheitlichen Lesbarkeit geschuldet war) wodurch man so nun eindeutiger erkennen kann, was der jeweilige Befehl tun wird.

      mac5150 schrieb:

      Ich habe auch noch ein selbstablaufendes Demoprogramm "verbrochen", das ein paar Funktionen zeigt
      Diese Basis habe ich dann auch verwendet um das ein wenig optisch zu "verschönern" und auch für verschiedene Controller verwendbar gemacht und so auch ins Lexikon einfließen lassen weil ich mir auch schon dachte, dass ein Demo ganz sinnvoll wäre.