Igitt was haben denn deine *.c fürne komische formatierung.
Schade, nix mit Editor anschaun, törnt mich grad ab das reinzuziehen.

@Roland
Da du ja ohne FAT-Buffer etc. arbeitest, interessiert mich die
Geschwindigkeit die du erreichst. Hast du schon mal was gemessen?

Sehr interessant :)
überlegst du eigentlich auch ein Programm zum schreiben von daten zu
entwickeln?
Ich hatte mal folgende Idee:
Von einer SD Karte daten lesen und diese dann auf einer Festplatte
abspeichern...(speziell für Fotos) ich weiss nicht mit wieviel aufwand
das zu realisieren ist.

die 3.3v stromversorgung hast du ja ganz elegant gelöst :)

@Roland
ja sorry habe mich etwas unsauber ausgedrückt:
Schreiben ist zwar möglich aber nur mit einer sehr geringen
Geschwindigkeit, oder habe ich da etwas falsch verstanden?
Weisst du zufällig wie man diese Geschwindigkeit erhöhen könnte auf
z.b.  1MB/s ?

MMC karten unterstützen bis zu 20 Mhz SPI takt. steht auch in den
datenblättern.

SD-Karten bis 25 MHz.

@roland
Wo hast Du denn den Kartenslot her ?

Ich meine mal auf wikipedia gelesen zu haben das SD oder MMC maximal
2mb/s kann... ich denke mal es liegt aber einfach an der Ansteuerung
mit SPI und die meisten karten erreichen den wert nicht wirklich.
78kB/s ist aber doch schon recht langsam, wenn ich mit der
Geschwindigkeit am PC zugreifen müsste würde ich irgendwann durch
drehen (wenn man nur mal daran denkt eine 4gb karte zu füllen). Ich
wusste gar nicht das die reichelt connectoren einen auswurf mechanismus
haben...

@Pete

Es gibt auch wesentlich billiger Sockets. Ich weiss gerade keinen Shop
in DE, der das zu diesem Preis schafft, aber diese hier (CH) können
das: http://www.compona.ch (~2CHF)
http://www.farnell.ch (2-19CHF, je nach Ausführung)
Es kommt einfach darauf an, was für Ansprüche du an den connector hast.
Wenn du nicht einen suuuper duuuper Connector mit Schirmung und
Schleudersitz brauchst, dann bekommst du einen für weniger als zwei
Euronen.

Gruss, Matthias

also mit so kleinen reads ist das auch echt ineffizient... warum liest
du nicht 512 byte pro read command? Wie machst du das denn bei der MMC
funktion? Führst du partial reads aus? Im Normalfall wirst du immer 512
byte blöcke von der karte lesen müssen, die restlichen bytes "weg zu
schmeißen" kostet natürlich viel Zeit.

Wenn es tatsächlich um hohe Transferaten geht, dann wird ja meistens
auch in großen Blöcken gelesen, logisch oder? :)

Na wahrscheindlich geht ihm das RAM aus.... leider immer das selbe,
irgendeinmal trifft man auf die Grenze der AVRchen.

Hallo,

in den Thread hat sich zwar schon ne weils nichts getan hoffe aber
trotzdem auf ne Antwort.

Ich bin auch grad dabei ne SD-Karte über SPI anzusteuern.

Als erstes sende ich an die Karte 10mal 0xff und dann das Kommando
0x40,0x00,0x00,0x00,0x00,0x95 (CMD 0) alles in 8bit Blöcken. Danach
polle ich mit 0xff um die Antwort von der SD-Karte zu bekommen.
Normalerweise müste ich doch nun nach dem CRC irgendwann eine 0x01 von
der Karte zurückbekommen.

Komisch ist das die SD-Karte schon ab dem vierten 0x00 Block des
Kommandos,immer mit 0xFE und gleich dannach mit 0x03 antwortet. Dann
bekomme ich 2-3 Blöcke garnichts und dann die erwartete 0x01.

Kann jemand die Signale deuten? Kann ich die 0xFE und 0x03 ignorieren
oder ist das ein Error Code?

Danke im vorraus!!

Mfg Peter Baumann

Malte

Auch ich habe eine Mega32, bei mir läuft's.

Der Programmier-Adapter stört bei mir bei einigen SD-Karten, nicht bei
allen. Und beim Flashen des Mega ziehe ich immer vorsichtshalber die
Karte raus.

Eine MiniSD-Karte sollte eigentlich kein Problem sein und der
3,3V-Regler ist das beste was Du machen konntest. Die Dioden-Lösung ist
nach meiner Erfahrung sehr unzuverläßig.

Baue doch einfach einige Debug-Meldungen in den Code ein. Man kann
sonst immer so schlecht sehen was wirklich passiert. z.B. mit einfachen
Meldungen die Du dann auf der seriellen Schnittstelle sehen kannst. So
etwa in sd_raw.c:

if(!sd_raw_available())

{
        printf_P(PSTR("Error: sd_raw_available\n"));
  return 0;

}

usw.

Platz hast Du ja im Mega32 vorerst reichlich zur Fehlersuche.

Spezielle Fuse verwende ich nicht, außer für den ext. Quarz.

Torsten

Gernot

>..schnell an das Ende einer Datei springen.

Nachdem Roland das Buffering überarbeitet hat ist das kein Problem mehr
und blitzschnell. Mit der eingebauten Mini-Shell kann man das sehr
elegant selbst überprüfen, z.B. so:

Datei anlegen:
touch 1.txt

Datei auf 100MB erweitern und ein paar Zeichen reinschreiben:
write 1.txt 100000000
<abcd

Oder einfach mitten rein:
write 1.txt 50000000
<1234

Beim drücken von Enter spüre ich keine Verzögerung.
Das gilt für Schreiben, Lesen sollte schneller möglich sein. Mein
Test-Aufbau: Mega32 @ 14,7456MHz, NoName 1GB SD-Karte, 115kB am Uart.

OT:
MP3's mit 200MB, uff. Das sind keine Songs mehr, etwa Hörbücher o.ä.?

Torsten

kommt von dos.
wenn du eine datei löscht, wird nur der name herausgenommen, wenn dir
der gleiche name wieder einfällt und dort reinschreibst, kannste die
datei wieder herstellen.

Hallo Roland,
Ich habe gerade den Samstag damit verbracht ein kleines Board für den
Kartenslot und eine Testplatine für meinen Mega16 zu Bauen.
Ich kann jetzt von einer 128 MB SD-Karte eine Datei, dumpen.
Vielen Dank. Großartige Arbeit.
Auf meinen Mega88 hat das Image mit dem Test-Main leider nicht
raufgepasst, auch nicht nachdem ich ein bisschen was wegdefiniert
habe.
Und ich denke der Mega 16 hat jetzt auch nicht mehr viel Luft für neuen
Code, ich werde einen Mega32 Ordern.
Ich habe noch eine 16MB-Karte, die kann das Programm aber nicht lesen.
Ich würde mir noch ein paar Zeilen Doku zu dem Main wünschen, und ein
paar grundsätzliche Hinweise zur Inbetriebsetzung.
Aber nochmal danke und klasse Arbeit.

servus
    Dirk

@Roland:
Doku benötigen wäre sicher etwas zuviel gesagt.

Du hättest vieleicht noch erläutern können, welche PortPins du mit
welchen an der Karte verbunden hast, insbesondere SS. Ebenso könnte man
beschreiben, welche Einstellungen für das Terminalprogramm zu wählen
sind, für das Testmain. Aber das bleibt dir überlassen und steht
schliesslich alles im Code drin. Ein Chef von mir hat mal früher
gesagt: Der Code ist die Doku.

Ebenso ein Vorschlag, was man mit der Shell anstellen kann, wie oben in
einem Beitrag:
touch 1.txt
write 1.txt 1000
ls
...

Vieleicht noch ein Warnhinweis, daß Backspace im Terminalprogramm evtl.
nicht so gut Tippfehler korrigiert, wie man denkt. Space am Ende von
Dateinamen,...

Aber das ist vieleicht mein persönliches Trauma. Konzentrier' dich,
auf was dir wichtig erscheint und lass dich nicht von mir davon
abhalten tolle Sachen zu machen.

Wirst du den Code noch weiterpflegen?

Gibt es noch known-bugs, mit Dateien, die sich überschreiben, oder
Karten, die Probleme bereiten?

Gruß
    Dirk

Was ihr nur alle mit den 10000 Schreibzyklen habt. Ein SD-Card hat einen
internen Controller wenn ein Sektor nicht mehr schreibbar ist wird der
durch einen Ersatzsektor ausgetauscht. Wieviele solche Ersatzsektoren
vorhanden sind ist Sache der Hersteller und dürfte sich auch im Preis
wiederspiegeln. Eine SD-Karte hat auch einen internen RAM ,das merkt
man am schnelleren Multisektorzugriff. Da werden die Daten auch erstmal
gesammelt. Ausserdem schafft flash heutzutage 100.000 Zyklen. Wenn es
unbedingt Langzeit sein muss, nimmt man ein FRAM sammelt da die Daten
und schreibt am Block.

@Roland:
wie ich sehe versuchst du das FAT16 Dateisystem an dem String FAT16 zu
erkennen, dies ist ein Eintrag in dem auch andere Sachen stehen können
und er ist nicht obligatorisch für FAT16. Das Windowsformatprogramm
macht dies allerdings seit Jahren so.

55AA prüfen, auf Partitionssektor prüfen
Bootsektor
55AA prüfen
Clusteranzahl<4085 ||Clusteranzahl>65524
Sektoren pro Cluster 2^n ?
evt. anfang der FAT cluster 0 und 1 Wert prüfen
Bevor Microsoft die FAT Patente bekam gab es von Microsoft ein
Dokument
das aus der Einführungszeit von VFAT stammt und unterschiedliche
FATimplementierungen und testroutinen (unter anderen Norton und
PCTools)
und mögliche Auswirkungen durch VFAT diskutiert. Ausserdem wird auf
typische Fehler in anderen FATimplementierungen eingegegangen.
Hier wird nochmals ausdrücklich darauf hingewiesen das FAT12 und FAT16
nicht durch den String sondern allein durch die Clusteranzahl
auseinandergehalten
werden. Auch PCIntern hat in der Bootsektorbeschreibung diesen String
nicht als obligatorisch.
Bezüglich Datenverlust: schon beim Einlesen des Hauptverzeichnisses
dürfte es probleme geben.

>Denn es sind mehrere Lesevorgänge erforderlich,
1. Sektor laden
Partitionssektor?
wenn ja Bootsektor laden
>Zusammenbauen der 16-Bit-Werte, das Prüfen der Werte, usw.
Diese Werte musst du sowieso auslesen
und das Zusammenbauen aus 8Bitwerten solltest du sowieso machen wenn
du
Interesse daran hast das dein FAT-Code auch auf anderen CPU läuft.

>Trotzdem, hast Du vielleicht noch einen Link...
Dieses Dokument ist aus dem Netz verschwunden als Microsoft die
FAT-Patente erhalten hat. Ich muss mal suchen ob ich es noch finde.
BTW: Hast du dir schonmal Gedanken gemacht was passiert wenn Microsoft
an dich herantritt wegen der FAT-Implementierung?

>Im Übrigen sollte der Code schon plattformunabhängig sein.
Ein Tip aus eigener Erfahrung, du hast sowieso nur eine Lese-/Schreib
und Kartendetektionsroutine. Der Rest sollte Hardwareunabhängig sein.
Wenn du die genannten Routine auf dem PC in eine Datei/Device umlenkst
kannst du alles auf dem PC entwickeln, aufgrund der erweiterten
Debuggingmöglichkeiten auf dem PC geht es wesentlich schneller voran
und es wird mit Sicherheit plattformunabhängig. Ganz nebenbei schont es
den flash der MCU und der SDCard.

@Roland:
Ich habe zumindest das eine Dokument im Netz gefunden:
http://www.walrus.com/~raphael/pdf/FatFormat.pdf#s...

Hi!
Wenn ich mich nicht verlesen habe so erkennt man die Fatart auch an den
1ten Byte jeder Fat.
$0FF8 = Fat 12
$FFF8 = Fat 16
$0FFFFFF8 = Fat 32
oder
Offset  Description  Size
000h  Executable Code (Boots Computer)  446 Bytes
1BEh  1st Partition Entry (See Next Table)  16 Bytes
1CEh  2nd Partition Entry  16 Bytes
1DEh  3rd Partition Entry  16 Bytes
1EEh  4th Partition Entry  16 Bytes
1FEh  Boot Record Signature (55h AAh)  2 Bytes

Partition Entry (Part of MBR)
Offset  Description  Size
00h  Current State of Partition (00h=Inactive, 80h=Active)  1 Byte
01h  Beginning of Partition - Head  1 Byte
02h   Beginning of Partition - Cylinder/Sector (See Below)  1 Word
04h  Type of Partition (See List Below)  1 Byte
05h  End of Partition - Head  1 Byte
06h  End of Partition - Cylinder/Sector  1 Word
08h  Number of Sectors Between the MBR and the First Sector in the
Partition  1 Double Word
0Ch  Number of Sectors in the Partition  1 Double Word

Partition Type Listing
There are more than just these shown, but I've only included that ones
relevant to MS Operating Systems.
Value  Description
00h  Unknown or Nothing
01h  12-bit FAT
04h  16-bit FAT (Partition Smaller than 32MB)
05h  Extended MS-DOS Partition
06h  16-bit FAT (Partition Larger than 32MB)
0Bh  32-bit FAT (Partition Up to 2048GB)
0Ch  Same as 0BH, but uses LBA1 13h Extensions
0Eh  Same as 06H, but uses LBA1 13h Extensions
0Fh  Same as 05H, but uses LBA1 13h Extensions

Die Fatstartadresse musst du sowiso berechnen, da kannste den Sector
auch mal lesen. Wenn du es dann noch mit dem MBReintrag vergleichst
sollte das eigentlich recht sicher sein. Du kannst natürlich auch die
VBReinträge prüfen und aus der Clusterzahl auf die Fat schließen.

schönen Tag noch, Uwe

Moin,

erstmal Glückwunsch zu dem Projekt und Danke an alle, die sich hier
richtig reinhängen, speziell an Roland.

Ich möchte habe auch ein Projekt, bei dem ich eine SD/MMC als
Datenlogger mit einbinden möchte und erstelle gerade das Konzept.

Nun meine Frage:

Um die Anzahl der Bauelemente und den benötigten Platz klein zu halten,
wollte ich den Atmega168 direkt bei 3,3V betreiben und mir den
Levelshifter sparen.

Bis 10Mhz ist das ja laut Datenblatt zulässig oder habe ich noch was
übersehen?

Noch eine Bitte: Könnte jemand den Schaltplan mal als PDF, JPG oder PNG
posten? Ich habe hier auf Arbeit kein Eagle ....

Danke!

abo

Malte

Ersetze einfach in "uart.c"

#define USE_SLEEP 1
durch
#define USE_SLEEP 0

und kommmentiere in der main() in "main.c" folgende Zeile

set_sleep_mode(SLEEP_MODE_IDLE);

einfach aus. Dann sollte es eigentlich sein wie vorher.


Roland hat den Idle-Mode auf meinen ausdrücklichen Wunsch hin
eingebaut. Wir haben lange diskutiert wie es am sinnvollsten ist. Nur
an einen ext.Interrupt hat keiner gedacht..

Torsten

Welche aufgabe übernimmt eigentlich am avr immer der port ss an der
mmc-karte? kann man auch eien anderen port nehmen?

da ich nur die mmc-karte anschliessen möchte und diese auch nur
betreibe, kann man den anschluss an der mmc cs sofort auf masse legen?

hier sind ja alles fachleute.

ich möchte die mmc-karte nicht mit dos und fat betreiben.
ich möchte einfach die mmc-karte initialieren und dann 512bytes lesen,
schreiben und evtl löschen.

wo kann man in winavr-c einfache beispiele ausmachen.
ich steige durch den oberen code für die mmc-karte nicht durch, finde
als laie keine timing, adressen usw.

danke.

mfg

Hallo Roland,
bin gerade dabei, einen Datenlogger mit einem Mega32 zu bauen und nutze
dabei Deinen Code zur Ansteuerung der SD-Karte. Hatte auch null
Probleme, den Code einzubinden, ist schön übersichtlich und gut
kommentiert (besser als meiner...;-)), echt klasse.
Leider sind die Ausführungszeiten mancher Funktionen zu lang, so dass
mir (bei höheren Sampleraten) jedes Mal wenn ein Block auf die Karte
geschrieben wird, samples verloren gehen, weil zum Beispiel die CPU auf
die SD-Karte wartet:

while(sd_raw_rec_byte() != 0xff);

Ich suche nun nach einer Möglichkeit, diese busy waits zu vermeiden und
statt dessen ins Hauptprogramm zurückzukehren, um bei Bedarf weitere
Messungen anzutriggern (gemessen wird mit einem MAX127 über TWI). Ich
habe schon versucht, statt der Warteschleife ein flag zu setzen und die
Warteschleife dann am Anfang des nächsten Aufrufs auszuführen, hat aber
nicht geklappt, wahrscheinlich weil nach dem write ein read
durchgeführt werden muss, um den nächsten Block zu finden, und die
Karte dann noch nicht bereit ist.
Ich fürchte, der Code müsste massiv umgeschrieben werden, um hier
deutliche Verbesserungen zu erzielen. Wahrscheinlich müsste dann auch
Deine elegante Aufteilung in Schichten dran glauben...
Irgendwelche Ideen, in welcher Richtung ich hier am schlauesten
vorgehen könnte?

Gruss,
Thorsten

Hallo Roland,

Meine erwartete Datenrate sind ca. 20kbytes/s, zur Verwendung kommt ein
Binärformat. In reinen Schreibtests mit Deinem FAT16-Treiber konnte ich
ca. 60kbytes/s erzielen, sollte also drin sein (mein Mega32 läuft mit
14.7456MHz). Mein Problem ist nicht der absolute Overhead, sondern die
Latenzzeit, die auftritt wenn ein Block geschrieben wird. Ich verwende
den FAT16-Treiber, da die Karte nach der Messung im PC ausgelesen
werden soll. Da meine Datenrate recht konstant ist, bringt ein
grösserer Datenpuffer nicht so richtig was (wenn die Daten schneller
kommen, als der Prozessor sie wegschreiben kann, geht es halt einfach
nicht, egal wie gross der Puffer ist). Ausserdem löst eine geringere
Datenrate das Problem nicht, denn die Latenzzeit tritt zwar weniger oft
auf, ist jedoch immer noch genauso gross (grösser als mein
Samplingintervall). Eventuell könnte ein Puffer für die FAT16-Metadaten
etwas bringen?
Interrupts könnten auch was bringen, allerdings müssten dann auch
FAT16-Routinen in die ISR gepackt werden, sonst wartet dann halt die
FAT-Routine statt der sd_raw routine, und ich bin immernoch da, wo ich
am Anfang war (daher meine Befürchtung, dass grössere Änderungen am
Code nötig werden). Bei f/2 SPI Takt habe ich pro zu übertragendem Byte
16 Prozessortakte zur Verfügung, von den allerdings die meisten als
Overhead (springen in und aus der ISR) wieder wegfallen.
Das mit dem zweiten Controller habe ich mir auch schon überlegt,
versuche ich aber zu vermeiden, weil dadurch eine Menge zusätzlicher
Komplexität entsteht.
Werde mir mal sd_raw_read_interval() genauer angucken.

Danke für die Tips,

Thorsten

Thorsten

Die FAT-Routinen kannst Du nicht in eine ISR packen weil die einfach zu
lange dauern. Nach kurzer Zeit gibt es einen Stack-Überlauf.

Die einzige Lösung wäre ein FIFO-Buffer der in einer ISR gefüllt wird.
Wenn Du Daten vom TWI lesen willst dann hast Du doch schon fast
gewonnen. Dafür gibt es doch extra eine ISR.

In der Hauptschleife schaust Du einfach ständig nach ob der FIFO neue
Daten enthält und schreibst diese weg.

Torsten

Torsten,

Ich dachte auch nicht dran, die FAT16-Routinen samt ihren Wartezyklen
in eine ISR zu packen, sondern die SPI-ISR so zu schreiben, dass sie
bei jedem Aufruf entscheidet, was als nächstes zu tun ist (Byte zum SPI
schreiben/lesen, wenn der Block fertig ist, gucken was als nächstes zu
tun ist, z.B. die FAT Einträge draus lesen usw.). Würde aber trotzdem
eine ziemlich grosse ISR geben, auch wenn bei jedem Aufruf nur ein
kleiner Teil davon zur Ausführung kommt. Das ist auch meiner Meinung
nach nicht der richtige Weg.
Das Problem ist halt, dass viele der Routinen einfach "busy" warten,
bis der Kartenzugriff abgeschlossen ist. Dadurch kriege ich immer die
Latenzen, egal ob die Karte nun durch eine ISR oder eine andere Routine
angesteuert wird.
Was möglicherweise ginge, wäre aber der umgekehrte Weg:
- Es gibt nicht einen Buffer, sondern zwei. Ein Pointer zeigt auf den
gerade aktiven.
- Wenn ein Block geschrieben werden soll, wird der SPI Interrupt
aktiviert und das erste Byte geschrieben. Die ISR sorgt dann dafür,
dass der Buffer asynchron auf die Karte geschrieben wird (Globale
Statusvariablen kontrollieren das, wenn der Block fertig ist,
deaktiviert die ISR den SPI Interrupt). Gleichzeitig wird der Zeiger
auf den zweiten Buffer gestellt, so dass weitere Schreibzugriffe
abgebuffert werden können. Die sd_raw Funktion kann sofort
zurückkehren.
Wo ich noch nicht so genau weiss, wie man es lösen könnte, ist das
lesen: Was mache ich mit einer Routine, die einen Block einliest und
dann bearbeitet? Die blockiert dann wieder... (zwangsläufig).
Was hältst Du davon?
Die andere Möglichkeit wäre, wie Du schreibst, die TWI ISR zu benutzen.
Ich muss mir nur noch überlegen, wie ich die Messung antriggere, könnte
ich in meiner RTC ISR am INT0 machen (die kriegt 32768Hz von der RTC).
Ansonsten wäre das evtl. noch besser, denn die TWI ISR feuert nicht so
schnell wie die SPI ISR (400kHz vs. 7MHz), d.h. mir bleiben mehr Takte
dazwischen übrig. Mal gucken...

Gruss,
Thorsten

Roland,

> Wenn die Daten mit 20kB/s kommen und Du 60kB/s wegschreiben kannst,
> kommen sie doch nicht schneller als Du sie schreiben kannst?!?

Sorry, hab mich wohl undeutlich ausgedrückt. Der grössere Datenpuffer
bringt mir natürlich deswegen nix, weil ich Samples verpasse, während
ich auf die Karte warte (und daher nicht messen & in den Buffer
schreiben kann). Er würde aber auch bei zu hohen Datenraten nix bringen
(das wollte ich eigentlich zum Ausdruck bringen). Mein Problem sind
aber, wie gesagt, die Latenzen.

Ich glaube inzwischen, dass es am besten ist, zu versuchen die
Messungen komplett über die ISRs zu steuern, während der Kartenzugriff
dann vom Hauptprogramm aus kontrolliert wird.

Werde mal Versuche machen und berichten, wie es so klappt.

Gruss,
Thorsten

> - Es gibt nicht einen Buffer, sondern zwei. Ein Pointer zeigt auf den
> gerade aktiven.

Double Buffering eben, geht auch. Nur, der Mega hat wenig Speicher und
der Verwaltungsaufwand dafür ist auch erheblich. Viel einfacher wäre es
mit einem Ring-Buffer und Zeigern auf Head und Tail zu arbeiten.

> - Wenn ein Block geschrieben werden soll, wird der SPI Interrupt
> aktiviert und das erste Byte geschrieben. Die ISR sorgt dann dafür,
> dass der Buffer asynchron auf die Karte geschrieben wird (Globale
> Statusvariablen kontrollieren das, wenn der Block fertig ist,
> deaktiviert die ISR den SPI Interrupt). Gleichzeitig wird der Zeiger
> auf den zweiten Buffer gestellt, so dass weitere Schreibzugriffe
> abgebuffert werden können. Die sd_raw Funktion kann sofort
> zurückkehren.

Das mit dem SPI Interrupt hört sich gut an. Leider muß dann Roland's
Code komplett neu geschrieben werden. ;)

> Wo ich noch nicht so genau weiss, wie man es lösen könnte, ist das
> lesen: Was mache ich mit einer Routine, die einen Block einliest und
> dann bearbeitet? Die blockiert dann wieder... (zwangsläufig).

Ja, das stimmt. Schwierig zu lösen.

> Was hältst Du davon?

Google mal nach einem Projekt nennt sich "AVRCam".

Das Konzept gefällt mir sehr gut. Dort wird mit einer globalen
Event-FIFO gearbeitet. Fast alle Events sind nicht-blockierend. TWI
wurde auch komplett in die ISR ausgelagert.

Schau Dir die Quelltexte unbedingt einmal an.

Wenn dieses Projekt CPU- und Speicher-intensives Video verarbeiten kann
muß es doch möglich sein einen Datenlogger mit SD-Karte auf die Beine zu
stellen. ;-)

BTW:
Die disk-info von Malte nach einer Neuformatierung
>free:   120578048/254795776
gefällt mir überhaupt nicht.

So ähnlich verhielt sich auch meine Karte auch kurz bevor sie ganz und
gar den Geist aufgegeben hat. :-(

Torsten

> Ich glaube, wir missverstehen uns hier ein bisschen. Wovon ich oben
> ausgegangen bin ist, dass die Messung als solche durch eine
> Hardware-Einheit des AVR stattfindet, somit keine MCU-Zeit braucht
und
> zum Schluss jeder Messung ein Interrupt (wie der des ADC) auslöst.

Ich bin zwar der Torsten ohne 'h' im Namen aber der andere wollte
Daten vom TWI mit Hilfe eines MAX127 (kenne ich nicht...) lesen. Also
mit HW Unterstützung, und hoffentlich ohne busy-wait beim Register
lesen.

> Irgendetwas mit dem SPI-Interrupt anzufangen halte ich für sinnlos.
Der
> feuert mit knapp 1MHz zu häufig.

Ops, Du hast recht. Eine ISR macht bei der Geschwindigkeit keinen
Sinn mehr.

Torsten

Roland,

ich sehe, worauf Du hinauswillst.
Gemessen wird mit zwei MAX127 am I2C Bus. Für jeden Messwert müssen 5
bytes über den Bus (Adresse + Kontrollbyte zum starten der Messung,
dann Adresse plus zwei Nullbytes zum lesen des Messwertes). Pro Messung
(16 Kanäle) sind das also 80 bytes, bei 400kHz also ca. 1.6ms. Bei einem
Sample-Interval von 4ms hätte ich dann noch ca. 2.4ms pro Takt zum
speichern, was zwar im Mittel ausreicht, wegen dem angesprochenen
Latenzproblem jedoch nicht funktioniert.
Zur ISR:
Bisher verwende ich eine modifizierte Variante des Atmel-Beispielcodes.
Die ISR kümmert sich hier ums versenden/empfangen der Messages,
initialisieren und verarbeiten tu ich die Ergebnisse in einer normalen
Unterfunktion, die im Augenblick noch vom Hauptprogramm aus aufgerufen
wird. Das Timing geschieht in einer ISR, die von einem 32kHz Takt
angesteuert wird (der Takt kommt von der RTC).
Wenn ich nun aus dieser ISR jeweils alle 4ms die erste TWI Message
anschubse, und in der TWI-ISR dann (gesteuert über ein globales Flag)
automatisch die nächste TWI Message vorbereite, wenn die letzte
vollständig ist (usw.), könnte es gehen. Die Messwerte in der TWI-ISR
in einen Buffer schreiben, der einfach im Hauptprogramm dann gemütlich
auf die SD-Karte wandert. So könnte es gehen. Und das beste: Ich muss
den SD-Code nicht verändern. Dafür halt die TWI-ISR.
Werde das mal so probieren.

@Torsten: Werde mir auch mal AVRCam angucken, danke für den Tip.

Das Forum hier ist spitze :-)

Gruss,
Thorsten

> Das mit dem TWI hatte ich überlesen. D.h. für das Messen ist auch ein
> Polling nötig. Dann wird das natürlich schwieriger, ohje...

Nein, ganz im Gegenteil, das macht es ja einfacher weil es eine extra
ISR für TWI gibt.

Mein Problem ist dass ich den MAX127 noch nicht kenne und die Art und
Weise wie man an dessen Daten kommt. Ich google gleich mal.

Langsam wird der Thread unübersichtlich, mehr als 100 Beiträge.
Scrollen macht jetzt keinen Spaß mehr. Was haltet Ihr von einer
Fortsetzung in einem neuen Thread?

Torsten

Hallo Roland,

>Es macht doch nichts, wenn die Karte noch schreibt und schon der
>nächste Interrupt kommt?

Irgendwie scheinbar doch. Es fehlen immer Samples. Allerdings arbeite
ich mit nur einem Puffer, weil ich denke, dass das Wegschreiben über
SPI wesentlich schneller geht als das Einlaufen neuer Samples. Das muss
ich mir aber noch mal genau überlegen, vielleicht liegt da der Hase im
Pfeffer.

>Wie schon erwähnt weiß ich nicht, ob die
>Karte den SPI-Takt, der durch das Polling erzeugt wird, zum Schreiben
>benötigt.

In dem von mir oben zitierten Link steht folgendes:

"In principle of the SPI mode, the CS signal must be asserted during a
transaction, however there is an exception to this rule. When the card
is busy, the host controller can deassert CS to release SPI bus for any
other SPI devices. The card will drive DO signal low again when reselect
it during internal process is in progress. Therefore a preceding busy
check (wait ready immediataly before command and data packet) instead
of post wait can eliminate waste wait time."

Daraus schliesse ich, dass das Polling nicht benötigt wird. In dem Link
steht übrigens noch so einiges über write-performance Verbesserung, zB.
dass MMCs viel schneller sind als SDs...

Gruß
Malte

Hi!
>Wie schon erwähnt weiß ich nicht, ob die
>Karte den SPI-Takt, der durch das Polling erzeugt wird, zum Schreiben
>benötigt.
Habe in der Hinsicht mal Messungen gemacht und festgestellt das
langsame Karten dadurch viel schneller schreiben
1,8/1,1ms @250KHz/1MHz. Bei Karten, die von sich aus schon recht
schnell sind, ist der Unterschied deutlich geringer 393us/372us.
Wenn der Takt also ganz wegbleibt kann das schon zu Zeitverlust führen.
Die gemessene Zeit ist übrigens der Abstand zwischen dem Ende des
letzten zu schreibenden Byte und der Busy-reaktion, also reine
Schreibzeit.
Viel Erfolg, Uwe

Hallo Roland,
ich habe ein Problem mit der Funktion fat16_write_file,
  /* calculate new file position */
        buffer += write_length;
        buffer_left -= write_length;
        fd->pos += write_length;

Ist die zu schreibende Datei, die einzige Datei auf dem Datenträger
wird der Dir. Eintrag nicht neu geschrieben. In der Abfrage sind dann
beide Werte gleich:
 /* update directory entry */
    if(fd->pos > fd->dir_entry.file_size)

Wenn eine 2. Datei da ist, wird ein Update des Dir. aufgerufen.
Funktioniert jedoch nicht. Im Dir. Eintrag steht dann noch die Alte
Größe wobei die Dateidaten abgelegt wurden.

Viele Grüße
Reinhold

Hallo Roland,
das Problem hat sich geklärt. Die Funktion "sd_raw_sync()" wurde
nicht angesprochen deshalb wurde das Dir. nicht upgedatet. Ein
Speicherproblem war die 2. Ursache.

Wenn ich allerdings an eine Datei ohne Offset Daten anhängen will hab
ich ein Problem.
Die Ursache liegt in der Funktion:
fat16_seek_file(fd,&offset , FAT16_SEEK_END);

Ist offset = 0 wird diese mit return 0 abgebrochen.
Mein Vorschlag:

uint8_t fat16_seek_file(struct fat16_file_struct* fd, int32_t* offset,
uint8_t whence)
{
    if(!fd )          //  || !offset
        return 0;

    uint32_t new_pos = fd->pos;
    switch(whence)
    {
        case FAT16_SEEK_SET:
            new_pos = *offset;
            break;
        case FAT16_SEEK_CUR:
            new_pos += *offset;
            break;
        case FAT16_SEEK_END:
            new_pos = fd->dir_entry.file_size + *offset;
            break;
        default:
            return 0;
    }

    if(new_pos > fd->dir_entry.file_size && !fat16_resize_file(fd,
new_pos))
        return 0;

    fd->pos = new_pos;
    fd->pos_cluster = 0;

    *offset = new_pos;
    return 1;
}

Oder mache ich was falsch?

Gruß und Danke schon mal für den Code
Reinhold

Hallo Roland,
jau ich hab meinen Fehler erkannt....

Gibt es einen Beispielcode zum anlegen eines Unterverzeichnisses?
Ich muss mit Unterverzeichnissen arbeiten da im Rootverzeichnis die
Anzahl der Einträge ja begrenzt ist.
Bei einer neu formatierten SD soll dann das Verzeichnis automatisch
angelegt werden.

Gruß
Reinhold

Hat das jemand schon einmal mit einer Kingston 256MB SD-Karte
hinbekommen ?

Ich bekomme bei dem Card init in Zeile 212 von sd_raw.c einen "test2"
Fehler:
/* reset card */
    uint8_t response;
    for(uint16_t i = 0; ; ++i)
    {
        response = sd_raw_send_command_r1(CMD_GO_IDLE_STATE, 0);
        if(response == (1 << R1_IDLE_STATE))
    {   printf("test1\n");
            break;
    }

        if(i == 0x1ff)
        {
            unselect_card();
      printf("test2\n");
            return 0;
        }
    }

Die Karte läuft mit 3,3V über Spannungsregler. Teiler sind 3K3 und 2K
Ohm, d.h. bei der Karte kommen die Pegel mit etwas über 3 Volt an.
Nun ja, nicht so optimal.

Würde auch 10k mit 6,6k gehen ? Dann liegt allerdings I=0,5mA recht
niedrig ...

So, geht jetzt, war ein elektrischer Fehler. Vielen Dank für die Library
!!! Jetzt steht dem Abenteuer SD-Card nichts mehr im Wege :-)

Für den 644er musste ich Änderungen am Interface machen. Die Register
enden dort alle mit "0" (z.B. SPCR0).

Pete

Hallo Roland,
die Funktion fat16_create_file() habe ich modifiziert zu
fat16_create_dir(). Das Ende der Funktion habe ich dazu modifiziert.

Der Dir-Eintrag im Root-Dir wird auch geschrieben aber das
Unterverzeichnis funktioniert nicht richtig.

.......
     cluster_num= fat16_append_clusters(fs, 0, 1);

    /* write directory entry to disk */
    dir_entry->cluster=cluster_num;
    dir_entry->attributes=FAT16_ATTRIB_DIR;
    dir_entry->date_create=format_time();
    dir_entry->date_change=format_time();
    dir_entry->entry_offset = dir_entry_offset;
    if(!fat16_write_dir_entry(fs, dir_entry))
        return 0;

    return 1;

#else
    return 0;
#endif
}

Ach ja das dir_entry habe ich um die Zeit/Datumsinformation erweitert.
Was muß ich machen damit das Unterverzeichnis richtig arbeitet?

Gruß
Reinhold

Hallo Roland,
ich hab herausgefunden das die SUBs nur dann nicht funktionieren wenn
in dem entsprechenden Cluster noch Datenmüll von gelöschten Dateien
steht. Bei einer gereinigten frisch formatierten SD geht alles! Also
muss ich jetzt nur noch den entsprechenden Cluster in dem das
Verzeichnis sein soll vorher löschen oder?
Gruß Reinhold

Mist, ich habe möglicherweise schon wieder eine Karte geschrottet. :(

Folgendes ist mir passiert:

Ich nutze Roland's Code um in einem Datenlogger alle 15min
Temperaturwerte von DS18S20 Sensoren aufzuzeichnen. Nur ein paar chars,
immer in die gleiche Datei. Nichts zeitkritisches, funktioniert super.
Den 'sync' Befehl nach dem schreiben hab ich auch nicht vergessen.

Nun dachte ich mir, es ist mal Zeit für einen Langzeit-Test und habe
meiner Schaltung die auf einem Steckbrett aufgebaut ist einen Akku
spendiert und in die Ecke gestellt. Und natürlich vergessen.

Irgendwann habe ich mich wieder erinnert und nachgesehen. Klar war der
Akku leer. Ok, Karte entfernt und in den Cardreader am PC gesteckt. Nun
der große Schreck - XP meint: Der Datenträger ist nicht formatiert.

Weder unter Linux noch unter XP mit dem SD-Formatter von Panasonic
konnte ich die Karte wieder zum Leben erwecken. Fehlermeldung:
write-protected.

Gut, eine neue kostet kein Vermögen. Aber die alte Karte kann sich doch
nicht einfach in Sonder-Müll verwandeln wenn die Stromversorgung mal
einknickt.

Hat jemand zufälligerweise ähnliche Probleme gehabt oder eine Idee ob
man evtl. mit einem Raw-Write an bestimmter Stelle die Karte(n) retten
könnte?

Torsten

Ich habe die gleichen Probleme :-(

Ergänzung:
Unter Ubuntu (Linux) sehe ich die Karte und kann auch Files lesen.
Formatieren geht auch nicht. Weder mit mkdosfs noch mit cat /dev/zero
</dev/speicherkarte>.

Haben wir uns ausgesperrt ??

P.S.: T.S.: Könntest Du Deinen Code vielleicht hier posten ?

> Ich habe die gleichen Probleme :-(

Wie ist es bei Dir passiert?

> Haben wir uns ausgesperrt ??

Ich glaube schon.

Auch weil es nicht meine erste Karte ist. Irgend etwas ist oberfaul.
Mag sein wegen der sehr lückenhaften Doku.

> Könntest Du Deinen Code vielleicht hier posten ?

Hhmm.

Das macht atm nicht wirklich Sinn weil ich bestimmt andere HW verwende
und gerade erst angefangen habe. Mitten drin beim experimentieren so zu
sagen - und noch lange nicht fertig.

Wenn Du aber unbedingt darauf bestehst bekommst Du selbstverständlich
den Quelltext. Ich brauche dann aber Deine Mail Adresse und Dein
Einverständnis das Roland ein Cc bekommt.

Torsten

Hallo T.S.,

meine email Adresse ist p e t e r - k r u s e (a t) g m x. n e t.

Gerne mit Kopie an Roland.

Ich vermute, dass beim Schreiben etwas daneben gegangen ist.(?)

Gruss,
Pete

@Pete
Done.

@AVR Nix
Zwar kenne ich den thread schon, weil aber auch dieser so ellenlang
ist, ist mir genau das entgangen. Danke für den Link. :-)

Torsten

Habe aber auch in dem Thread keine Lösung für die "Read-only"-Karten
gefunden...

Hallo,
habt ihr eigentlich schon mal überlegt, wie man solch eine Fehlfunktion
durch Stromausfall verhindern könnte? Würde mich sehr interessieren,
denn sowas kann ja bei jedem autark arbeitenden Datenlogger passieren.
Bei meinem System habe ich mich noch nicht getraut, den Stecker während
des Schreibens zu ziehen. Kann man da vielleicht mit dem Brown Out
Detector was machen? (Ich habe mich noch nicht damit beschäftigt)

Gruß
Malte

Nun ja, irgendwann möchte ich die Daten auch auf meinen PC übertragen.
Ich werde vor dem Schreibvorgang eine LED anmachen und nach dem
Schreiben wieder aus. Dann kann ich sehen, wann ich ziehen darf.

Hallo Ihr Kartentöter,
Mal ne blöde Frage, Wie sieht denn euer CSD-Reg. an Bitpos.13-15 und
84-95 aus? Schreibschutz? Card Command Classes?

Ich würde da jetzt mal anfangen zu suchen.

MFG Uwe

@Malte
Nachgedacht schon, aber noch keine Lösung gefunden. Der Brown Out
Detector nützt in meinem Fall gar nichts, weil auch bei fast entladenem
Akku die Zellspannung locker ausreicht. Nur bei hoher Belastung während
eines Schreibvorganges auf die Karte knickt die Spannung ein. Dann,
wenn es zu spät ist.

@Pete
Ich habe die Empfehlung in dem o.g. Thread mal angepasst &
ausprobiert:

if(sd_raw_send_command_r1(CMD_CLR_WRITE_PROT, 0))

{

    unselect_card();

    return 0;
}


Geht nicht wie zu erwarten war. Vielleicht muß die '0' durch etwas
anderes ersetzt werden. Bin ratlos.

Torsten

@Torsten:
Hast Du Deine Karte wieder reaktieren können ?

Beantwortet ist auch noch nicht Deine Frage nach der Reaktivierung der
Karte ...

Hallo hatte leider noch keine Zeit mich in den Source einzuarbeiten.
Arbeite aber mit einer selbstgeschriebenen Software
Aber einige Fragen bzw. Anmerkungen hätte ich schon.
Wie stellt das Programm die relative Adresse der FAT Sektoren fest?
Meiner Erfahrung nach liegt nähmlich der erste Sektor des Dateisystemes
je nach Kartengrösse nicht ab der Adresse 0x00000000 sondern etwa bei
einer 32 MB Karte erst bei 0x00006600. Obwohl er etwa in WINHEX bei
0x00000000 auftaucht.(Im Moment gehe ich nicht von einem Fehler meiner
Software aus)
Jetzt meine Frage könnte das mit dem Writeprotect-Managment der SD
Karte zusammenhängen. Und was passiert wenn man in diese Sektoren Daten
reinschreibt.
Eine weitere Frage wäre weiss irgentjemand hier wo ich eine genaue
Dokumentation über das WriteProtectmanagment herbekomme. In den
Üblichen Datenblättern etwa von Sandisk steht dazu nämlich leider nicht
viel drin.

Hallo,

lässt sich der Code dahingehend einstellen, dass ich mittels ATmega8
schreibend auf das FAT16 - Dateiformat zugreifen kann?
Welche Einstellungen müssen hierfür getätigt werden?

Unter BASCOM mittels DOS-AVR bekommt man das nicht realisiert, weil
hierfür einfach nicht genügend RAM zur Verfügung steht. Wieviel RAM
benötigt diese Variante minimal für ein FAT-Dateisystem?

Wie sieht es mit einem Low-Level_Zugriff aus?

DANKE schon einmal.

Hi,

hat jemand schon Verzeichnisse angelegt? Ich kriege es nicht richtig hin
und habe immer alten Datenmüll in den Verzeichnissen.

Danke!!!

Gruß
Holger

Seit etwa 2 Monaten verwende ich die ältere Version von 20060319 in
einem eigenen Projekt. Alles läuft sehr stabil und zuverläßig. Danke an
Roland noch einmal dafür!

Nun ist in meinem Projekt etwas aufgetreten womit ich zu Anfang
überhaupt nicht gerechnet habe: die Datenflut ist einfach zu groß. Alles
in einer einzigen Datei im root zu speichern war zwar einfach umzusetzen
aber nicht besonders klug. Aufgrund der Größe macht ein Download auch
bei 115k nun keinen Spaß mehr.

Kein Problem dachte ich, die neue Version von 20061101 nehmen und alles
in einzelne Verzeichnisse packen. Doch damit habe ich einige Probleme:

Wenn ich z.B. ein neues Verzeichnis anlege mit "mkdir Test", zeigt ein
"ls" noch korrekt an das es wirklich angelegt wurde.

Aber beim hineingehen mit "cd Test" und "ls" bleibt alles in einer
Endlosschleife hängen. Der erste Eintrag wird ständig wiederholt. Nur
ein Reset erlöst den uC.

Was mich stutzig werden läßt: Nehme ich die Karte und erzeuge im
Kartenleser unter XP ein gleich lautendes Verzeichnis, dann zurück zum
uC, zeigt "ls" es korrekt an. Ein "cd Test" und "ls" zeigt
erwartungsgemäß die Einträge "." und ".." an. Dann zurück mit "cd.." und
"rm Test" um das Verzeichnis zu löschen. Aber jetzt kommt der Hammer:
"mkdir Test" und "ls" funktioniert jetzt...

Die Karte habe ich mehrmals mit dem SDFormatter V1.2 formatiert. Einen
"sync" nach jeder Eingabe habe ich auch nicht vergessen. Der uC und die
Karte haben genug 'Saft'. ;)

Für jemanden der mit Dateisystemen nicht per 'Du' ist so wie ich ist der
Quelltext auch wenn er so gut strukturiert ist wie im SD-Reader nicht so
einfach zu durchschauen.

Deswegen meine Frage an Roland: Kannst Du mir bitte helfen dem Problem
auf den Grund zu gehen? Möglicherweise könnten einige printf's an der
richtigen Stelle helfen.

Torsten

Hallo  André Kronfeldt,
kiffen kann auch gesundheitsförderlich sein. In den Niederlanden werden
bei bestimmtne Krankheiten z.B. MS nicht Interferoon und Opium sondern
das Kiffen als Medikament empfohlen. Spezielle Züchtungen mit
gesundheitsförderlichen Tendenzen statt Chemiekeule und Abhängigkeit.
Spritzen kann man nur 2 Jahre. Rauchen kann man das ganze Leben lang.
Roland weiter so. Denn in Zukunft gibt es CF Karten mit 8GB,16GB,32GB
was ist mit denen.

@ T.S.:
Hast Du die defekte Karte wieder reaktivieren können oder eine Lösung
für das Ziehen der Karte beim Schreiben gefunden ?

Hallo zusammen

Ist es möglich die SD-Karte an einem anderen Port und somit nicht mit
dem Hardware SPI des AVR zu betreiben mit dem Code von Roland Riegel?

In sd_raw.c wird ja das SPCR Register entsprechend konfiguriert...

@ Pete
1) Nein.
2) Nein. Das habe ich auch noch nie gewagt.

Mein Problem war ein anderes - nicht ausreichende Spannungsversorgung,
siehe weiter oben. Die Lösung: aufpassen/vermeiden. ;)

PS: Meine Mail blieb von Dir bis heute unbeantwortet.

Torsten

@Torsten: Sorry, eine PM ist an Dich unterwegs.

Für das Ziehen der Karte oder Ausschalten habe ich eine kleine LED
installiert, die mir anzeigt, wenn gerade nicht geschrieben wird. So
richtig Austesten konnte ich das aber noch nicht.

Defekte Karte ist an Kingston unterwegs :)

Viele Grüße,
Pete

Wow ! Kingston hat eine neue Karte geschickt ! DAS nenne ich Service und
Schnelligkeit !!! (freu)

Montag abgeschickt und Donnerstag die neue Karte in der Hand. Besser
geht´s nicht :-)

Hallo,

entschuldigt bitte die naive Frage aber leider fehlt mir der Durchblick:

kann ich jetzt in Windows XP ein Paar Bitmap-Dateien erstellen, auf
einer SD-Card speichern (mit einem ganz normalen USB-Kartenleser für den
PC),
um danach irgendeine beliebige dieser .bmp-Dateien mithilfe des
Programms von Roland mit einem Mega8 auslesen?

Anders gesagt, ich will einfach Paar .bmp Dateien bequem am PC erzeugen,
die dann mit einem Mega auf einer LED-Matrix angezeigt werden werden,
als Speichermedium eben die SD-Card. Es ist nur Lesen seitens des Mega
nötig, er wird nicht auf die Karte schreiben.

Bedeutet die FAT16 Unterstützung dieses Programms, dass ich eben so
vorgehen kann und die .bmp-Dateien direkt vom PC auf der Karte kopieren
kann, ohne sie irgendwie konviertieren zu müssen?

Du musst sie nur im µC wieder zu raw dekodieren, was aber nicht äußerst
schwer ist.

@Roland, Hauke:

danke, genau das brauche ist; mein µC weiss schon, wie er mit .bmp die
LED Matrix steuert, nur schreibe ich sie z.Z. im Flash vom µC.

Ich mach'mich jetzt an die Arbeit mit der SD-Karte.

Hallo,
verwende den fat16 Zugriff von Roland Riegel. Im Prinzip funktioniert
alles prima, allerdings habe ich Probleme wenn ich der Übersicht halber
die verschiedenen Funktionsaufrufe zum erzeugen eines files in eine
eigene Funktion packe.
Der entstprechende Funktionsprototyp sieht folgendermassen aus:

uint8_t create_log_file(struct fat16_fs_struct* fs, struct
fat16_file_struct* fd1)

In der Funktion erzeuge ich meinen gewünschten Dateinamen und mit der
Funktion fat16_create_file die gewünschte Datei.
Mit fd1 = fat16_open_file(fs, &file_entry) öffne ich die Datei und weise
den als Paramter übergebenen Pointer struct fat16_file_struct* fd1 zu.

Wenn ich nun in main nach Aufruf von create_log_file folgende Zeilen
ausführe wird nichts in die Datei geschrieben.

struct fat16_file_struct* fd1;
create_log_file(fs, fd1);

char buffer[]="test";
int8_t data_len = sizeof(buffer);
/* write text to file */
fat16_write_file(fd1, (uint8_t*) buffer, data_len);
sd_raw_sync();

Wenn ich allerdings die selben Zeilen unmittelbar vor der return
Anweisung in create_log_file einfüge wird der String "test" wie
gewünscht in die Datei geschrieben.

Wird der Zeiger fd1 nach Beendigung von create_log_file ungültig (bzw.
der Bereich wo der Zeiger hinverweist)? Oder wo könnte das Problem
liegen?

Vielen Dank für eure Tips

M.

Danke, klappt jetzt.

Super!
M.

Hallo,

um meine Daten die ich auf die SD Karte schreibe zu komprimieren, lege
ich die einzelnen Variablen die ich verwende nicht direkt auf der Karte
ab sondern beschränke die Anzahl der Bits auf den tatsächlichen
maximalen Wertebereich. Die Bits der verschiedenen Variablen verknüpfe
ich zu einem Stream. Über einen Descriptor der jedem neuen Datensatz
vorausgeht ist die Länge der einzelnen Datenfelder definiert.
Im Prinzip scheint auch alles zu funktionieren, allerdings habe ich hin
und wieder beim dekodieren nach einer wechselnden Anzahl von Datensätzen
keine vernünftigen Daten mehr. Ich vermute die Ursache darin, dass beim
speichern auf die Karte dann an dieser Stelle Daten verloren gegangen
sind. Der Decodier Algorithmus kommt dann durcheinander weil er durch
das fehlende Byte um 8 Bit verschobene und somit falsche Bits für den
Descriptor einliest.
In meiner Funktion zum abspeichern überprüfe ich zwar ob das zu
speichernde Byte auch geschrieben wird, aber bekomme dort keine
Fehlermeldung.
Habe sowohl mit als auch ohne SD_RAW_WRITE_BUFFERING das gleiche
Problem.

Meine Funktion zum speichern und einen exemplarischen Aufbau des Aufrufs
findet ihr im Anhang.

Tips? Oder suche ich den Fehler an der falschen Stelle? Sind die Daten
sicher auf der Karte gespeichert wenn fat16_write_file() die richtige
Anzahl von geschrieben Daten als Rückgabewert liefert? Auf der anderen
Seite bin ich mir relativ sicher, dass die Kompression und Dekompression
richtig funktionieren. Schwierig weil der Fehler mehr oder weniger
zufällig ist.

Danke
M.

Der versprochene Anhang

M.

Hallo Roland,

ich habe eine kleinen Service-Request für Deine Bibliothek.

Ich arbeite öfter mal abwechselnd mit dem ATMega16 und ATMega644 und da
haben leider die SPI-Register unterschiedliche Namen.

Könntest Du es vielleicht etwas generischer in der Bibliothek bauen ?
Das wäre prima :-)


Gruss,
Pete

Ja stimmt sollte besser
static uint8_t data_block = 0x00;
in der Deklaration heißen.

Allerdings würde ein abweichender Startwert ja nur den ersten
gespeicherten Wert beeinflussen. Das von mir geschilderte Problem tritt
aber erst irgendwann später auf.

M.

Kann gut sein, werde mich wohl auch damit beschäftigen bis ich die
Ursache gefunden habe ;-)
Kann es zu Problemen mit der SD Card Kommunikation kommen wenn während
eines Schreibzykluses ein Interrupt ausgelöst wird? Ich empfange einen
kontinuierlichen Datenstream über UART. Im Unterschied zu deiner
Beispielkonsolenanwendung treten also immer Daten an der seriellen
Schnittstelle auf und es kann dementsprechend auch während eines
Schreibzykluses ein Interrupt ausgelöst werden.

Gruss
M.

Hallo Roland,

ich habe eine Frage zu dem Offset Parameter bei fat16_seek_file.

Wenn ich ein append machen will, geht das dann so? :

int32_t offset = 0;  // zero bytes from the end of the file ==> append
if(!fat16_seek_file(fd, &offset, FAT16_SEEK_END) { ... }

Das klappt auch, wenn das File leer ist ?

Beste Grüße,
Pete

Hi Roland,

erst mal.....super Code den Du da hast!!!
Ich benutze Deinen neuesten Code vom 20.01.07 auf einem Arm7.
Funktioniert alles prima.
Das einzige Problem das ich habe ist, wenn ich Verzeichnisse erstelle
kann ich diese nicht unter Windows XP löschen da Windows mir immer sagt,
das das Verzeichnis nicht leer ist. Selbst erstellte Dateien zu löschen
funktioniert prima auch in ertellten Verzeichnissen.
Hast Du eine Idee?

Danke im voraus!!!
Gruß
Mille

Hi Roland,

Dein Code funktioniert soweit prima außer dem einem Problem und wenn was
funktioniert sollte man nicht umsteigen! ;-)))
Wenn ich einfach ein Verzeichnis mit dem Namen "test" so anlege habe ich
das Problem:

struct fat16_dir_entry_struct dir_entry;
fat16_create_dir(dd, "test", &dir_entry);

Egal ob ich einfach nur ein Verzeichnis alleine anlege oder eine Datei
hineinschreibe. Die Datei kann ich dann unter Windows XP löschen....das
Verzeichnis allerdings nicht. Auch wenn ich nur ein Verzeichnis anlege
ohne eine Datei dort rein zu schreiben! Windows meckert dann immer!!!
Siehe das JPEG im Anhang. Auch wenn ich das Häkchen unter
Schreibgeschützt weg mache kann ich das Verzeichnis nicht löschen.
Vielleicht hast Du ja noch eine Idee?

Gruß
Mille

Hallo,

ich habe Probleme beim initialieren meiner Sd Karten. Wenn ich die
Karten unter Windows formatiere kommt es relativ oft vor, dass die
Karten nicht richtig funktionieren. Error beim Filessystem öffnen oder
mein ganzes Program bleibt schon bei der Initialisierung hängen.
Formatiere ich unter unix gehen die Karten dann vorerst wieder. Woran
liegt das? Was verwendet ihr unter Windows zum formatieren eurer Karten?

Bei einer meiner Karten habe ich zudem das Problem, dass ich hin und
wieder nach Verwendung mit dem Mikrocontroller die Karte nicht mehr
formatieren und die Dateien löschen kann - Fehlermeldung die Karte ist
schreibgeschützt.

Danke
Jeremy

Hallo Roland,

da ich demnächst einen offline Temperaturlogger bauen wollte, würde ich
gerne die Messwerte auf SD-Card speichern. Was ich auf deiner Homepage
so sehe, sieht sehr gut aus. Respekt.
Zu den Eagle Files hätte ich zwei Fragen: verwendest du von Reichelt den
"Connector 21"? Wie auch immer, wozu der Anschluss von "Pin" 10, 11, 12?
Die sind doch für den Schreibschutz der Karte, oder? Wird der
ausgewertet, bzw. benötigt man denn überhaupt? Wenn ich die Dokus zur
SD-Karte richtig gelesen habe, dann obliegt die Auswertung des
Schreibschutzes nur der Software, es wird also nichts hardwaremäßig an
der Karte ausgeschaltet. Insofern: da ich eh auf die Karte schreiben
möchte, kann ich mir die 2 Pins (+ 1 GND) auch sparen.

Gruß,

Dirk

Hallo Roland,

danke für die Antwort. Habe eben bei Reichelt die passenden Bauteile
(mit kleinen Änderungen) bestellt. Gönne mir den Luxus der
Pegelanpassung mittels Transistoren und extra Spannungsregler. Das
bischen neu layouten war auch kein Thema. Was mir dabei aufgefallen ist:
die Library in deiner Zip Datei der ersten Version enthält den
Connector, allerdings scheinen die "Platzierungen/Pins" des Connectors
nicht zu stimmen (sind um 0,05inch verrückt), so dass er im schematic
nicht angeschlossen werden kann. War allerdings kein Problem: einfach
das device mit verschobenen Pins neu erstellen, Rest passt wohl
hoffentlich (jedenfalls nach chinesischem Datenblatt von Reichelt).
Insofern bleibt unterm Strich nur zu sagen: Respekt vor deiner Leistung
die Software dazu zu entwicklen und dich so in die Materie
einzuarbeiten!

Gruß,

Dirk

Übrigens gute Meldung bezüglich FAT (zumindest in D):

http://www.heise.de/newsticker/meldung/86102

Ist Rolands Server down ? Ich bekomme keine Verbindung.

@Roland,

kurzes feedback.
Funktioniert alles prima!!! Super Arbeit!!! ->froi<-

Gruß
Mille

Also ich nutz seit einiger Zeit ne Compactflash als Festplatte.
Und habe noch keine Probleme gehabt.
Ich denke der Wert 100.000 ist der Garantierte Wert, die FLashs kommen
sicher noch höher.

Dank an Roland Riegel und die gesammte Open-Souce,
Mein Datenlogger funktionert endlich.

Was ich noch nicht verstehe ist, warum ich nach jedem ADC-Cannel wechsel
ne Dummymessung machen muß.

hallo,

hat jemand ein ein schema fuer mich? moechte das
ganze mit nem atmega16 ausprobieren, da sind die
boardlayouts leider nicht sehr hilfreich.

mal das ganze dann schnell mit eagle um/nach und
stells hier rein.

danke
 hansl

(Dieser Beitrag wurde geloescht)

(Dieser Beitrag wurde geloescht)

Wegen SD formatieren:

Gibts bei Panasonic

http://panasonic.jp/support/audio/sd/download/sd_f...

(Dieser Beitrag wurde geloescht)

(Dieser Beitrag wurde geloescht)

Auf die Erweiterung mit Datum/Uhrzeit bin ich auch gespannt...

Bei mir ist es so das der sd-reader in meinem eigenen Projekt seit
geraumer Zeit erfolgreich läuft. Allerdings in einer älteren Version;
das Problem mit Verzeichnissen unter m$ kann ich nachvollziehen wie hier
gepostet wurde.

Nun habe ich etwas Angst alle Dateien mit denen von einer neueren
Version mit einem Schlag einfach zu ersetzten. Möglicherweise sind
eigene 'Anpassungen' drin die ich einfach vergessen habe.

Roland, könntest Du evtl. ein Diff zwischen den einzelnen Versionen mit
veröffentlichen? Das wäre sehr hilfreich.

Danke noch einmal für alles,
Torsten

(Dieser Beitrag wurde geloescht)

(Dieser Beitrag wurde geloescht)

> was nehm ich da für ein Programm unter Windows?

... das gleichnamige. ;)

Wenn Du WinAVR installiert hast, guck mal unter utils\bin

Torsten

(Dieser Beitrag wurde geloescht)

Roland,

Offen gestanden hat es mich erhebliche Überwindung gekostet um den neuen
Code auszuprobieren. Sachen die gut laufen sollte man eigentlich nicht
mehr anfassen. ;)

Zuerst habe ich ein Update auf 20070301 gemacht. Per Hand so wie Guido,
mit copy&paste nach dem diff zu der alten Version. 'patch' traue ich
mich nicht auf meine Sourcen loszulassen.

Dabei ist mir aufgefallen, daß Du die GPL entfernt hast. Was bedeutet
das jetzt genau?

Dann den neuen patch per Hand eingebaut. Aus Bequemlichkeit und/oder
Vorsicht belasse ich erst einmal die Zeit so wie sie ist mit dem
eingebauten #define fat16_get_datetime. Die Daten sind mir wichtig, ich
möchte nichts riskieren. Das Datei-Datum jetzt vom RTC zu holen bedeutet
einiges an meinem Proggi umzubauen.

Ich habe dann einige neue Dateien mit dem AVR erzeugt. Anschließend die
Karte in XP's Card-Reader eingesteckt. Kein Datum im Explorer. :(

Cmd in XP ausprobiert: Ein 'dir' zeigt für eine Datei z.B.

01.01.1601  02:00 166.828 01.txt

Bestimmt habe ich irgendwo einen typo. Nur wo?
Kann ich evtl. an einer sinnvollen Stelle ein paar Bytes zur V24
schicken zum gucken was los ist? Oder muß ich die Karte neu formatieren
(was ich eigentlich nicht glaube)?

Hmm, bin etwas ratlos.

Torsten

Hallo Roland,

> Was meinst Du mit "die GPL entfernt"? Welche Version hattest Du vorher
> genau?

Eine ältere Version, welche genau habe ich vergessen.
Da habe ich etwas falsch verstanden. Bitte entschuldige.

Btw wenn Du CVS verwendest, könnte man $Id$ einfügen, das zeigt die
letzte Änderung an.

Um Tippfehler auszuschließen habe ich jetzt auf die Version 20070301
patch losgelassen:
patch -i sd-reader_fat16-time.patch.txt

Die 3 betroffenen Dateien habe ich in mein Projekt kopiert. Zusätzlich
noch etwas debug-code in fat16_create_file und fat16_create_dir
spendiert:

...
fat16_get_datetime(year, month, day, hour, min, sec);
fat16_set_file_creation_date(dir_entry, year, month, day);
fat16_set_file_creation_time(dir_entry, hour, min, sec);

printf_P((PSTR("%02d.%02d.%04d %02d:%02d:%02d\r\n")),
    day, month, year, hour, min, sec);
...

Auf der Konsole so wie es sein sollte:
01.01.2007 00:00:00
beim erzeugen von Dateien oder Verzeichnissen. Also arbeitet die
Funktion soweit.

Trotzdem das gleiche wie gestern beschrieben.
Vielleicht geht's mit einer anderen Karte, mal sehen.

Torsten

Hallo Roland,

> Das heißt, im Prinzip verwendest Du jetzt meinen Original-Code? Schön.

Yep.

> Alles was das aussagt ist, dass fat16_get_datetime() funktioniert, und
> das sind ja im Moment nur einfache Zuweisungen. Ich wollte explizit den
> Wert von dir_entry->creation_date/time wissen. Der sollte 0x3621 (für
> 01.01.2007) bzw. 0x0000 (für 00:00:00 Uhr) sein. Nur die Werte innerhalb
> von dir_entry werden dann auch von fat16_write_dir_entry() auf die Karte
> geschrieben.

Achso. Schon wieder habe ich etwas falsch verstanden, ich bitte abermals
um Entschuldigung.

Die beiden printf_P's habe ich nun geändert, sind noch an der gleichen
Stelle:

printf_P((PSTR("date: 0x%04x time: 0x%04x\r\n")),
    dir_entry->creation_date, dir_entry->creation_time);

Ich hoffe das war richtig. Heraus kommt:

date: 0x3621 time: 0x0000

> Ich glaube nicht, dass das an der Karte liegt. Das hat nichts mit der
> physikalischen Ebene zu tun.

Wie Du richtig vermutet hast hat sich mit einer anderen Karte nichts
geändert.

Debuging ist keine einfache Sache und kann evtl. länger dauern weil
alles mögliche dafür in Frage kommen kann. Wir könnten versuchen der
Sache auf den Grund zu gehen wie schon einmal per PM wenn Du möchtest.
Es schreibt sich halt einfach leichter.

Torsten

Hallo zusammen,

da hier alle SD-Karten Kompetenzen versammelt sind trau ich mich mal
eine frage zu stellen.
Ich bestreite gerade ein Projekt indem ich eine SD-Karte mit Fat16
formatierung an ein Tricore 1130 µC anbinden soll.
Im wesentlichen hab ich die Sourcecodes von Ulrich Radig übernommen,
will sagen ich hab sie an meinen µC angepasst.
Da mein µC auf 3,3V läuft hab ich die SD-Karte quasi Eins zu Eins an den
Port geklemmt.
Ich habe jetzt allerdings ein problem bei der Initialisierung der Karte.
Nachdem ich die mind. 74 Clocks an die SD-Karte bei CS=High schick,
sende ich ja das CMD 0 bei CS=LOW. Sämtliche Übertragungen der Bytes hab
ich mit dem Oszi überprüft. Nach Plan sollte die Karte dann ja 0x01hex
zurücksenden.
Die Antwort die ich bekom ist allerdings 0x3fhex.
Meine Frage lautet nun: Wie kann die SD-Karte mir z.b. einen Illigal
Command Error zurücksenden, obwohl ich doch 6 Bytes für Commando 0
hinschick.
Ich komm einfach nicht dahinter was mir die Karte damit sagen will.
Meinen Quellcode habe ich mal angehängt.

Für eine erleuchtende Antwort wäre ich euch dankbar.

Mir fällt etwas auf in

while(sd_write_command(cmd)!=0x01)
{
    if(Timeout++ >= 10) <--- [*]
    {
        return (1);
    }
}

[*] Das Timeout ist auf jeden Fall zu kurz. Ich glaube irgendwo mal
gelesen zu haben das das Aufwecken der Karte fast eine Sekunde dauern
kann.

Torsten

Also selbst wenn ich das Timeout von 10 auf 1000 erhöh kommt immernoch
0x3f zurück.

Mathias

Schau Dir doch bitte einmal die Datei sd_raw.c vom sd-reader genauer an
weil es sich in diesem Thread genau darum dreht ;)

Ob ein Timeout von 1000 für eine Zeit von rund ~1s reicht wage ich stark
zu bezweifeln. Das geht nur bei den AVR's weil man jeden Takt zählen
kann und somit die Ausführungszeit vorhersagbar ist.

Nur Vermutungen weil ich von dieser CPU/MPU noch nie etwas gehört habe:
- der Code wird in einem Cache ausgeführt
- der Compiler optimiert stark
... so das Deine Schleifen in einem 'Wimpernschlag' ausgeführt werden
nicht aber in der Größenordnung die benötigt wird.

Möglicherweise hat der Tricore einen Timer. Wenn ja, verwende besser
diesen für einen Timeout.

Torsten

Hallo Roland,

ich habe deine Schaltung nachgebaut, allerdings mit Mega64 und meine
Kontrolle ober Karte gesteckt bzw schreibschutz liegen immer auf low, da
ich keinen Sockel habe.

Problem ist aber, dass sich die Karte nicht (richtig) initialisieren
lässt.
wenn ich die Karte n paar mal rausnehme und wieder reinstecke gehts mit
viel glück.
Habe das Problem verfolgt und hab dann herrausgefunden dass er mir in
der Funktion sd_raw_init da aussteigt:

   /* reset card */
    uint8_t response;
    for(uint16_t i = 0; ; ++i)
    {
        response = sd_raw_send_command_r1(CMD_GO_IDLE_STATE, 0);
        if(response == (1 << R1_IDLE_STATE))
            break;

        if(i == 0x1ff)
        {
            unselect_card();
            return 0;
        }
    }

woran könnte das liegen? hab schon verschiedene Karten ausprobiert und
bei allen das selbe Syndrom.

Danke Stefan

Hallo Stefan,

Habe auch mal das Filesystem von Roland auf einem Mega64 probiert.
Am Anfang hatte ich auch Probleme.
Eines davon war bei sd_raw_init:

/* card needs 74 cycles minimum to start up */
    for(uint8_t i = 0; i < 10; ++i)

Bei mir wurden komischerweise nur 5 Datenpakete ausgegeben (gemessen).
Weiss der Geier, warum..
Nachdem ich es geändert hatte in

/* card needs 74 cycles minimum to start up */
    for(uint8_t i = 0; i < 20; ++i)

lief es einwandfrei.
Es ist ja ein Minimumwert. Mehr 0xFF-Bytes zu senden, schadet nichts.
Wichtig ist auch, dass der SPI Takt bei Init nicht über 400KHz liegt.
Und selbstverständlich, dass der Chip-Select für die Karte richtig
angesteuert wird.

Roland:
Welchen maximalen Lesedurchsatz hast Du hinbekommen?
Ich habe nur max. 250KBytes/Sek. geschafft. Für 512 Bytes, was einem
Sektor entsprechen sollte:

/* load file contents for speed measurements */
            uint8_t buffer[512];
            while(fat16_read_file(fd, buffer, sizeof(buffer)) > 0)
            {
            }

Ich verwende keine SPI, sondern ein externes CPLD, welches eine SPI mit
25MBits/Sek. enthält. Der Datenaustausch erfolgt rein über
Speicherzugriffe und der Status der SPI wird über einen Portpin
abgefragt, z.B. Senden:

void sd_raw_send_byte(uint8_t b)
{
    uint8_t *SDAddress;
    uint16_t i;
  if (Initcard == 1)
    i = 0x1101;  //write INIT Mode 400KBits/Sek.
  else i = 0x1102;  //write fast mode 25MBits/Sek.
  SDAddress = (uint8_t *) i;
  *SDAddress = b;  //write  Data
_asm__ __volatile_ ("nop");  //allow "Ready" to change
  while (PIND & (1<<PIND0)) //wait for "Ready"
  {
  }
}

Dein Filesystem ist sehr komfortabel. Bin zwar noch nicht ganz
durchgestiegen, weil ich noch nicht solange in C programmiere, aber es
funzt. Was ich noch gerne machen würde, wäre den Zeichenvergleich für
den Dateinamenszugriff Case-unabhängig zu machen. So dass man beim
Konsolenbetrieb nicht immer exakt auf Groß/Kleinschreibung achten muss.
Bin aber noch nicht durch Deine Strukturen durchgestiegen, bzw. wie die
Eingabestrings mit den Dateinamen verglichen werden.
Auch will ich mal versuchen, komplette Sekoren oder gar Cluster komplett
einzulesen, ohne die ständigen Bereichsabfragen, die (so wie es
aussieht), das ganze ziemlich ausbremsen.
Aber sonst: Hohes Lob!

Joachim

hallöle,
funzt der code auch mit sehr grossen speicherkarten (ca. 10 GB oder so)?
sorry, aber ich wollt' mir nicht alle ~300 beiträge hier durchlesen...

(Dieser Beitrag wurde geloescht)

(Dieser Beitrag wurde geloescht)

Hallo!

Hatte oben mal geschrieben, dass der Schreibdurchsatz sehr gering sei.
Das wollte ich hiermit mal klar stellen ging auf meine Kappe. Hatte
schon vor ein paar Wochen rausgefunden, dass ich den sizeof falsch
verwendet habe und eine Puffergröße von 2 Bytes statt 512 hatte. Aber da
sieht man mal, wie entscheidend diese Puffergröße ist.

Vielen Dank für die Aufnahme meines Patches. Ist ja doch noch eine Menge
Leben drin in den Routinen.

Grüße!

Hallo,
ich suche die Original-CID und -CSD der SD-Karten
Kingston Elite Pro 256MB
Platinum 1GB

Fragt mich nicht wie, aber mir ist es (unfreiwillig) gelungen,
die read-only-Register CID und CSD dieser Karten kaputt zu bekommen.
Bei der Kingston-Karte steckt eine halbe Kopie der CSD in dem CID-
Register.
Bei der Platinum-Karte stimmt die CRC7 bei CSD nicht. Was wieder
eine ganze Reihe von Fragen aufwirft. ;-)

Vielen Dank!
August

Hallo Roland,

ich brauche für ein GPS-Fahrtenbuch Schreibzugriff auf eine MMC, also
habe ich dein Projekt getestet:
-Mega16 auf das STK500 gesteckt
-Vtarget auf 3.3V konfiguriert
-MMC Sockel mit einem Stück Flachbandkabel an PORTB angesteckt
-Projekt kompiliert & geflasht
-> Funktionierte auf Anhieb wunderbar!

Wenn meine Platine da ist werde ich dann noch das NMEA Parsen & GPX
schreiben (das Gerät soll direkt GPX Dateien auf die Karte schreiben)
implementieren. Ich habe auf der Platine einen Goldcap mit 470.000 µF
vorgesehen, mal sehen ob das reicht um die Daten noch gar auf die Karte
zu schreiben wenn der Strom abgestellt wird...

Also vielen Dank für das Projekt,

Gruß
Stefan

Hi,

hab folgendes problem mit dem Code

sd_raw_init()
partition_open()
fat16_open()
fat16_get_dir_entry_of_path()
und fat16_open_dir()

sind erfolgreich. Wenn ich dann aber fat16_create_file() oder
fat16_create_dir() benutzen will, hängt er sich auf oder hat den Fehler,
dass er keinen freien Clsuter findet.

Die MMC wurde mit knoppix auf fat16 partitioniert (16 MB groß) und mit
mkdosfs formatiert.

Bin echt am verzweifeln, weil ich keinen logischen Grund finde...

Grüße
Christian

hallo,

ich hab grad laut anleitung von ulrich radigs webseite ein
brotbrett bestueckt.

http://www.ulrichradig.de/site/atmel/avr_mmcsd/gfx...

der aufbau ist:

ein stk500 mit atmega16 und 16MhZ quarz (laeuft).

die +5V beziehe ich vom VTG anschluss an portB.

sollten da beim mmc anschluss nach den 2 dioden nicht um die 3.7V
zu messen sein? bei mir ist es davor: 4.96V und nach den 2 1N418 4.32V.

jemand ne idee wo ich mich verbastelt haben koennte?

mfg
 Hansl

btw. mit 4 dioden komm ich auf 3.7V

gibts unterschiedliche 1N4148er ?

RTFM.

Wenn du das Datenblatt gelesen hättest, wüsstest du, dass der
Spannungsabfall vom Strom abhängig ist, der durch die Diode fliesst.

jemand: merci, habs eben nachgemessen. stimmt.

@ jemand

Genau. Die nächste Frage von Hansl kann man schon raten.
Wieso funktioniert SPI mit den Spannungsteilern
nicht bei 8MHz ;)

Es ist doch immer wieder das gleiche leidige Thema :(

holger:

pack deine kristallkugel wieder ein und entspann dich.

mcu ist geflasht. ausgabe am terminal is auch da.
nun brauch ich nur noch irgendwo die mmckarte fat16 formatieren.

mfg
 hansl

SPI funktioniert bei mir sehr wohl mit den Spannungsteilern, auch bei
14,x MHz. Die 3,3V Spannungsversorgung mit der Diodenlösung dagegen
nicht. Unbedingt, das wurde mehrfach erwähnt, einen eigenen Regler dafür
verwenden.

VORSICHT mit dem LM317 und einigen 3,3V Festspannungsreglern: Manche
brauchen eine Mindestlast von einigen mA!

Eine SD-Karte braucht nur Strom wenn darauf zugegriffen wird. Bei einem
ungeeigneten Regler könnte die Spannung auf unzulässige Werte
hochlaufen.

Sehr gute Erfahrungen habe ich mit einem "LP 2950 CZ-3,3" gemacht.

Meinen 5V-Regler (78L05) habe ich wegen der guten Erfahrungen durch
einen "LP 2950 CZ-5,0" aus der gleichen Familie ersetzt. Ein feines Teil
btw, der Ruhestrom liegt im µA Bereich. Das kann wichtig für
Batterie-Betrieb sein: der Ruhestrom ist ca. 5mA geringer pro Regler.
Beide gibt es für 60 Cent bei Segor.

Torsten

Hallo,

torsten: danke, hab diese fehlerquelle mal enfernt.

Hab nun anstelle der moeglicherweise wackeligen diodenloesung genau
wie stefan ein paar posts weiter oben beschrieben hat die VTARGET
konfigurationsmoeglichkeit des stk500 benutzt.

Leider ist alles was in der console zu sehen ist dies hier:
"MMC/SD initialization failed"

jemand ne idee woranns liegen koennte? oder kommt die meldung
auch wenn kein-oder ein ungueltiger partitiontable oder fat
gefunden wurde?


hier noch ein paar details zum setup:

SPI ist enabled (0)

die konfiguration der Anschluesse beim Atmega16:
PORTB4(SS)   - MMC CS *via spannungsteiler
PORTB5(MOSI) - MMC DI *via spannungsteiler
PORTB6(MISO) - MMC DO
PORTB7(SCK)  - MMC CLK *via spannungsteiler

uisp -dprog=stk500 -dserial=/dev/ttyS0 -dspeed=115200 -dpart=atmega16
--rd_aref --rd_vtg --rd_fuses
Firmware Version: 1.14
VTarget = 3.3 V
ARef = 3.3 V
Atmel AVR ATmega16 is found.
Firmware Version: 1.14

Fuse Low Byte      = 0xff
Fuse High Byte     = 0xd9
Cannot read extended fuse bits on this device. Returning 0xff
Fuse Extended Byte = 0xff
Calibration Byte   = 0xbf  --  Read Only
Lock Bits          = 0xff
    BLB12 -> 1
    BLB11 -> 1
    BLB02 -> 1
    BLB01 -> 1
      LB2 -> 1
      LB1 -> 1


achja, die karte ist ne 128MB MMC - takeMS. die hab ich noch
nie benutzt, weis also weder ob noch wenn womit die formatiert ist.


mfg
 hansl

> jemand ne idee woranns liegen koennte? oder kommt die meldung
> auch wenn kein-oder ein ungueltiger partitiontable oder fat
> gefunden wurde?

Ähem - wenn Du die Sourcen durchlesen würdest, wüsstest Du, dass bei
DIESER Meldung noch gar kein Partitionseintrag eingelesen wurde.
Diese Meldung bezieht sich rein auf sd_raw_init().
Die Karte sendet also keine gültigen Response-Daten.

Also zu 90% Hardware- oder Interface-Fehler.
Musst halt mal anzeigen lassen, was die Karte überhaupt antwortet. Wenn
sie denn überhaupt antwortet.

NEUE Karten in der Größe <=2GB sollten ab Werk ausschließlich mit FAT16
formatiert sein. Ich habe noch niemals eine andere gesehen und schon ca.
300 Stück verschiedener Karten "verbaut".
Vorsicht bei gebrauchten aus Ebay: Da wurde oft schon drauf
rumgepfuscht.
Wenn die Karte unter Windows neu formatiert wird, macht Windows in
vielen Fällen FAT12 draus, wenn die Karte relativ klein ist (z.B. 64MB).

Bei ersten Versuchen würde ich Billigkarten vermeiden.
Manche haben ein Problem mit dem SPI-Modus, obwohl sie in Kameras oder
Cardreadern problemlos laufen. Will hier keine Schleichwerbung machen,
aber Karten von SanDisk oder Kingston waren bei mir immer problemlos.

Zum Thema "Spannungsteiler mit Widerständen" wollte ich noch sagen, dass
die allseits bekannte Schaltung bis 4MHz funktioniert. Bei meinem M16C
Kontroller geht das sogar noch bei 8MHz SPI-Takt. Allerdings liefen
manche Kartenfabrikate nicht, vor allem irgendwelcher Noname-schrott ala
"extreme-memory". Billige Karten reagieren recht sensibel auf allzu
"verwaschene" Signale.
Sichere 8 MHz mit AVR erreicht man mit niederohmigeren Widerständen.
Also nicht im Bereich 1,8/3,3 KOhm, sondern zum Beispiel 330/620 Ohm.
Bedeutet natürlich eine höhere Strombelastung, aber die Flanken werden
wieder steiler und somit ist eine höhere Frequenz möglich.
Auf "wundersame" Weise funktionierten danach auch Karten, die sich
vorher niemals haben ansprechen lassen ;-)
Bei 12Mhz ist mit der Spannungsteilerlösung so ziemlich Schluss.
Aber die werden mit einem AVR eh nicht erreicht.
Wenns also billig sein muss und der AVR unbedingt an 5V laufen muss,
dann funktioniert diese Lösung in jedem Fall.
Mittlerweile arbeite ich mit ARM und da tritt das Problem
glücklicherweise nicht mehr auf :-)


Joachim

joachim: danke fuer die ausfuehrungen. werd mal mit dem hardwareaufbau
herumexperimentieren.

den code hab ich mir natuerlich angesehen != verstanden.

bei elm chans software blick ich leider noch weniger durch.

mfg
 Hansl

Hat noch jemand die ursprünglichen AtMega8 Sourcen für ein FAT
Filesystem und
kann er die Hier im Forum zur Verfügung stellen?
Das Ganze soll als Basis für einen kompakten Datenlogger dienen.
Schon im Voraus vielen Dank.

Hansl:
Jetzt muss ich aber nochmal fragen: Du hast die Versorgung des Boards
auf 3,3V gesetzt und die Spannungsteiler dringelassen???
So interpretiere ich jedenfalls Dein vorletztes Posting.

Joachim

joachim:
jepp, hab ich. nach ein wenig gruebeln war mir dann klar das das topfen
ist :) und habs rausgenommen. mittlerweile hab ich die MMC karte bei
nem freund getestet und es hat sich herausgestellt das weder dessen
cardreader noch sein palm pilot mit dem ding was anzufangen weiss.

der palm meldet eine fehlerhafte karte, der windoofpc aeussert sich
nicht dazu.

hab heute um 5 euronen ne 128mb RS-MMC karte von Lexar, was auch immer
RS sein soll, gekauft und nen LT1086 CM-3.3 von nem fibrechanneladapter
gebrutzelt.

werde des naechtesns wenns klima wieder passt einen 2. versuch starten
:)

dann wieder mit spannungsteiler am SPI und 5V VTARGET.

mfg
 Hansl

es ist verhext. immer noch die MMC/SD initialization failed
fehlermeldung :(

elektrisch sollte alles korrekt sein. mmc wird durch nen LT1086 CM-3.3
versorgt.

habs nun mal mit 330 und 650 Ohm widerstaneden als spannungsteiler
probiert aendert auch nichts. gestern hat die karte in nem cardreader
aufjedenfall einwandfrei funktioniert. also wenn ich die karte nciht
irgendwie beim aufbauen geschrottet hab sollte die nun funktionieren.

folgendes habe ich messen koennen(mieses multimeter):
CS       (MMC PIN1, MCU PB4)   3.24V
DATA IN  (MMC PIN2, MCU PB5)   3.24V
VCC      (MMC PIN4)            3.27V
DATA OUT (MMC PIN7, MCU PB6)   4.74V

hab keinen schimmer woranns liegen koennte :(

achja, ISP kabel abziehen bringt auch nix.

weitere debuggingtips?

mfg
 Hansl

Hast du einen 100nF C über die 3,3V direkt am Kartenslot?

Bei mir läuft seit fast zwei Jahren die folgende Beschaltung.
Der interne PULL-UP am MISO ist deaktiviert

Für Signale vom uC an die Karte (CS, MOSI, SCK)

        3v3 ^
            |
           | |
           | | 47k
           | |       2k2
            |     _____
MMC/SD -----O-----_______------  uC (out)
            |
           | |
           | | 3k9
           | |
            |
           GND

Data-Out der Karte (MISO)

        3v3 ^
            |
           | |
           | | 47k
           | |      330
            |     _____
MMC/SD -----O-----_______------ uC (MISO)

werner:
hab nun auch deine schaltung aufgebaut, und in Rolandscode
noch ein PORTB &= ~_BV(PB6); ergaenzt um den pullup des MISO
PORTS zu deaktivieren. ergebnis unveraendert.

ich vermute das irgendwo am stk500 der hund begraben liegt...
nur wo?

dies ist nun der dritte aufbau. diesmal sogar mit 8Mhz internem takt!
und 100nf C am mmc. sicher ist sicher :)

anbei nochmal meine aktuellen fusesettings:

Fuse Low Byte      = 0xd4
Fuse High Byte     = 0xd9

Atmega16 @ 8MhZ, JTAG DISABLED

die mmckarte funktioniert. aufjedenfall hab ich das dintg gestern
nochmal getestet. leider aber nur mit einem palm :(

jemand irgendeine idee? ich tippe auf das stk500, denn das
ist das einzige an dem ich ausgenommen von "spi-programmingkabel
trennen" nix geaendert habe..

mfg
 Hansl


aus dem, hey das guck ich mir schnell mal an ist mittlerweile ein
jahresziel geworden ;)

Tips hast Du bekommen, nur ob Du die umsetzt, ist fraglich.
Beim Lesen Deiner Beschreibungen kommt es einem so vor, als ob Du
"wahllos drin rumstocherst".

1. Besorg Dir ein Oszi und mess die SPI Leitungen. Gib dazu ein Muster
an SPI aus z.B. 0x5A und schau Dir die Signale SCLK und Data direkt an
der SD Karte an. Messe auch den Chip select.
Denk dran: Im Initmode darf die SD Karte maximal 400KHz bekommen.
Multimeter kasste vergessen. Man kann Hardware solange "blind"
programmieren, wie man Glück hat, dass alles klappt. Wenn aber der Wurm
drin ist, kommt man ohne das richtige Messzeug nicht weiter.
Wenn Du gar keine Chance hast, ein Oszi zu bekommen, dann bastel Dir
eine verbindung zwischen den Anschlüssen Data In und Data Out der
SD-Karte (natürlich solange diese NICHT eingesteckt ist :-) und mach
einen Loopback-test der SPI-Schnittstelle. Also ob das Byte, welches Du
sendest auch wieder reinkommt.

2. Gebe nach JEDEM Schritt ALLE empfangenen Daten der SD-Karte auf Dein
Terminal aus. Wenn gar nichts kommt, dann erzeuge zusätzliche
Hilfsmeldungen und sieh nach, WO in den Funktionen ein Timeout erfolgt.
Roland hat ja schon die UART implementiert, also wo ist das Problem?

Es geht nur Schritt für Schritt. Und immer nur EINE Sache ändern bzw.
testen, niemals MEHRERE gleichzeitig. Das ist extrem wichtig.
Und um Himmels Willen - besorg Dir irgendein billiges Oszi ;-)

Joachim

joachim:

zu 1:
oszi hab ich keins, kenn niemanden mit einem und kann ich mir auch
dieses jahr wohl sicher keines leisten.

loopbacktest, klingt einleuchtend, mal sehn ob ich dazu code finden
kann.

zu 2:
das mit dem code aendern ist ja nicht so einfach wenn man nicht
versteht was da genau passiert. vorallem besteht bei mir eher die
gefahr das der code wenn ich drinn ein wenig rumruehre ploetzlich
nichtmehr tut und dann faengt das "wahllos herumstochern" erst an.

ein paar printfs in "uint8_t sd_raw_init()" waern schon praktisch.
mal gucken wie ich das angehen koennte. das Jahr ist ja noch lang :)


hab wohl immer eine sache geaendert :) mal die widerstaende
ausgetauscht.
dann mal den takt geaendert, dann mal nen kondensator dazu, dann mal ne
neue MMC karte ran.....worauf willst DU HINAUS? (caps konnt ich mir ned
verkneifen ;))

mfg
 Hansl

> loopbacktest, klingt einleuchtend, mal sehn ob ich dazu code finden
> kann.

Wirst Du kaum. Musst Du selber programmieren.
Aber es gibt sicher irgendwo Basisroutinen zum Schreiben und Lesen eines
Wertes an/von SPI.
Um möglichst die originale Initialisierungssequenz zu nehmen, müsstest
Du den Loopbacktest hier einfügen (in der Main.c):

 /* setup sd card slot */
    if(!sd_raw_init())
    {
#if DEBUG
        uart_puts_p(PSTR("MMC/SD initialization failed\n"));
#endif
        // HIER DEN LOOPBACK TEST
        return 1;
    }

Da beim betrieb ohne Karte und gebrücktem DIN/DOUT die Fehlermeldung
natürlich vorprogrammiert ist, muss der Test genau hinter der
Fehlermeldung rein. Der Vorteil: Du kannst die vorhandene SPI-Init
nehmen.

> das mit dem code aendern ist ja nicht so einfach wenn man nicht
> versteht was da genau passiert.

Du sollst ja nicht sehr viel ändern, sondern nur ergänzen!
Der Trugschluss bei solchen Fremdprojekten ist, dass man sich die Arbeit
sparen kann. Das geht, wenn man Glück hat und alles funktioniert (was in
den seltensten Fällen so ist).
Wenn man aber hängt, braucht man viel Zeit, durchzusteigen.
Da solche Projekte meist schon sehr weit gediehen und optimiert sind,
und mit allen möglichen Features ausgestattet, ist es sehr schwer, die
relevanten Punkte herauszulesen. Man braucht oft lange, herauszufinden,
WO WAS und WARUM definiert ist.
Geht mir auch nicht anders. Da muss man durch.
Ich mache es aber so: Wenn etwas absolut nicht laufen will, dann
schreibe ich mir erstmal ein paar eigene Testprogramme für die Hardware.
Erst wenn diese erfolgreich verlaufen, kehre ich wieder zum Projekt
zurück.

Ich würde vorschlagen, Du vergisst erst mal die Sd-Karte und beginnst
damit, die SPI-Schnittstelle selber mal zu programmieren (einen besagten
Loopbacktest zu schreiben).
Wenn das dann funktioniert, kannst Du wieder zur SD-Karte zurückkehren.

Joachim

Hallo,

hab nun ein wenig herumkopiert und sende nun 0XFE als testwert.

scheine es aber nie zu empfangen.

hab ich da einen offensichtlichen fehler drinne?

oder ist meine hw total hinueber?

mfg
 Hansl


anbei das gaenderte main.c aus sd-reader_source_20070603
dabei handelt sichs eiegentlich nur um einwenig copy&paste
aus sd_raw.c.

zur hardware... hab einfach mosi und miso verbunden.
ansonst, alles beim alten, atmega16@8Mhz(interner taktgeber), stk500
fuses:Fuse Low Byte = 0xd4, Fuse High Byte = 0xd9

mfg
 Hansl

ok, klappt doch,

hab vergessen das ueberfluessige zeug auszukommentieren :)

nungut. also spi funktioniert also grundsaetzlich.


aendeurng in main.c von zuvor:

uint8_t sd_raw_rec_byte()
{
    /* send dummy data for receiving some */
//    SPDR = 0xff;
//    while(!(SPSR & (1 << SPIF)));
//    SPSR &= ~(1 << SPIF);
    return SPDR;
}


mfg
 Hansl

> hab vergessen das ueberfluessige zeug auszukommentieren

Ahaaa ;-)

Na also, nachdem Deine SPI nun sendet und empfängt, musst Du sehen, ob
das Chipselect signal für die Karte anliegt.
Das kann man leider nicht simulieren sondern nur messen.
Checke auch, ob Du den richtigen Port für das Selectsignal eingestellt
hast.
Das Select ist definiert in der sd_raw_config.h für die verschiedenen
Kontrollertypen:

#define select_card() PORTB &= ~(1 << xxxx)
#define unselect_card() PORTB |= (1 << xxxx)

Desweiteren würde ich für den Anfang die hohe Taktrate für die SPI
abschalten und folgende Zeilen auskommentieren (in sd_raw_init() in der
sd_raw.c). Das kannst Du gleich tun. Es beeinflusst die Gesamtfunktion
nicht, schützt Dich aber vor weiteren möglichen Hardwareproblemen.

/* switch to highest SPI frequency possible */
    SPCR &= ~((1 << SPR1) | (1 << SPR0)); /* Clock Frequency: f_OSC / 4
*/
    SPSR |= (1 << SPI2X); /* Doubled Clock Frequency: f_OSC / 2 */

Erst wenn die Karte komplett läuft, gibst Du dies wieder frei.
Läuft die Karte DANN nicht mehr, kannst Du sicher sein, dass Dein
Interface den hohen Takt nicht veträgt und die Signale "verwaschen".

Tja - viel mehr fällt mir dann auch nicht mehr ein.

Joachim

Immer noch kein Licht am Ende des Tunnels :(

Hab nun fogendes Setup:
 STK500 auf 3.3V konfiguriert, Atmega16 @ 8MhZ, JTAG deaktiviert
 ISP KABEL abgesteckt!

Hardwaresetup:
 PORTB4 ------- CARDSELECT, PIN1       (gemessen 3.3V)
 PORTB5 ------- DATAOUT,    PIN7
 PORTB6 ------- DATAIN,     PIN2
 PORTB7 ------- CLOCK,      PIN5
 VTG ---------- VCC,        PIN4       (gemessen 3.3V)
 GND ---------- GND,        PIN3 & PIN6

Software anbei. (Mit den von Jochaim empfohlenen Aenderungen)

falls irgendjemand noch ne idee hat worans liegen koennte...bitte
schreien!

werd mir falls da nix mehr zu debuggen geht wohl oder uebel ne
platine aetzen und das ganze mal ohne stk500 probieren.

mfg
 Hansl