Letzte Hoffnuung hier im Forum eine Erklärung zu folgenden Phänomenalen Problem zu bekommen. Habe hier ein DF-Player Modul. Das ist ein Steckmodul, welches MP3 Files von einer Micro SD Karte abspielt. Das hat auch eine Serielle Schnittstelle, worüber man dieses Steuern kann. Zum Testen und zum erstellen einer Routine die alle Steuerbefehle für den DF-Player beinhaltet habe ich ein ATmega8 benutzt. Diesen habe ich auf 9600 8N1 eingestellt und alles klappt mit dem ATmega8 prima. Jetzt habe ich ein Projekt, wo dieser DF-Player integriert werden soll. In diesem Projekt verwende ich einen ATXmega256A3U. Weil dieser nur mit 3,3 Volt arbeitet, habe ich einen Wandler-Chip ADG3304 zur Wandlung der RX und TX Leitung eingesetzt. Das Problem: Obwohl ich die selbe Datei mit den Steuerroutinen ungeändert vom ATmega8 verwende funktioniert die Kommunikation mit dem Modul jetzt nicht mehr. In der Datei mit den Steuerroutinen sind auch nur Ladebefehle die entsprechende Werte laden, keine Befehle die auf Register o.ä. zugreifen. Also das IN OUT STS und LDS Problem gibt es hier nicht! Habe auf den ADG3304 zuerst getippt und deswegen mal eine RX Leitung von einem COM eines PC´s an den RX Eingang des DF-Player Modules angeschlossen. So konnte ich sehen, das exakt das richtige hier am DF-Player Modul auch ankommt. Aber das DF-Player-Modul sendet mir einen Datenerror zurück. Hat also das was ich dem Modul gesendet habe nicht verstanden, obwohl ich es am PC im Terminalprogramm "überwacht" habe und im Terminal Programm auch richtig angezeigt wird. Meine Versuche: 1. Habe den ADG3304 durch eine einfache Schaltung mit BSS138 Mosfet´s ersetzt, die sich schon mehrfach bewehrt hat. Ergebnis = selbe Sache. Im Terminalprogramm am PC wird der Richtige Steuerbefehl angezeigt, Das Modul meldet aber Datenerror. 2. Habe die Taktfrequenz des ATxmega von 32MHz auf 2MHz geändert, und die USART Baudrate der Frequenz angeglichen. Ergebnis: Selbe! Am Modul-Pin RX kommt exakt das richtige an, aber das Modul sendet Datenerror zurück. 3. Habe das Modul herausgenommen und in die Testplatine mit dem ATmega8 gesteckt. Modul funktioniert einwand frei. Ergebnis: Modul ist nicht defekt! 4. Habe das Modul zurück in die ATxmega Platine gesteckt und wieder funktioniert es nicht. Habe das Modul in der ATXmega Platine belassen und die Testplatine mit den ATmega8 nur über die RX und TX Leitungen sowie + und GND verbunden. Ergebnis: Wenn das Modul über ATmega angesteuert wird funktioniert es auch in der Projektplatine. 5. Habe noch eine andere Testplatine wo auch ein ATxmega256A3U drauf ist. Habe diese auch nur mit + GND und RX und TX einer seriellen Schnittstelle verbunden. Ergebnis: Selbe Problem! ATxmega sendet zwar die richtigen Werte, aber das Modul sendet Datenerror zurück! 6. Ich habe mir noch mal die Datenblätter vom ATmega8 und auch vom ATxmega256A3U angesehen, in der Hoffung hier etwas zu finden, was ich im ATxmega eventuell falsch gemacht habe. Aber da gibt es eigentlich keinen UNterschied, was die serielle Schnittstelle als USART betrifft. Baudrate, Parität, Datenlänge, Stopbit und nichts exotisches... Duch die Kontrolle am RX Pin des Modules konnte ich ja auch sehen, das exakt die richtigen Daten mit 9600 angekommen sind. Jetzt die Frage: Warum geht es mit der seriellen Schnittstelle eines ATmega8, aber nicht mit einem ATxmega256A3U????? Was könnte da noch die Ursache sein???? Ich habe keine Idee mehr und kann auch in keiner Weise verstehen, wie soetwas überhaupt auftreten kann... Wäre deshalb sehr dankbar, wenn jemand von ähnlichem mit einer Lösung berichten könnte.
Hast du ein Oszilloskop greifbar?
Tom schrieb: > Was könnte da noch die Ursache sein???? Bitrate passt nicht wirklich. Was ist denn die Taktquelle des ATXmega256A3U?
> habe ich einen Wandler-Chip ADG3304 Da steht aber was bösens im DB: > To ensure correct operation of the ADG3304, the circuit that drives the > input of the ADG3304 channels should have an output impedance of less than > or equal to 150 Ω and a minimum peak current driving capability of 36 mA. Die meisten mir bekannten µC GPIOs haben <=20mA bei 3,3V Betriebsspannung. Das könnte hier durchaus Probleme bereiten -> Oszi.
:
Bearbeitet durch User
Tom schrieb: > Weil dieser nur mit > 3,3 Volt arbeitet, habe ich einen Wandler-Chip ADG3304 zur Wandlung der > RX und TX Leitung eingesetzt. Dir ist klar dass du das "DF-Player Modul" auch einfach mit 3,3V betreiben kannst und den Level-Shifter gar nicht brauchst?
Jim M. schrieb: > Da steht aber was bösens im DB: Auch aus diesem Grund hatte ich den ADG3304 auch als erste Fehlerquelle im Blickfeld, auch weil ich schon einmal mit diesem Level Shifter IC Probleme hatte. Deshalb habe ich eine einfache MOSFET Schaltung erst einmal ausprobiert, die sich in der Vergangenheit immer bewährt hatte. Mike J. schrieb: > Dir ist klar dass du das "DF-Player Modul" auch einfach mit 3,3V > betreiben kannst und den Level-Shifter gar nicht brauchst? Im "Datenblatt", wenn man das so bezeichnen darf, des DF-Player Moduls steht von 3,2 bis 5,0 V Typisch 4,2 V. Da Typisch 4,2 V steht, habe ich mir gedacht, das 3,3V eventuell etwas zu Nahe an dem Minimum sind und wollte einfach nur sicher gehen, das es auch problemlos arbeitet. Das "Datenblatt" existiert auch in verschiedenen Formen, da es auch sehr viele andere MP3-Module gibt, die den selben Chip verwenden. Da gibt es dann auch andere "Datenblätter" wo auch andere Funktionen beschrieben sind, die im Datenblatt des DF-Player nicht aufgeführt sind, jedoch aber auch mit diesem funktionieren... Also alles nicht ganz so korrekt. Aber man ist ja froh über alles an Informationen was man so von der Chinaware so bekommen kann... SOOOOOOOOOOO!! jetzt habe ich aber den Fehlerteufel aufgespürt!!!! Erst einmal besten Dank an alle die sich die Zeit genommen haben, sich das große Problem durchzulesen und Tips geschrieben haben. Das Problem ist natürlich wie immer ein ganz anderes... Der Df-Player bekommt immer einen Befehl bestehend aus jeweils 10 Bytes gesendet. Darin sind an der Position 8 und 9 auch 2 Bytes welche für die Checksumme dienen. Da die Berechnung der Checksumme im ATmega8 super funktioniert hat, hat es auch mit dem ATmega8 geklappt. Im ATXmega256A3U habe ich heute Morgen festgestellt, das aber auf einmal aus unerklärlichen Gründen das 9. Byte nicht richtig berechnet ist. Obwohl die exakt selbe Berechnungsroutine verwendet wurde, stimmte das 9. Byte nicht! Nach stundenlanger Suche habe ich den Übeltäter nun erkennen können. Die Checksumme wird im ATXmega wie auch im ATmega8 ordentlich berechnet. Habe mit das Berechnete Ergebnis anzeigen lassen. Das 9. Bit wurde aber trotzdem falsch zum DF-Player gesendet. Deshalb auch der Datenerror! Jetzt musste ich herausfinden, was zwischen der Berechnung und dem senden passiert, das der Wert auf einmal ein ganz anderer ist. Die Lösung: Am Ende der Checksummenberechnung, verbleiben die Bytes 8 und 9 im Register r16 und r17. Das ist auch so gewollt, weil die Senderoutine der seriellen Schnittstelle, immer den Wert aus r16 raussendet. Nach dem senden von r16 (Byte8) wird r17 in r16 verschoben und nun auch gesendet. Die Senderoutine verwendete (jetzt nicht mehr!) r17 aber auch für die Statuskontrolle der Seriellen Schnittstelle und hat deshalb den Checksummenwert Byte 9 verändert. Die Senderoutine des ATmega8 verwendete aber r18 für die Statuskontrolle und hat deshalb das Byte9 nicht verändert. Es war sehr, sehr Schwierig dieses herauszufinden... Aber glücklicherweise funktioniert es jetzt auch mit dem ATXmega!
Tom schrieb: > Die Senderoutine verwendete (jetzt nicht mehr!) r17 aber auch für die > Statuskontrolle der Seriellen Schnittstelle Das hört sich nach einem Fehler in der Bibliothek an. Welche Bibliotheken nutzt du ASF? (Die welche direkt beim AVR-Studio mitgeliefert werden?) Schreibst du deinen Code in C ? Zeig mal was du am Code verändert hast.
Tom schrieb: > Es war sehr, sehr Schwierig dieses herauszufinden... Deshalb programmieren die meisten ja auch in C, damit man vor solchen und vielen anderen Fallgruben sicher ist. Ein Compiler nimmt einem die komplette Variablenverwaltung ab und ist dabei 100% fehlerfrei. Er weiß ganz genau, wann eine lokale Variable nicht mehr benötigt wird und kann dann das Register für die nächste Variable verwenden. Nie wieder muß man sich mit Push/Pop abquälen.
Peter D. schrieb: > Ein Compiler nimmt einem die komplette Variablenverwaltung ab Ja, und ist dabei nur in einem Code-Baum recht effizient. Wälder, z.B. in Form von Interrupts mag er garnicht, da wird er zwischen mäßig und katastrophal schweinemäßig ineffizient... > Nie wieder muß man sich mit Push/Pop abquälen. Muß man sich auch in Asm nicht. Wenn man die Sache beherrscht... Richtige Programmierer tuen das. Die anderen nehmen C oder noch was ineffizienteres... Die richtigen Programmierer können die volle Bandbreite souverän und nehmen das, was am besten zum Problem passt. Wobei die Wahl sehr leicht fällt, wenn das Problem nur in Assembler überhaupt lösbar wird... Naja, C-only-Typen wählen dann natürlich einen fetteren Controller. Böses Problem, das ist nicht C-kompatibel auf der Zielplattform. Verdammt, kann sich das nicht einfach dem Mainstream anpassen? Die Ineffizenz des Compilers ist natürlich NIEMALS schuld...
c-hater schrieb: > Richtige Programmierer tuen das. Die anderen nehmen C oder noch was > ineffizienteres Ist dir eigentlich bewusst, was solche Ergüsse über dich aussagen? Wer mindestens den Verstand einer Maus hat, kann dich nicht (mehr) ernst nehmen.
Stefan ⛄ F. schrieb: > Ist dir eigentlich bewusst, was solche Ergüsse über dich aussagen? > > Wer mindestens den Verstand einer Maus hat, kann dich nicht (mehr) ernst > nehmen. c-hater übt sich halt als Profi-Provokateur. Er hat schon zuviel miterlebt als dass das hier Geschriebene / Berichtete immer so spurlos an ihm vorüber geht. Jedem Tierchen sein Plaisir-chen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.