VS1053 SPI- und CLKI Frequenz

>mit 320kb/s mp3s funktioniert es nicht.

320kb/s ist schon heftig. Oder sind es 320kbit/s?

Das schaff ich mit einem Atmega32 und VS1001 bei 8MHz Clock;)

Sry, sind selbstverständlich alles Bits bei den MP3s :)

holger schrieb:
>>mit 320kb/s mp3s funktioniert es nicht.
>
> 320kb/s ist schon heftig. Oder sind es 320kbit/s?
>
> Das schaff ich mit einem Atmega32 und VS1001 bei 8MHz Clock;)

Kannst du mir wohl fix in Worten erklären wie du die Weiterleitung 
gemacht hast?

Ich vermute zwar nicht dass es daran liegt aber vielleicht habe ich 
meinen Buffer auch falsch umgesetzt.
Ist ein 4096Byte Fifo.
In der ISR wird das Byte lediglich reingeschoben.
in der "Main" werden sie weitergeschickt und sobald 2048Byte frei sind 
wird ein 0xFF zum PC geschickt als Auslösen für das Senden weiterer 
2048Bytes.
Ich habe schon Testweise versucht das Senden von 2048Byte über SPI und 
das Empfangen von 2048 Bytes voneinander zu trennen um das Senden nicht 
von der ISR ständig unterbrechen zu lassen. Es macht aber garkeinen 
Unterschied.

>Betreibe nen VS1053 an nem M644, der liest MP3 vonner SD Karte mit FAT32
>und schubst das aufn VS ohne Probs.
>M644 = 12MHz
>SPI = 6MHz

Bei mir ATmega32 mit 16MHz Takt.
Holt die Daten auch von SD und zeigt noch 2x Temperatur von zwei DS1821
und Uhrzeit und Datum vom DCF77 Empfänger auf einem DOGM128 an.
VS1001, DOGM und SD Karte hängen alle am selben SPI.

Martin Wende schrieb:
> Baus also lieber aufn Puffer um, dass wenn er nurnoch zu 50% gefüllt ist
>
> neue Daten ansausen.

Vorab vielen Dank für die Hilfe. Im Nachhinein weiß ich leider nicht wo 
ich die fehlerhafte
Der Artikel von Matuschek ist sehr lehrreich. Ich werde als erstes die 
SPI-driver von Atmel rauswerfen und die Sendesequenz nach seinem Schema 
umbauen.

Allerdings ist mir noch das Thema SPI-Takt und Bufferung unklar.

Ein SPI-Takt von 8Mhz dürfte den VS1053 sehr ins schwitzen bringen in 
Fällen bei denen SCI-Register gelesen werden.
Der höchste CLKI Takt des VS liegt bei 55,3Mhz und wird durch das setzen 
des SC_MULT auf 4,5 erreicht (bei 12.288Mhz Quarz). Maximale Frequenz 
für das Lesen ist dann
(XTALI * SC_MULT) / 7
12.288Mhz * 4,5 / 7 = 7,899 Mhz :(

Was ich auch noch nicht ganz verstehe ist das behandeln des Buffers auf 
dem xMega.

Da die USART baud erheblich höher(1M) ist als die zu haltende 
SPI-Sendegeschwindigkeit muss der xMega doch Rückmeldung über den 
Füllstand seiner Buffer liefern und somit Daten "holen" oder verstehe 
ich das falsch?

In meiner derzeitigen Implementierung wird die Rückmeldung bei 50% 
Bufferfüllstand gesendet was das nachfüllen auf 100% am Stück auslöst.
Um zeit bei der Überwachung des Füllstandes zu sparen habe ich einen 
festen Zeitinterval realisiert.
Zu beginn werden 2048Bytes empfangen (50%). Anschließend werden weitere 
2048Bytes angefordert(Füllung auf 100%) und während diese empfangen 
werden werden die ersten 2048Bytes verschickt. Sind die ersten 
verschickt werden wieder 2048 angefordert und die 2. 2048Bytes werden 
verschickt.
Durch die Wahl einer Datenpaket-Größe von 2048Byte möchte ich die Anzahl 
an Rückmeldungen und somit Verzögerungen auf der Windows-Machine 
möglichst klein halten.
Gibt es da eine optimalere lösung?

Gruß Max

Ich betreibe die USB-Verbindung über einen CP2102 im USBXpress 
Modus(kein COM-Port) unter Verwendung der SiLabs Treiber.

Eine ungenaue Zeitnessung auf Hostseite(C#->Stopwatch) ergab eine 
Übertragungszeit von 22ns für 2048 Bytes was auf ca. 93kByte/s schließen 
lässt.

Aber das USB-Host-Argument leuchtet ein.


Das auslegen des Füllstands auf einen Pin macht keinen Sinn da bei einer 
Puffergröße von 4096Bytes und einer Paketgröße von 2048Bytes der Puffer 
immer befüllt bleibt
Beispiel:
Füllstand 50%:
xMega fordert 2048Bytes vom PC
xMega sendet vorhandene 2048Bytes "zeitgleich" während angeforderten 
Bytes eintreffen.
xMega wartet auf Abschluss der USB-Übertragung (Wäre interessant zu 
wissen ob es überhaupt dazu kommt)
Füllstand wieder 50%:

Das wiederholt sich für die Länge der MP3.

Max schrieb:
> von 22ns für 2048 Bytes

*ms