Hi,
nachdem ich nun den SD_kartenleser von Holger Klabunde zum Laufen
gebracht habe, würde ich gerne die Übertragungsgeschwindigkeit ein
bisschen "pimpen". Das Maximum was ich derzeit schaffe ist
Schreiben von 128 Byte Blöcken mit: 100 kb/s
Lesen von 128 Byte Blöcken mit: 100 kb/s
Anhand der Test die Holger´s zip File anbeiliegen kann man allerdings
bis zu 300 kb/s schaffen bei einem Takt von 16 MHz und einem Teiler von
4.
Deswegen schreibe ich nach der Initialisierung in das SPCR-Register für
die Bits SPR0 und SPR1 jeweils eine 0. Das SPI2X Bit lasse ich auf 0.
Somit müsste ich einen 4 Teiler haben und mit 4 MHz takten. Leider
funktioniert das Schreiben dann nicht mehr. Bei einer Einstellung von 01
und SPI2X = 1 funktioniert alles, allerdings ändert das setzen von SPI2X
in meinem Fall an der Geschwindigkeit nichts obwohl im Datenblatt steht,
dass dann ein 8 Teiler wäre und kein 16 Teiler.
Ich verwende einen ATMEGA32 mit 5V VCC und verwende Spannungsteiler auf
den Leitungen.
Matthias wrote:
> Ich verwende einen ATMEGA32 mit 5V VCC und verwende Spannungsteiler auf> den Leitungen.
Kleine Frage, wie groß sind denn die Spannungsteiler dimensioniert?
KLeiner ok, aber mit den Werten komm ich ja gerade mal auf 2,9 V. Ich
dachte die Datenleitungen hätten Pegel so um die 3,3 bis 3,6 V. Bei
etwas längeren Leitungen wohl nicht so gut oder ?
es geht darum den Strom nicht so stark zu begrenzen sonst sind die
Flanken nicht so gut und es dauert länger bis die Karte einen
Flankenwechsel erkennt.
Es funktioniert nun, leider ändert sich auch bei einer Takteinstellung
von SPR0 und SPR1 jeweils eine 0 nicht die kb/s. Bleiben bei ca. 128
kb/s. Das kann doch nicht an der Karte liegen oder ?
Oh doch, das ist möglich. Eine meiner Karten schreibt
nur mit 30kB/s. Die ist einfach so lahm. Lesen tut sie
dafür mit 300kB/s. Wie schnell ist denn das lesen ?
FAT-Buffer benutzt ? Das hilft beim lesen nicht viel,
aber einige Karten schreiben damit schneller.
Das ist aber alles noch meilenweit von heutigen Kartenspeeds weg. Das
müsste doch schneller gehen, oder ??
Die Karten können doch heute bis 20 MB/s, selbst lahme Standardkarten
gehen oft über 2 MB/s.
Wo liegt denn hier das Problem ??
Das kann sehr wohl an der Karte liegen...
der SPI-Modus wird ja "normalerweise"(*) (also in der Kamera, im
Cardreader, etc) nicht benutzt, kann schon sein dass der so langsam ist.
Test mal ne andere Karte dagegen.
(*) außer zum Initialisieren, aber da ist die Geschwindigkeit ja relativ
egal
Lesen und Schreiben sind ungefähr gleich schnell. Ich hab eine DS Mini
karte mit Adapter von Sandisk und die schaft meines Erachtens wesentlich
schnellere Geschwindigkeiten. Hab hier im Forum irgendwo gelesen, dass
man bei den Dingern auch einen High Speed Modus einstellen kann, dann
können die aber angeblich sogar 25Mb/s. Naja egal, aber Holger bekommt
angeblich bis zu 300 kb/s hin, mir würden 200 reichen, aber 130 sind mir
noch zu wenig, kann es an den Spannungsteilern liegen ? könnte da ja
noch ein bissal runtergehen. Oszi könnte doch da Wissen schaffen, wenn
die Flanken nicht steil genug sind. Wie oben nachzulesen verwende ich
jetzt die kombi UA/UE = 1kOhm/(1kOhm+500 Ohm)
>Naja egal, aber Holger bekommt angeblich bis zu 300 kb/s>hin, mir würden 200 reichen, aber 130 sind mir>noch zu wenig, kann es an den Spannungsteilern liegen ?
Ich krieg sogar mehr hin mit meinem neuesten Programmcode.
Die 400kB/s hab ich schon geknackt. Aber nur mit meiner
schnellsten Karte ! Die meisten meiner Karten liegen viel weiter unten.
Ein paar schaffen ums verrecken keine 200kB/s. Beim schreiben
jedenfalls.
Sogar eine nagelneue 2GB SD Karte nicht. Auch nicht auf nem ARM7 bei
15MHz SPI :( Bei 15MHz SPI sind mir sogar drei Karten ausgestiegen.
Das mal nur so nebenbei.
Der SPI Modus hat nichts mit dem MMC oder SD Modus zu tun.
Man kann nicht mal sagen das neue große Karten im SPI Modus
besonders schnell sind. Meine schnellste ist eine 256MB MMC plus
von extrememory.
Kleiner Nachtrag: Die meisten meiner Karten sind beim lesen
erheblich schneller als beim schreiben.
Bist du sicher das dein ATMega32 auch mit 16MHz läuft ?
Schonmal überlegt, dass es auch an der Software liegen kann? ;) Bringt
ja nix wenn du mit ner irren Geschwindigkeit die Bytes einzeln in die
SD-Karte pumpst, aber die Bytes immer nur stundenweise 'reinreichst.
@ Simon
>Schonmal überlegt, dass es auch an der Software liegen kann?
Guter Hinweis. Meine Messungen beinhalten nur Maximalwerte
um sie vergleichen zu können. Die Daten müssen im realen Leben
aber auch noch irgenwo her kommen. Dann gehts so richtig runter
mit dem Tempo.
Gruß
Holger
holger wrote:
> Dann gehts so richtig runter> mit dem Tempo.
Jup, oder andersherum gesehen: angenommen du willst eine Datei über
einen eingebauten Webserver an einen Client schicken. Jetzt wirds
langsam.
Übrigens: Die 100kb/s sind schon nicht allzuschlecht.
Und achja: Ich konnte bei meinen SD-Karte (Ich weiß nicht mehr die Größe
der Spannungsteiler-Widerstände. Sind SMD und es steht drauf: 1800 und
3300. Ich meine dass es 1k8 und 3k3 waren) die SPI Schnittstelle bis
10MHz (FCPU/2 bei 20MHz) takten und das haben die alle noch mitgemacht
ich denke mal das die SPI Modus einfach mal um den Faktor 4 langsamer
ist da nur eine Datenleitung benutzt wird statt 4 außerdem wird der AVR
einfach zu langsam sein, neuere SD-Karten werden ja mit bis zu 50 MHz
getaktet also kein Wunder wenn hier die Datenrate so niedrig ist, wenn
der AVR vielleicht höchstens 1 MHz zu schieben vermag. Vielleicht könnte
man hier mit ein paar Schieberegistern arbeiten an die man die Daten
parallel übermittelt und dann extern schneller takten tut um die Daten
dann schneller raustakten zu können als es der AVR macht. Die neuen MMC
4.0 Karten sollen 8 Datenleitungen haben vielleicht wäre das ne
Überlegung wert gerade weil man die Daten parallel aus dem AVR
rausbekommt und das Programm dann auch schneller abläuft.
Den Kartenleser von Holger Klabunde kenne ich nicht, gibts dazu irgenwo
einen Link wo man sich das Projekt mal anschauen kann?
@ Thomas
Sicher wäre es schön wenn man statt SPI mit nur einer
Datenleitung 4 oder 8 Datenleitungen benutzen könnte.
Dann musst du aber Mitglied im Club werden. Kostet
ja nur ein paar tausend Euro im Jahr. Der Hacken an der
Sache: Du darfst deinen Code nicht mehr frei rausgeben.
Achso wusste nicht das die das Geheimhalten und Geld dafür verlangen
aber mit einem Logic-Analyzer müsste man doch dahinterkommen. Gibts da
nichts aus der Linux-Ecke?
dann setzt doch auf Compact Flash ein paar Latches und die Sache läuft
rund und vor allem schneller weil parallel und der µC kann nebenher noch
andere Sachen erledigen als sich nur ums schieben zu kümmern.
Wenn ihr aber bei SPI bleiben wollt könnte man die fertigen Daten wo
also alle sdrin ist, Start-Stop Funktion, Adresse, Byte usw. in ein
großes parallel zu seriel Schieberegister laden und dann extern mit den
maximal möglichen 25 MHz austakten.
>dann setzt doch auf Compact Flash ein paar Latches und die Sache läuft>rund und vor allem schneller weil parallel und der µC kann nebenher noch>andere Sachen erledigen als sich nur ums schieben zu kümmern.
Danke für den Tip. Der uC erledigt das schieben aber nicht selbst.
Das macht das Hardware SPI Modul. Solange das schiebt kann der
uC schon mal Daten aus dem Speicher holen und den Schleifenzähler
runterzählen.
Compact Flash ist nicht wirklich gut an einem 40poligen uC.
Erstens kann man den Sockel kaum löten und zweitens gehen
die Hälfte der IO Pins dabei drauf. SPI braucht nur vier Pins.
liege ich somit falsch, dass eine SPI SCK Änderung um das doppelte z.B.
von Teiler 8 auf Teiler 4 keine Geschwindigkeitsändrung in der Datenrate
veruracht ?
>Bist du sicher das dein ATMega32 auch mit 16MHz läuft ?
eigentlich schon, habe an XTAL1 und XTAL2 einen 16MHz Quarz zwei 27pf
Kondensatoren gegen Masse und in den Fuse-Bits habe ich External Quarz/
Resonator (1111) (11) im AVR eingestellt. Noch dazu ein CKOPT, da man
dass beim MEGA32 ab 16 MHz takten benötigt. Habe ich etwas vergessen ?
>Habe ich etwas vergessen ?
Ja möglicherweise. In MMCReadSektor und in MMCWriteSektor
stelle ich (wie unvorsichtig) automatisch auf SPI Doublespeed.
Evtl. arbeitest du die ganze Zeit schon mit demselben Teiler :(
Ich versuche Initialisierung von Schreib bzw. Lesevorgang so zu trennen
in dem ich in der Getdriveinformation() den 128 Taktteiler nehme und den
Speed bevor ich mit RemoveFile() beginne auf 0x50 (also 4Teiler) und
SPSR=0x01 hochdrehe.
Sollte ich also nach der Initialisierung auf 0x50 stellen, dann Lese und
schreibe ich automatisch mit fosc/2, da innerhalb der Funktionen ja auf
SPSR= 0x01 umgestellt wird. Dann verstehe ich die 100kB/s erst recht
nicht ;-(((
Das habe ich bereits bemerkt und sry ich meinte die MMCIdentify(). Zu
beginn wird ja der 128 Teiler zu initialsierung hergenomme und dann zu
Ende auf 0x50 umgestellt, was der 4 Teiler bei SPSR = 0x00 wäre.
Bei derartiger Einstellung schaffe ich, wenn ich 128 Bytes schreibe:
Schreiben: 108, 5 kB/s
Lesen: 120,6 kB/s
Bin ratlos !
Das ist aber kein Original-LOG von mir.
Hoffentlich hast du nicht auch an anderen Stellen rumgefummelt.
Was ist das denn ? => secPerCluster 100
Wie ist denn die Karte formatiert ?
serPerCluster ist bei allen meinen Karten
eine Zweierpotenz: 1,2,4,8,16,32,64,128
Das funktioniert so wirklich ?
>Das ist aber kein Original-LOG von mir.
Doch, habe nur den Schreibtest mit 128 Bytes drinnengelassen, den Rest
habe ich auskommentiert und die DEBUG-Comments hab ich angemacht.
Ansonsten hab ich nix gemacht.
Habe in Knoppix eine leere DOS-Partitionstabelle angelegt. Dann eine
partition (primär), dann von Zyliner 1 bis 1016. Dann das FAT16 mit hex
6 als fs gemacht und das ganze geschrieben:
*******in Linux********
fdisk /dev/sda
o
n
1
1
1016
t
6
w
***********************
Dann habe ich die Karte in Windows XP probiert, dort erkannte er sie,
aber nicht formatiert. Dann habe ich unter Dateiträgerverwaltung mit FAT
und einer size von 16k (kleiner ging es nicht) formatiert.
Ab dem zeitpunkt erkannte Windows und das Programm die Karte und das FS
und das Schreiben und Lesen ging los;-)
Schalte doch mal MMC_DEBUG_COMMANDS ab.
Das könnte schon sehr aufhalten.
Wundert mich das das LOG nicht voll von CMDxx Ausgaben ist ?
Mit dem secPerCluster Wert wirds aber Probleme geben.
Partitionier die Karte doch mal in Win neu.
Partitionieren tu ich sie ja immer in Linux. Ich hab ein LOW-Voltage
FORMAT Tool im Web gefunden, dass di Karte vollkommen platt macht und
dann partitioniere ich immer in Linux. Wie soll ich da vorgehen.
Soll ich die Karte wieder komplett löschen und dann in Windows mit FAT
formatieren ? Dann erkennt das Programm das FAT16 nämlich nie.
>>Schalte doch mal MMC_DEBUG_COMMANDS ab.
Auch schon gemacht, keine deutliche verbesserung spürbar, leider.
>>Mit dem secPerCluster Wert wirds aber Probleme geben.
Das würde ich gerne richtig machen. Schätze das da der Fehler liegt. Wie
mach ich das genau in Windows ?
>Soll ich die Karte wieder komplett löschen und dann in Windows mit FAT>formatieren ?
Ja mach, das mal.
> Dann erkennt das Programm das FAT16 nämlich nie.
Wie alt ist die Version meines Programmes ?
Damit hatte ich noch nie Ärger.
Das sieht für mich gut aus. Ich weiss: für dich nicht :(
Dann sind die Dinger halt so langsam. Sind die Debug Ausgaben
in mmc_spi.h wirklich alle aus ?
Zieh dir mal die neuste Software von meiner Homepage.
In dos.h aktivierst du dann:
FASTER_FWRITE
FASTER_FREAD
Beim schreiben bringt das ~3-4%. Beim lesen einiges mehr.
Aber auch das wird dich nicht glücklich machen.
Gruß
Holger
>Sind die Debug Ausgaben
in mmc_spi.h wirklich alle aus ?
ja vertrau mir :-) die sind aus.
>Beim schreiben bringt das ~3-4%. Beim lesen einiges mehr.
Aber auch das wird dich nicht glücklich machen.
hört sich doch gut an, wenn ich sagen kann, das es an der Karte liegt,
dann ist das ja für mich ok, dann hol ich mir eben eine schnelle und
nehme eine aus deinen Test. Mir gehts nur eben logischerweise darum, ob
ich etwas falsch mache. Ich zieh mir jetzt die Software und meld mich
dann wieder.
Da nur 16 MB draufpassen, beginnt der Test bei 8Bytes. Man muss
bedenken, dass diese Karte schon mindestens3-4 Jahre alt ist. Wenn ich
mir deinen Test mit einer Sandisk 256MB anschaue, bin ich mit der alten
Karte beim Schreiben gleichschnell. Beim Lesen fehlen noch ein paar
Bytes ;-)
***********************************************************************
ATMega FAT DOS-Read-Write-Test3
by Holgi
FAT16
bootSecOffset 57
Reserved Sectors 8
FAT Sectors 112
Num. of FAT's 2
secPerCluster 1
BytesPerCluster 512
FATFirstSector 65
FirstRootSector 289
RootDirSectors 32
FirstDataSector 321
maxsect 28800
FirstDirCluster 0
maxcluster 28481
Using FAT12 FAT16 FAT32
Using FAT Buffer
MMC/SD Card
FAST_SPI_WRITE FAST_SPI_READ
FASTER_FWRITE
FASTER_FREAD
F_CPU 16000000
Deleting files
Start writing files
8 15.82s 126.4kB/s
16 12.72s 157.2kB/s
32 11.10s 180.1kB/s
64 10.34s 193.4kB/s
77 10.28s 194.5kB/s
128 9.93s 201.4kB/s
Start reading files
8 16.77s 119.2kB/s
16 12.89s 155.1kB/s
32 10.93s 182.9kB/s
64 9.97s 200.6kB/s
77 9.88s 202.4kB/s
128 9.48s 210.9kB/s
Verifying files
77.TXT verify ok !
128.TXT verify ok !
Test done.
************************************************************************
*
PS: Das Programm von dir ist übrgens der hammer. Hab ich bis jetzt noch
gar nicht erwähnt.
Es gibt nur einen kleinen BUg in der Dumbsect.c wo der aufruf der USART
funktion ser_putc(' ') kommt macht mein Compiler mucken.
***undefined reference******
Das sieht doch schon besser aus !
Benutze im neuen makefile jetzt -02 statt -Os.
Das bringt auch schon einiges.
Die Testdaten sind zum Teil schon recht alt.
Ich mach irgendwann mal einen neuen Messlauf.
Viel Spaß dann noch
Holger
