mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Speicherkarten-Daten auslesen zu langsam


Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich hab ein (kleines) Problem bei der Ansteuerung meiner SD Karte. Das 
Auslesen von Daten aus einer Datei usw. klappt wunderbar, aber es ist 
mir zu langsam.

Ich steuere die Karte via SPI an, mein CPU Takt beträgt 16 MHz...
Bei einem Prescaler von 8 (2 MHz) funktionierts noch, beim Prescaler 4 
(4 MHz) nicht mehr, woran kann das liegen?
Ich dachte die SD Karten kommen mit einem Takt von 20 MHz klar (laut 
Datenblatt)??

Danke schonmal im Voraus.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die schnelle Antwort.

Ich benutze ein Pegelwandler (74LVC245) mit einer "Propagation delay 
time" von maximal 7 ns, das dürfte doch locker für 8 MHz Takt reichen??

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das sollte reichen. Und in der anderen Richtung?

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andere Richtung? also du meinst SDO von der SD-Karte aus?
Na die Leitung hängt an einem Eingang vom 245er chip, der Ausgang geht 
dann zum MISO pin am µC (dazwischen noch ein 4,7K Widerstand)..

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
im Datenblatt vom ATmega128 steht nur die Output Spannung

Output Low Voltage
(Ports A,B,C,D, E, F, G) :     0,7 V

Output High Voltage
(Ports A,B,C,D, E, F, G) :     4.2 V


Aber beim TWI Steht bei Input High: 0,7*Vcc das wären 3,5 V und 3,3 V 
wären dann schlecht...
die Frage ist dann nur, warum es bei 2 MHz überhaupt funktioniert?


Gibt es ne schnelle Möglichkeit den Pegel anzuheben ohne noch so ein IC 
zu verwenden und ohne die Spannung des µC zu verändern?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hirbel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
naja aber ich kann den LVC245 nicht durch den HCT ersetzen sondern 
brauch wieder ne extra schaltung...mist, hätt ich mir vorher überlegen 
sollen..


Ohne den Widerstand gehts garnicht, nicht mal bei nem Takt von 125 KHz, 
mit dagegen einwandfrei, wieder bis 2 MHz...

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab mal die schaltung (oben) mitgeschickt

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So sieht mein SPI Init aus:

SPI_DIR |= (1 << MOSI) | (1 << SCK) | (1 << SS);
SPI_PORT |= (1 << MOSI) | (1 << SCK) | (1 << SS);

SPI_DIR &= ~(1 << MISO);

SPCR = (1 << MSTR) | (1 << SPE);

SPCR |= (1 << SPR0) | (1 << SPR1);                                SPSR 
|= (1<<SPI2X);


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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also auf dem Board, das vom Thread-Teilnehmer benutz wird,
ist auch nirgends ein Pullup widerstand dran:

http://heldt-intern.dyndns.org/uploads/pdf/Experim...

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum hab ich den eigentlich dazwischen??
ich versuch mal ne umleitung direkt zum µC pin zu bauen und aktiviere 
ebenfalls den internen pullup..

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, jetzt läufts mit 8 MHz....mehr ist ja nicht drin beim Hardware SPI 
(16 MHz CPU Takt) oder??

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, 8MHz ist das maximale.
Lag es nur an dem Pullup?

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja es lag daran und an den LVC, keine ahnung warum ich die Outputdaten 
von der SD Karte noch dadurch jagen wollte....

ich habe jetzt eine Rate von 512 Bytes in 7 µs
das sind doch knapp 70 MB/s, kann das stimmen?

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein.

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dachte ich mir,
bitte einmal vorrechnen was nun wirklich rauskommt :)

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die 512Byte pro 7µs zweifele ich hiermit öffentlich an.

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
meine messung habe ich wie folgt vorgenommen:

Sd Karte initialisiert.

Datei geladen.

Timer wie folgt initialisiert:

TCCR1A=0x00;
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

Ein Block (512 Bytes) angefordert

Timer gestoppt (mit TIMSK=0x04)

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


wo ist der Fehler?? Kann ja nur beim timer sein

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
na ich habe ja glaube geschrieben das es nicht sein kann...
habe den fehler gefunden...beim zurücksetzen von TCNT1 stand ein alter 
wert drin....
so komme ich auf 7 ms und grad mal 71 KByte/s
...langsam....

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Benedikt:

Kannst du das nochmal genau erklären mit dem timer und der Zeitmessung?
Hab ich grad nich wirklich verstanden....

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also mit den Timereinstellungen komme ich auf folgendes:

16bit Zähler = 1 --> 4,096 ms

TCNT1 = 41860  -->  2,61625 ms

= 6,71225 ms

Das ist keine wirkliche Verbesserung...was mache ich falsch??

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :(

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Poete mal den Rest vom Code.

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
welchen rest denn?
die ganzen sd-karten routinen für die ansteuerung?
neee das ist zu viel...

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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
na das mit den 22 Takten bekomme ich ja nun nicht kleiner hin...

ich könnte den timer langsamer laufen lassen, so das ich garkeine 
Intterupt routine brauche, sonder TCNT1 ausreicht, also nie der overflow 
erreicht wird...
aber ich wette da kommt dann das gleich raus

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sooo der timer lief jetzt mit 2MHz.
TCNT1 hatte den Wert 13423, das sind wieder 6,7115 ms
die Messung ist also korrekt oder nich?

es stimmt schon, das ich zeit vertrödele, in dem ich auf die SD karte 
warte (busy wait) aber das geht doch nun mal nich anders ??

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hirbel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
ja die ist schon entwas älter und sieht sehr mitgenommen aus...

anbei mal die sd.c, fat32.c (nicht alles auf meinem mist gewachsen) und 
die main.c (steht auch anderes zeug drin -> nicht beachten).

also ein wenig zeit geht auch drauf, weil er zu einer bestimmten stelle 
in einer datei springt...aber das ist nicht viel (hab ich schonmal 
auskommentiert)

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hab mal ne neuere Karte genommen, da sinds jetzt immerhin "nur" noch
6,6555 ms ;)

kann es evtl. sein, das es an der takt oder datenleitung liegt?
hab dafür nur ein 0,2 mm kupferlackdraht genommen und alle leitungen 
zusammengedreht....???

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
okay, ich hab das mit dem buffer abgeändert und 10 mal die gleichen 512 
bytes gelesen (ohne Seek, also vom anfang der datei)...

und man glaubt es kaum, aber ich komme auf 7,067 ms für 512 bytes :(

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Am Besten liest du mal 10.000 Bloecke und stopst mit der Uhr ;-)

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ach naja ich lass das jetzt erstmal so, alles in asm umzuschreiben, da 
hab ich jetzt keine lust zu 70KByte sind ja 560 kbit/s das dürfte für 
mp3 anwendungen ausreichen?

Kannst mir aber auch deine routinen zur verfügen stellen, wenn du willst 
:)


Vielen Dank aber erstmal für doe Hilfe.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hirbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
okay, werd den code mal testen..

wie sieht es eigentlich mit SDHC karten aus??
funktionieren die auch (mit dem gleichen code für normale SD karten) 
oder funktionieren die anders oder garnicht?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.