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.
> 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.
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.
