Speicherkarten-Daten auslesen zu langsam

Falsches Timing, zu hochohmige Spannungsteiler (falls der µC mit 5V 
läuft) usw.
Ich hatte mit 15MHz SPI Takt bisher noch nie Probleme.

Ja, das sollte reichen. Und in der anderen Richtung?

Kommt der µC mit den 3,3V Pegel zurecht? Da die Pegel vermutlich recht 
knapp als high erkannt werden, kann es sein, dass dadurch nochmal ein 
wenig Verzögerung hinzukommt, vor allem mit dem 4,7k Widerstand. Lass 
den mal weg.

Die Ausgangsspannungen interessieren hier nicht, die Eingangsspannungen 
sind wichtig:
Input High Voltage except XTAL1 and RESET pins: 0.6*VCC, also 3V bei 5V.
Bei 3,3V Spannung sind das nur 0,3V mehr, was eben zusammen mit dem 4,7k 
Widerstand eine zusätzliche Verzögerung bewirkt.
Versuch es mal ohne den Widerstand.

Die beste Lösung wäre ein HCT245 oder irgendwas in der Art, denn dieser 
hat Schaltschwellen bei etwa 0,8V bzw. 2V. Am Ausgang liefert er 0V/5V.

Ich meinte den HCT125 zusätzlich zum LVC245 für die andere Richtung.

Hast du den richtigen SPI Modus gewählt?
Und häng mal einen Pullup (irgendwas im Bereich 10-100k) an den Ausgang 
des SD Karte.

Hirbel wrote:

> kann kein pullup mehr dazwischen klemmen ohne die schaltung zu
> zerstören, ist schon fertig geätzt :(

Schlecht, der ist aber notwendig, siehe hier:
Beitrag "Re: Adressierung der Daten auf einer SD-Karte?"

Ansonsten passt der SPI Modus.

Vermutlich hat er den internen Pullup aktiviert, was bei dir nicht geht, 
da du den LVC245 dazwischen hast.

Ja, 8MHz ist das maximale.
Lag es nur an dem Pullup?

Nein.

Die 512Byte pro 7µs zweifele ich hiermit öffentlich an.

Hirbel wrote:

> Timer gestartet (mit TIMSK=0x04)
> -> Timerinterrupt jede µs->zähler wird erhöht, TCNT1 wird zurückgesetzt

Alle 16 Takte ein Interrupt? Vergiss es!

> Ausgabe der 512 Bytes (sind korrekt)
> und ausgabe des Zählers (7 µs)

Mit ein wenig Nachdenken hättest du eigentlich selbst drauf kommen 
können, dass dies nicht sein kann:
SPI hat 8MHz, also 8MBit/s. 512Byte sind 4kBit. Wenn du für 8bit 1µs 
brauchst, dann kannst du in 7µs maximal 56Bit übertragen, aber nie 
4kBit.

Ahaaa. Rein theoretisch sind 512Bytes gut einer halben ms drin, wenn 
Dein Controller nichts anderes mehr machen muß. Also macht Dein 
Controller die anderen 6 1/2 ms noch irgendwelchen anderen Kram. 
Vielleicht kannst Du da noch optimieren. Oder aber der Controller wartet 
auf ein Busy von der Karte. Da könnte dann nur noch das Kommando 
"MultiBlockRead" etwas helfen. Ich erreiche bei meinen Karten bei 16Mhz 
SPI (XMega@32Mhz) etwas über 400kByte/s beim Single Block lesen. Du 
kannst natürlich auch Deinen Controller übertakten. 25Mhz machen die 
meisten ATMEGAs problemlos mit.

Travel Rec. wrote:
> Ahaaa. Rein theoretisch sind 512Bytes gut einer halben ms drin, wenn
> Dein Controller nichts anderes mehr machen muß. Also macht Dein
> Controller die anderen 6 1/2 ms noch irgendwelchen anderen Kram.

Ja, nämlich das hier:

> TCCR1B=0x01;         //Prescaler 1 -> 16 MHz
> TCNT1=0x10000 - 16;  //---> 1 MHz -> jede µs
> ICR1H=0x00;
> ICR1L=0x00;
> OCR1AH=0x00;
> OCR1AL=0x00;
> OCR1BH=0x00;
> OCR1BL=0x00;
>
> Timer gestartet (mit TIMSK=0x04)
> -> Timerinterrupt jede µs->zähler wird erhöht, TCNT1 wird zurückgesetzt

Wenn der AVR jede µs einen Interrupt ausführt, dann geht da fast die 
ganze Rechenleistung drauf.
So eine Zeitmessung macht man anders:
Den Timer auf 0 setzen und starten. Im Overflow Interrupt eine weitere 
8/16bit Variable erhöhen. Nun hast du zusammen mit dem 16bit Timer einen 
24/32bit Zähler mit 62,5ns Auflösung und einem Messbereich bis 1s/256s.
Wenn du fertig bist, stoppst du den Timer mit TCCR1B=0;
Nun kannst du das Timer Register und die Variable auslesen und ausgeben.

Ich wette dann bist du mindestens doppelt so schnell.
Beim Lesen sind die SD Karten in der Regel sehr schnell, so dass fast 
nur der SPI Takt + Overhead zwischen den Bytes eine Rolle spielen. Ich 
schreibe sogar mit rund 100kByte/s mit einem mega8 @10MHz...

Du benutzt den Timer nicht als Timer zur Erzeugung eines Zähltaktes, 
sondern lässt den Timer direkt bis 65535 zählen. Bei 16MHz Takt gibt es 
so nur mit 244Hz einen Overflow Interrupt. Im Interrupt erhöhst du eine 
weitere Variable, falls ein Messbereich bis 4ms nicht reicht.

Irgendwie kommt mir das etwas komisch vor:
Wenn du vorher wirklich den Timer alle 1µs einen Interrupt hast 
ausführen lassen, dann wäre diese zu (4 Takte Interrupteintritt, 4 Takte 
um Register zu retten, und das ganze nochmal beim Verlassen, also 16 
Takte insgesamt, dann nochmal 10 Takte um eine 16bit Variable zu 
erhöhen, macht also mindestens mal 26 Takte. Deine erste Messung war 
vermutlich also komplett falsch.

Da deine zweite Messung fast dasselbe Ergebnis liefert, und bei der 
ersten Messung der µC eigentlich die ganze Zeit im Interrupt verbringen 
müsste, kann da irgendwas nicht passen.

Poete mal den Rest vom Code.

Hirbel wrote:
> meine interrupt routine sieht so aus:
>
> _timer1_overflow:
>   ST   -Y,R30
>   ST   -Y,R31
>   IN   R30,SREG
>   ST   -Y,R30
>   MOVW R30,R6
>   ADIW R30,1
>   MOVW R6,R30
>   LD   R30,Y+
>   OUT  SREG,R30
>   LD   R31,Y+
>   LD   R30,Y+
>   RETI
>
> Sind genau 22 Takte (Codevision compiler)...
> also ich weiß nich wo der fehler liegt :(

Wenn der Code (bzw. etwas ähnliches das du vorher hattest) 22 Takte 
braucht, er aber alle 16 Takte ausgeführt wurde, dann kann da was nicht 
passen.

Wenn du es nun anders machst, und immer noch das selbe rauskommt, dann 
kann da was nicht passen.

>wenn bei beiden Messungen 7 ms rauskommt, warum sollte es da einen
>Fehler geben, ich versteh das nich so ganz...

Weil 7ms das 7-fache davon ist, was der Controller eigentlich an Zeit 
braucht, um die Daten auf der Karte abzulegen. Wenn Kartenschreibzeit 
und andere Routinen im zeitlichen Verhältnis von etwa 1:1 vorliegen 
würden, würde ich ja gar nichts sagen. Aber so vertrödelst Du einfach 
irgendwo Zeit, die Du vielleicht andernorts brauchen könntest.

Hirbel wrote:
> na das mit den 22 Takten bekomme ich ja nun nicht kleiner hin...

Darum gehts ja auch nicht.

Ich machs mal an einem einfachen Beispiel:
Du liest ein Buch mit 512 Seiten.
Du liest nur 1h pro Tag, da du die restliche Zeit mit etwas anderem 
zubringst.
Jetzt liest du das Buch nochmal, diesmal liest du aber 23h pro Tag. 
Trotzdem brauchst du 512 Tage.
Wenn du beidesmal genausoschnell gelesen hast, dann muss irgendwo ein 
Fehler sein, denn dann kann das nicht stimmen.

Wenn du alle 1µs, also alle 16 Takte den Timer Interrupt ausführst, 
dieser aber 22 Takte braucht, dann
- passt die Zeitmessung nicht
- ist der Prozessor zu 22/23, also 96% mit dem Timer Interrupt 
beschäftigt

Wenn dein Code hierbei genausolange braucht, als wenn er nur z.B. 1% im 
Timerinterrupt verbringt, also 99% der Rechenleistung zum Lesen hat, 
dann kann irgendwas nicht stimmen.

Zeig also mein deinen ganzen Code!

Wie alt ist denn die SD Karte?
70kByte/s ist schnarchlahm. Die Zugriffszeit beim Lesen ist eigentlich 
vernachlässigbar klein (meist irgendwas im 2 stelligen µs Bereich). 
Zumindest hatte ich noch keine Karte, die länger gebraucht hat.

Achso, du liest nicht nur die Daten, sondern suchst erst noch den Sektor 
aus der Cluster Chain usw.
Das erklärt einiges.

Les mal z.B. 16x 512Bytes und mess dabei mal die Zeit.
Dann sollten deutlich >100kByte/s rauskommen.

Meine Erfahrung war bisher, das die Datenrate bei bis zu rund der Hälte 
des der SPI Frequenz liegt, also bei dir bei rund 4MBit/s=500kByte/s.
Hängt natürlich auch von der Geschwindigkeit des Prozessors usw. ab.

In der sd.c könntest du bei der Lesefunktion noch
*(buffer + i) = card_sendbyte(0xFF);
durch
*buffer++ = card_sendbyte(0xFF);
ersetzen, das sollte der Compiler deutlich besser optimieren können.

Und die card_sendbyte Funktion selbst, die solltest du als inline 
deklarieren, denn der Sprung + Rücksprung dauert fast so lange wie das 
Lesen selbst.
Und die Timeoutabfrage in der Funktion ist eigentlich auch unnötigt. 
Nach 16 Takte ist der SPI Transfer fertig, wenn nicht dann ist irgendwo 
was gewaltig schief gelaufen, da hilft dann auch keine Abfrage mehr.

Ansonsten sieht der Code gut aus. Wenn du mehrere Blöcke liest, und den 
Code wie angegeben etwas optimiert, dann sollten definitiv >100kByte/s 
rauskommen.

Versuch mal die Änderungen in die Software einzubauen, vor allem das mit 
dem inline sollte eigentlich rund 50% mehr Geschwindigkeit bewirken.

Hirbel wrote:
> ach naja ich lass das jetzt erstmal so, alles in asm umzuschreiben, da
> hab ich jetzt keine lust zu

Musst du auch nicht.
Mit dem Code von ELM-Chan erreiche ich >200kByte/s (alles in C).
http://elm-chan.org/fsw/ff/00index_e.html

> 70KByte sind ja 560 kbit/s das dürfte für mp3 anwendungen ausreichen?

Ja, sollten eigentlich. Mehr als 320kBit/s gibt es bei den normalen mp3s 
ja nicht.

Die Routinen von ELM Chan können glaube ich SDHC ausprobiert habe ich es 
noch nicht.