hallo,

hier mal meine fat16/fat32 lib für atmel atmegas.
noch ich sag mal im alpha 2 status ;)

was geht ist:

- auslesen eines MBR ( muss im code eingestellt werden...)

- datei anlegen        open('w',rstr);
- datei schreiben      ffwrite(c);
- datei anhängen       open('a',rstr);
- datei lesen          c=ffread();
- datei löschen        ffrm(fileName);
- direktory wechseln   ffcd(dirName);  (immer nur eins nach dem anderen)
- direktory anzeigen   ffls();
- datei seek           ffseek(234);    (ab stelle 0, nur beim lesen)

- commando promt    hier kann komplette funktionalität getestet werden !
- umwandeln von "t.txt" -> "T        TXT"    fat_str("t.txt);


mit einem atmega168 @ 20 mhz schafft man lesend ~ 220.000 bytes/sec,
mit einem atmega32  @ 8  mhz schafft man lesend ~  20.000 bytes/sec,
bei fat 32 mit größeren clustern wird es immer schneller ;)

würde mich über anregungen, oder verbesserungsvorschläge freuen !

ps: hab Ulrich Radigs mmc.h/mmc.c etwas erweiter, an dieser stelle danke
    für die veröffentlichung dieser dateien.

grüße daniel

hallo,

einige bug-fixes sind gemacht, eine lib zum einlesen von
tastatureingaben, über eine at-tastatur ist jetzt dabei.

nur falls es jemanden interessiert ;)

g das thema interessiert doch immer.

wie sieht es mit dem speicherbedarf aus? funktioniert der code auch - 
read only - auf einem atmega16 (1kb ram)?

hallo,

@ Alexander D.

würde sogar mit write funktionieren, man müsste nur in der main auf ein 
paar sachen verzichten, wie den commando prompt und so. nur die 
fat-0.x.c und file-0.x.c sind auch super so zu gebrauchen.

@ gast

quellen sind einmal die Fatgen103.pdf spezifikationen von MS gewesen und

https://www.pjrc.com/tech/8051/ide/fat32.html

entickelt hab ich das ganze mit linux.
habe mir raw images von mmc/sd karten gemacht und das mit 
low-level-datei-lese funktionen mit linux gcc geschrieben, da kann man 
dann schön debugen.


zu dem code,
das einzige problem, warum read und write nich z.b. auf einem atmega8 
läuft ist, weil nicht genügend flash da ist, ram würde locker reichen.

hallo,

neue optimierungen und bugs beseitigt beim schreiben !

fat16 schreiben von 60.000 bytes in 1,421 sec -> 41KB
fat16 lesen     von 60.000 bytes in 0,823 sec -> 71KB

fat32 schreiben von 60.000 bytes in 1,249 sec -> 46KB
fat32 lesen     von 60.000 bytes in 0,747 sec -> 78KB


die werte, mit atmega32 @ 8 mhz (interner takt).

status: ist jetzt voll funktionsfähig !


grüße daniel

hallo,

@  Siegmar

danke, hört man gerne :)
wenn du zum testen kommst, laß doch mal hören wo es hinkt,
wenn es hinkt ;)

@ holger

ja werd ich machen. nur noch keine lust gehabt...
ist mir auch noch ein kleines rätsel warum das unbedingt nötig ist.
würde es reichen nur die funktionen in einer *.h datei "bekannt" zu 
machen, die von anderen *.c dateien aus aufgerufen werden ? das würde 
für mich am meisten sinn machen. wäre dann quasi sowas wie private oder 
public. also private nur in der *.c selber als prototyp, public in der 
*.h...

hallo,

@ kalhou

es kommt auf die größe der karte an. manche sind zu klein um sie mit 
fat32 zu formatieren. andere wieder sind zu groß um sie mit fat 16 zu 
formatieren...
welchen controller willst du denn benutzen und wie willst du die karte 
anschließen?

grüße daniel

hallo,

kleinere änderungen, grad der optimierung erhöht.

ohne lcd, tastatur und benchmark teil,
jetzt 709 bytes statischer ram (bei lesen und schreiben mit commando 
prompt) und 10127 bytes an flash speicher verbrauch.
mit allem 740 ram und 11796 flash.

compiler optimierung 2 besser als s...


grüße daniel

hallo,

@ kalhou

also beschreiben einer datei würde wie folgt laufen:

//1
ffopen('w',"DELME   TXT");                      
                               
//2
unsigned char str[22]="das soll auf die karte";           
unsigned char i=0;

//3
do{

   ffwrite(str[i]);
   i++;
}while(str[i]!='\0');

//4
ffclose();

-1 die funktion ffopen erwartet als datei bezeichnung einen string im 
8.3 format, alles großgeschrieben ! man kann zum wandeln von z.b. 
delme.txt" die funktion fat_str nutzen, die macht aus "delme.txt" "DELME 
TXT".

-2 str enthält 22 bytes die auf die karte sollen, i ist nur ein index 
zähler für den str

-3 in der schleife wird auf die karte geschrieben, der ganze string

-4 schließt die datei (erst hier wird die datei tatsächlich angelegt, 
vorher werden nur die daten der datei auf die karte geschrieben)

noch zu 1:
es gibt auch noch ffopen('a',"DELME   TXT"); das würde die datei zum 
anhängen öffnen, wird dann ab letztem zeichen weiter geschrieben.

nur öffnen zum lesen wäre ffopen('r',"DELME   TXT"); und dein obiger 
code

hallo,

sieh dir mal mit einem hex editor die daten auf der karte an.

da wirst du sehen, dass dort 8.3 einträge und lange datei namen drauf 
sind.
bei allen 8.3 datei namen werden großbuchstaben sein. wenn der datei 
name bzw. die endung nicht 8 bzw 3 zeichen haben, wird mit leerzeichen 
aufgefüllt, bis 8.3 erfüllt ist!
wenn du mit dem pc eine datei auf der karte anlegst, dann wird es bei 
dem beispiel "delme.txt" einen 8.3 eintrag geben der "DELME   TXT" 
lautet. nur mit diesen 8.3 namen arbeitet die library.
fat_str ist aus dem grund nicht in ffopen integriert, weil es auch ohne 
läuft und ich das ganze so schrumpfen möchte, das es irgendwann auf 
einen mega8 passt.

-1. egal was für eine datei du anlegst, es wird immer ein großbuchstaben 
8.3 name mit angelegt. von jedem betriebssystem, dass ich kenne.

-3. da ist die funktion zum schreiben von strings...

ffwriteString(unsigned char str[],unsigned char name[], unsigned char option){

  ffopen(option,name);                      
  unsigned long int i=0;    


  do{

   ffwrite(str[i]);
   i++;
  }while(str[i]!='\0');

 
  ffclose();
}

nur so aus dem kopf, sollte aber gehn :)


-4. mehrere dateien wird es erstmal nicht geben, aus ram gründen.
aber du hast doch schon einen weg aufgezeigt wie es gehen könnte. wenn 
du es änderst, poste doch einfach mal eine ergebnisse :)

zu dem problem mit dem anhängen, werd ich später mal ausprobieren...

hallo,

bei mir gibt es mit folgendem code keine probleme:

  // löscht datei, wenn vorhanden...
  ffrm("DELME   TXT");    
  
  // schreibt in die datei (kann nur schreiben wenn nicht vorhanden ist)
  ffwriteString("das soll in die datei","DELME   TXT",'w'); 

  // anhängen von daten
  ffwriteString(", mehr noch","DELME   TXT",'a');

benutzt wird die ffwirteString von siehe oben...

wegen dem einlesen von strings kannst du dir ja nach dem beispiel was 
basteln...

grüße daniel

daraus wird dann: langed~1, langed~2 usw... ist dann etwas 
unübersichtlich ;)

vorallem wenn es so etwas ist wie langedatei-wichtig-von-chef.txt und 
langedatei-wichtig-von-frau.txt weil daraus auch langed~1 und langed~2 
wird

Dürfte wohl für den Controller weniger einfach werden, anhand des 
Inhaltes einer Datei darauf zu schliessen, wie der originale Dateiname 
lautet. Es sei denn der originale Dateiname steht versteckt irgendwo in 
der Datei, was ich mir aber nicht vorstellen kann!
Das Problem ist ja, dass wenn ich die Datei 
"langedatei-wichtig-von-frau.txt" öffnen will, nicht beide Dateien 
"langed~1" und "langed~2" aufmachen sollte, um herauszufinden welche der 
beiden jetzt die Datei ist die ich brauche.

Das Problem ist nur, wenn ich auf meinem MP3-Player eine Datei in Form 
von "Interpret - Titel" ablege, bekomme ich schon mächtig Probleme, da 
z.b. ein Album 10 Lieder drauf hat "Interp~1...10" wird schon ein wenig 
schwierig zum auslesen.

hallo,

das problem von langen dateinamen ist das die auch mal 255 zeichen lang 
sein können.
ich finde, wenn man z.b. einen mp3 player baut, sollte der auch die id3 
tags anzeigen wenn er die lieder spielt. es git doch pc programme, die 
die mp3 sammlungen sortieren und ordentlich tagen...

grüße daniel

hallo,

die funktion "lsRowsOfClust(unsigned long int start_sec)" in file-0.3.c 
bekommt einen start sektor eines clusters übergeben und arbeitet dann 
selbständig den cluster ab (also die sektoren). und in dieser funktion 
benutzt du einfach anstatt der uart ausgaben, einen teil in dem du die 
namen oder was auch immer dich interessiert von der datei woanders 
speicherst.
in dem teil wo die uart ausgaben sind ist die aktuelle datei auf dem 
struct:file zu finden, mit allen möglichen angaben. in dem struct:fat 
ist der aktuell geladenen sektor zu finden.
macht zusammen: name, attribut, reihe in sektor, den sektor selber, 
größe, länge, 1.cluster. also alles was man zur weiteren verarbeitung 
braucht.

hilft das?

güße daniel

1) In eine Codesammlung gehört fertiger, funktionsfähiger Code. Sagt ja 
der Name schon.

2) Gute Programmierkenntnisse der verwendeten Sprache sind dafür 
zwingend erforderlich.(#include "fat-0.3.c")

3) Es gibt bereits (erprobte) Libs hier in dieser Codesammlung die 
SD/MMC + FAT unterstützen. Wozu das Rad neu erfinden?

hallo,

@ Torsten S.

sieh mal in meinen ersten post, 4. zeile...

#include "fat-0.3.c" funktioniert doch oder? übersichtlicher ist das 
auslagern von prototypen in *.h dateien auf jeden fall nicht !
c standart ist, dass jede datei auch einzelnd compilierbar sein soll. 
ist doch so auch gegeben.

warum das rad neu erfinden? weil ich mein eigenes rad will! zudem hat ja 
wohl selber machen noch den größten lerneffekt. so wie theorie und 
praxis halt !

@  kalhou

schick mir ein image von der karte und dem von dir verwendeten code, 
dann kann ich dir genau sagen woran es liegt. sonst must bischen selber 
probieren. bei mir läuft es, das einzige problem sind mit linux 
formatierte karten, weil die komischerweise das root dir, wenn es nur 1 
cluster groß ist mit 0x0ffffff8 als ende markiert haben...
und dachte es ist eindeutig, man kann IMMER nur eine datei zum 
lesen/schreiben/anhängen öffnen! man kann aber durchaus mehrere 
nacheinander öffnen usw...

Daniel Platte wrote:

> warum das rad neu erfinden? weil ich mein eigenes rad will! zudem hat ja
> wohl selber machen noch den größten lerneffekt. so wie theorie und
> praxis halt !

OK. Warum nicht. Aber bitte erst wenns fertig ist in die Codesammlung.

> #include "fat-0.3.c" funktioniert doch oder? übersichtlicher ist das
> auslagern von prototypen in *.h dateien auf jeden fall nicht !

Ein großer Fehler, diplomatisch ausgedrückt. Sei froh, das noch keiner 
von den C-Experten seinen Senf dazugegeben hat.

Bitte meine Posting nicht als rumnörgeln betrachten, sondern als 
konstruktive Kritik um Dich auf den "richtigen" Weg zu bringen.

Torsten

hm,

meiner meinung nach ist der code schon durchaus brauchbar. vielleicht im 
falschen forum, mag sein. dann möge es bitte jemand verschieben.

bei der letzten version mmc-0.3.zip läuft bei mir mit verschieden 
formatierungen und cluster größen alles gut.

warum sind *.h dateien denn so wichtig? bzw der richtige weg (hatte es 
ja auch schon geändert..)?

bin offen für verbesserungen und anregungen, ist ja der sinn weshalb der 
code hier öffentlich rumsteht :)

güße daniel

Hier ist mein Beispielcode!

Habe gewisse Anpassungen an den Libraries vorgenommen z.b. die Struktur 
für Fat und File im Headerfile definiert etc. aber der Code sollte 
allgemein verständlich sein.

Auf der SD Karte hatte ich lediglich 3 Ordner (ORDNER1,2,3). Die Karte 
ist eine 1GB SanDisk und ist mit FAT32 formatiert.

Der Code wurde im AVRStudio compiliert, daher stammt auch das Makefile, 
welches noch im Ordner enthalten ist.



Gruss

[EDIT]
hab gerade gesehen, dass die Karte mit FAT16 mit Vista formatiert war. 
Hab sie dann FAT32 formatiert und ging gleich. Allerdings bleibt mein 
Problem das ich während der Funktion ffls(); statt der UART Ausgabe eine 
Datei und dann den Namen der aktuellen Datei dort reinschreiben will ;)

hallo,

werd mir deinen code und den fehler bei fat16-ffls mal ansehen, 
allerdings leider erst sonntag. bin übers wochenende weg..

grüße daniel

hallo,
hab mir den code angesehen, läuft bei mir problemlos. schade das du kein 
image von der karte gemacht hast, mit der es nicht ging. so ist der 
fehler für mich nicht reproduzierbar.
zu deinem problem, was du möchtes ist eine datei suchen um dann etwas 
damit zu machen oder?

wenn ja:
die funktion ffopen gibt 0 zurück wenn die datei die du lesen/anhängen 
willst in dem aktuellen verzeichniss vorhanden ist. wenn 0 zurück kommt, 
ist die datei auch schon fürs lesen oder anhängen "vorbereitet", also 
mit ffread() / ffwrite() zugänglich. kommt 1 bei ffopen('w',dateiName") 
zurück ist die datei vorhanden und muss gelöscht werden vor dem 
schreiben.

wenn nein:
hab ich keine ahnung was du machen willst ;)
dann erkläre es mal...

grundsätzlich sollten die datei-operation funktionen in file-0.x.c nur 
extern genutzt werden, da so sicher gestellt ist, das alle flags und 
structs richtig geladen/gesetzt sind. das war nämlich das problem bei 
dem was du wolltest...
z.b. wenn man file.name benutzen will aber dann ffopen aufruft, läd 
ffopen was neues auf file.name, weil ffopen eben auch ein dir auf eine 
datei durchsucht, und alles mögiche auf file.name landet bevor man das 
hat was man will...

grüße daniel

genau gesagt möchte ich alle files eines ordner auslesen und statt dann 
die filenamen über usart auszugeben, würde ich gerne den filenamen in 
eine liste eintragen, die dann etwa so aussieht

"
DATEI1  MP3; Interpret1; Titel1
DATEI2  MP3; Interpret2; Titel2
DATEI3  MP3; Interpret3; Titel3
DATEI4  MP3; Interpret4; Titel4
"

das ganze wäre z.b. in einer txt datei eingetragen: Also soll er 
eigentlich jedes File in dieser Form in eine Liste eintragen (ID3 Tag 
Erkennung habe ich schon gemacht)

wenn ich mehrere Files offen haben könnte wäre das ja kein Problem, da 
aber die Funktion lsRowsOfClust() selbst auf die File/Fat Struktur 
zugreifft gibt es ein Problem solange ich nur eine Datei offen haben 
kann.
Was mir in diesem Zusammenhang aufgefallen ist: Du hast ja anfänglich 
gesagt du würdest kein Support für mehrere Files die offen sind 
anbieten, da damit möglichst wenig Ressourcen gebraucht werden, 
allerdings sieht es so aus als wäre in fat-0.x.c eine statische Variable

extern unsigned char   sector[512];

 vorhanden die immer 512bytes Platz wegnimmt, ob man nun eine Datei 
offen hat, oder nicht..

hallo,

wieso willst du so eine datei anlegen? ist doch doppelt, weil es diese 
struktur doch eigentlich schon in dem ordner gibt...
man könnte das ganze so erweitern, dass id3 tags ausgelesen werden und 
mit angezeit werden, anstatt z.b. die länge der datei.

ps: hab grade getestet, läuft auch problemlos auf atmegas die nur 1kB 
ram haben.

hallo,

nein kann man nicht und wird man auch erstmal nicht.

hm,

hab mir ehrlich gesagt noch nie gedanken darum gemacht eine formatier 
routine zu schreiben, wäre sicher nicht besonders schwer. gut, bei 
gelegenheit mach ich das mal :)

groß/kleinschreibung ist einfach nur nervig. ich schreibe außerdem sehr 
viel jeden tag, da bin ich froh wenn ich mal meine kleinen finger etwas 
schonen kann (die betätigen shift bei 10 finger tippen).

*(unsigned char*)vi++=*bytesOfSec++;

mit einem gecasteten void pointer byteweise auf 4 byte große variablen 
zu schreiben ist bis jetzt noch die eleganteste lösung meiner meinung 
nach...

güße daniel

hallo,

hier nochmal eine etwas verbesserte version.
bug in run_cmd behoben.
benchmark teil kann mit #define benchmark 0 oder 1 ein oder aus 
geschaltet werden.

grüße daniel

bug beim leere datei lesen beseitigt.

so das wäre es dann erstmal.

hallo,

die neuste version ist erweitert um:

ffmkdir - legt verzeichniss in aktuellem verzeichniss an.
ffrm    - kann jetzt auch ordner löschen. löscht rekursiv !

in der fat-0.3.h ist ein define :

#define smallFatSys  1

wird es auf

#define smallFatSys  0

gesetzt, dann passt der code in einen atmega8 , mit schreib und lese 
unterstüzung und kommando prompt !

falls jemand fehler findet, bitte melden !

bugfix in ffrm...

hallo,

ja danke. dicker bug in ffwrite und was blödes in ffopen.


ist geändert !

och als arbeit würde ich das nicht umbedingt bezeichnen ;) macht doch 
spass

Mir ist nun mein ForumPW wieder eingefallen, deswegen nicht mehr Timo, 
sondern nun LoLiPoPer.
Ich habe nun einfach noch mal die komplette Version 0.4.2 nach CV 
portiert.

Jetzt klappt es schon besser. Aber es läuft noch nicht ganz rund.
Jetzt steht in der Datei, die ich wie oben beschrieben anlege, der erste 
Teil (die ersten 512 Bytes) drin, dann ist eine Pause von 512 Byte(nur 
Leerzeichen)und ab hier gibt es noch kleine Fehler jeweils wenn die 
Vielfachen von 512Bytes erreicht werden.
Kleine Fehler in so fern, dass immer ein paar Zeichen verloren gehen.
Das ganze sieht in der TXT in etwa so aus:


<----512Byte----><----512Byte----><----512Byte----><----512Byte----><--- 
--...
"text text text ""               ""text text tex"    "text text t"
                         |                         |                |
                   große Lücke                kleine Lücke     kl. Lücke

Wenn du da noch mal schauen könntest, wäre das klasse..
Macht ja Spaß ;)

hallo,

eben erst zurück gekommen...

da ist wohl noch eine variable falsch gesetzt gewesen.
danke für deine mithlife und geduld. bin selbst die ganze zeit schon am 
bugs suchen, aber je mehr mitmachen umso besser wird es werden.

ist ein wenig umständlich hier nur den auszug zu posten, deshalb als 
anhang die geänderte file-0.3.c

geändert nur eine zeile in ffopen in dem teil:

   if(option=='a' && file_flag==0){

und zwar fehlte die angabe(nach zeile 94):

   cntSecOfClust=s+1;

die für ffwrite nötig ist, um zu wissen in welchem sektor des clusters 
man sich grade befindet. die berechnung ist da auch noch etwas 
umständlich, wie auch in ffseek...

Servus..

bei der Menge an Code ist es ja ganz klar, dass man mal ne Kleinigkeit 
übersieht. Alles klein Problem..

Die von mir beschriebene "große Lücke" ist nun weg. Die kleinen gibt es 
allerdings immer noch.
Ich hänge als Anhang mal die Textdatei an, damit du dir selbst n Bild 
machen kannst.
In der Datei werden immer Datensätze in dieser Form:
#;NUMMER;DATUM;UHRZEIT;MESSWERT (für Import in Excel)
aneinandergereit. An einigen Stellen fehlen eben einige Daten.
(Wenn du die Datei mit Excel öffnest ist das auch ganz gut zu erkennen.)

Was mir noch aufgefallen ist:
Wenn ich mit ffopen('w',"DATEINAMTXT"); eine Datei anlegen will, diese 
jedoch schon existiert, bekommen ich von ffopen nicht immer den 
Rückgabewert 1 geliefert. d.h. die Datei wird neu angelegt und befindet 
sich dann zwei mal auf der SD-Karte. Die Inhalte sind jeweils die 
gleichen und es geht auch nix verloren. Schön is das aber nicht. ;)
Ab und zu ist der Rückgabewert aber korrekterweise auch 0.

So, das sollte erst mal genug sein.. ;)

hallo,

woher kommen die daten die auf die karten sollen denn? sind die auf 
jeden fall korrekt? werde morgen nochmal exzessiv testen mit großen 
datenmengen und hin und her kopieren von dateien usw...

hattest du die karte neu formatiert, als du den neuen code verwendet 
hattest?
wenn nicht könnten so sachen mit ffopen('w',"DATEINAMTXT"); passieren. 
werde ich mir morgen aber auch nochmal genau anschauen.

güße daniel

hallo,

kann die bugs nicht bestätigen. habe mehrere dateien mit w erstellt, mit 
a sachen angehangen in verschiedenen größe (vielfachache von 512 usw). 
läuft immer alles ok. kommen deine daten über den uart?

poste doch mal die funktionsaufrufe wie du sie machst. vielleicht werd 
ich daraus schlauer.

als anhang nochmal das aktuellste programm

hmm.. wenns bei dir so läuft, kann es ja eigentlich nur an mir liegen.

Ich poste mal die Funktionsaufrufe, evtl. ist ja dort ein Schnitzer 
drin.
Ansonsten kann es ja immer noch sein, dass beim Portieren nach CV was 
falsch gelaufen ist.

Vorweg: Die SD-Karte ist eine ScanDisk 512MB.
        Formatiert habe ich diese mit WindowsXP Prof. als FAT und auch 
mal
        als FAT32. (Ich formatiere die Karte auch bei ca. jedem 2. 
Versuch
        neu.)
Hier jetzt die Aufrufe:

// External Interrupt 6 service routine                                    
// Interrupt wird ausgelöst, wenn entweder die SD-Karte rausgezogen oder 
// eingesteckt wird. Entsprechend wird SD_ONLINE = 0 gesetzt oder die 
// Initialisierung durchgeführt und SD_ONLINE = 1 gesetzt.
interrupt [EXT_INT6] void ext_int6_isr(void)
{  
  char temp;
  delay_ms(500);    //Warten, bis Karte richtig ein- / ausgesteckt
  if(((SD_Detect)==0)&&(SD_WriteProtect==0)){
        puts1(SDKartegefunden);
        
        puts1(SDInit);
        temp = mmc_init();              
        if(temp==0){
                puts1(OK);     
                puts1(FATInit);
                temp = fat_initfat();                  
                if(temp==0){
                        puts1(OK);
        
                        puts1(messdatatxterstellen);
                        temp = DV_MESSDATATXTerstellen();
                        if(temp==0)puts1(OK);
                        else puts1(Dateibereitsvorhanden); 
                        
                        SD_ONLINE = 1;
                        }    
                 else puts1(Fehler);
        }
        else puts1(Fehler);
  }      
  else {
    puts1(SDKartenichtgefunden);
    SD_ONLINE = 0;
    }
}

dazu die Funktion DV_MESSDATATXTerstellen();

char DV_MESSDATATXTerstellen(){
        char temp=0;                            
        temp = ffopen('w',messdatatxt);
        if(temp==1) return(1);                  //Datei existiert bereits             
        do{   
                ffwrite(messdatatext[temp]);
                temp++;
        }
        while(messdatatext[temp]!='\0');        
        ffclose();
        return(0);   
        }

Diese Funktion wird in der mainloop jede Sekunde aufgerufen:

char DV_MessungSpeichern(int Nummer){
        char temp;
        char TEMP[4]="   ";  
        unsigned long int Abstand; 
        unsigned char Abstand_ASCII[32];
        #asm("cli");
        
        itoa(Nummer,TEMP);
        
        temp = ffopen('a',messdatatxt);
        if(temp==1) return(1);                  //Datei nicht vorhanden
       
        ffwrite('#');                           //Zeilenführungszeichen 
        ffwrite(';');      
        
        ffwrite(TEMP[0]); 
        ffwrite(TEMP[1]); 
        ffwrite(TEMP[2]);
        ffwrite(';');     
        
        ffwrite(Tag_ASCII[0]);
        ffwrite(Tag_ASCII[1]);
        ffwrite('.');       
        ffwrite(Monat_ASCII[0]);
        ffwrite(Monat_ASCII[1]);
        ffwrite('.');         
        ffwrite(Jahr_ASCII[0]);
        ffwrite(Jahr_ASCII[1]);
        ffwrite(Jahr_ASCII[2]);
        ffwrite(Jahr_ASCII[3]);
        ffwrite(';');        
        
        ffwrite(Stunde_ASCII[0]);
        ffwrite(Stunde_ASCII[1]);
        ffwrite(':');  
        ffwrite(Minute_ASCII[0]);
        ffwrite(Minute_ASCII[1]);
        ffwrite(';');  
        ffwrite(';');      
        
        ffwrite('\n');
        ffwrite('\r');
        ffclose();  
        
        #asm("sei"); 
        MessungNr++;
        return(0);   
        }  

Die Variablen Sekunde_ASCII, usw. sind globale Variablen, die aus einem 
RTC-Chip stammen. Die Variablen gebe ich im mainloop jeweils zur 
Kontrolle per UART aus.(Da stimmen die Daten immer.)
messdatatxt ist ein globaler String:char* messdatatxt="MESSDATATXT";

Ich hab jetzt noch mal rumprobiert. Folgende Fehler treten auf:
- Ein Datenblock 512Byte fehlt ganz(kommt sehr selten vor).
- Einige Datensätze fehlen teilweise.
- MESSDATA.TXT wird mehrfach erstellt

Hoffentlich hab ich hier was falsch gemacht. Sonst wirds ungemütlich..

hallo,

also die karte sollte nur dann abgezogen werden, wenn ganz sicher keine 
schreib/anhäng operation gemacht wird. also besser einen pin mit 
schalter versehen und erst nachdem der schalter gedrückt wurden und 
sicher ist, dass die karte nichts mehr macht raus ziehen. oder irgnedwie 
anders sicher stellen, dass keine operation läuft während man den strom 
wegnimmt.

grundsätzlich sieht dein code ok aus. benutzt du die letzte version der 
lib?

habe mit:
 fat32 und 4 sektoren pro cluster
 fat16 und 1 sektor   pro cluster
 fat16 und 4 sektoren pro cluster,
getestet. hab über das programm dateien auf die karte geschrieben, 
angehangen, ausgelesen usw. alles ohne probleme.
kannst du evtl. noch fat und file *.c dateien posten, dann schau ich mir 
mal die änderungen dort an.

hast du ein delay in der main, um DV_MessungSpeichern aufzurufen, oder 
mit timer?

güße daniel

moin moin...

jipp, den Taster hab ich drin. Bevor ich die Karte abziehe setze ich 
über einen Taster SD_ONLINE = 0; und DV_MessungSpeichern(); kann nur bei 
SD_ONLINE ==1; aufgerufen werden.

 if(SD_ONLINE){ 
        temp = DV_MessungSpeichern(MessungNr);
        }

Ich hab jetzt mal etwas umprogrammiert. Und zwar beim EXTINT6 mit 
einigem Erfolg:

// SD-Card initialisation // FAT-File System initialisation
if(((SD_Detect)==0)&&(SD_WriteProtect==0)){
        puts1(SDKartegefunden);       
        puts1(SDInit);
        temp = mmc_init();              
        if(temp==0){
                puts1(OK);
        
                puts1(FATInit);
                temp = fat_initfat();                  
                if(temp==0){
                        puts1(OK);
                        puts1(messdatatxterstellen);
                        temp = ffopen('r',messdatatxt);
                        ffclose();
                        if(temp==1){
                          DV_MESSDATATXTerstellen();
                          puts1(OK);
                          SD_ONLINE = 1;  
                          }           
                        else puts1(Dateibereitsvorhanden); 
                        }    
                 else puts1(Fehler);
                 }
        else puts1(Fehler);
        }
else puts1(SDKartenichtgefunden);

sprich: Ich mache die Abfrage, ob eine Datei schon vorhanden ist, indem 
ich versuche sie zu lesen.
Was merkwürdig ist: Auch wenn die Datei vorhanden ist, liefert 
ffopen('r',..); anscheinend immer 1 zurück.
Damit wird DV_MESSDATATXTerstellen(); jedesmal ausgeführt. ABER:
Es bleibt bei EINER Datei!! (verstehe im mom nicht wirklich warum, aber 
das Ergebnis ist das Erwünschte!)
Das Problem reduziert somit auf einen einzigen Fehler:
Wenn ich weniger als 1024Bytes in eine TXT-Datei schreibe klappt alles 
wunderbar. SChreibe ich jedoch mehr als 1024Byte in die Datei fehlen die 
2. 512Bytes (bzw sind diese mit Nullen(Leerzeichen) aufgefüllt). Danach 
ist wieder alles OK.

DIe Lib ist die 0.4.2!

Ahja, und DV_MessungSpeichern(); wird nach einem delay aufgerufen.
(Das auch nur zur Probe. Später soll das dann per Taster laufen.)

Im Anhang sind noch die File.c & die FAT.c. Allerdings in einer 
TXT-Datei, da ich den Code erst mal einfach in die MAIN.c geknallt habe.

Hoffe, du musst nich zu viel Aufwand betreiben..
ALso schon mal Danke..

hallo,

ich kanns nicht sehen, aber du sorgst doch dafür, dass bei programmstart 
file_flag mit 0 initialisiert wird(ein ffclose macht das auch..)? es 
gibt nämlich nur 3 möglichkeiten warum ffopen('r',datname); 1 zurück 
gibt.

1. wenn file_flag nicht 0 ist.
2. wenn die datei nicht im aktuellen verzeichniss gefunden wurde.
3. wenn das laden des 1. sektors der datei fehl schlägt.

ich habe in der option bei ffopen im write teil etwas geändert, 
erscheint mir sicherer, änder das auch noch grad.

if(option=='w' && file_flag==0){  
   if(1==fat_loadFileDataFromDir(name)){
   ...
   ...
   ...
   return(0);
   }
}

warum bei daten größer 1024 dieser bug bei dir auftritt ist mir grad 
noch ein rätsel, schau ich mir aber noch genau an.

nach dem delay hatte ich nur gefragt, um sicher sein zu können, dass da 
kein interrupt irgendwo reinpfuscht :)

für mich wäre noch interessant, wieviele sektoren pro cluster hat die 
karte mit fat32 formatiert? wenn du das so grad nicht nachsehen kannst, 
mach einfach mal sowas nach der fat init:

char tmp[12];
ultoa(fat.secPerClust,tmp,10);
uputs("secPerClust: ");
uputs(tmp);

ach was mir grad noch einfällt, wie ist die karte an den avr 
angeschlossen?
da können auch mal ein paar bytes verloren gehen wenn die kabel zu lang 
oder so. bin selber jetzt auch auf einen 74hc4050 umgestiegen um die 
karte zuverlässiger anzuschließen (kostet 40 cent).

grüße daniel

Mal wieder Hallo!;)

Das file_flag hatte ich nicht expliziet mit 0 initialisiert. Ich dachte, 
sowas läuft über die Initialisierung von fat_initfat();
Probiert hab ich das jetzt aber mal (auch mit ffclose(); beim 
Programmstart), bringt aber keine Änderung.

Den Teil in ffopen hab ich aktualisiert.

Am Anschluss der Karte kann es eigentlich nicht liegen, da ich das 
"Savvy128"-Board von chip45.com verwende.

Interrupt verwende ich schon, allerdings schalte ich die bei jedem 
Zugriff auf die Karte mit #asm('cli');  aus.
(Ext. Interrupt vom RTC-Chip)

Deinen Code zur Sektorenbestimmung liefert bei FAT32 den Wert "8" und 
bei FAT den Wert "16".

hmm.. mit dem Umweg über ffopen('r',..); zur Dateienerstellung kann ich 
leben, nur das Löschen der Daten wenn ich mehr als 1024 Byte schreibe 
stört schon.

also,

nach nochmaligem debugen kann ich einen fehler da aussließen.
wichtig ist einfach nur die reihenfolge:

1. ffopen
2. ffwrite/ffread
3. ffclose

dann kann da nix schief gehen. irgendwo fehlt warscheinlich eine 
kleinigkteit in deinem code, irgend eine änderung die ich gemacht habe, 
die du aber nicht gemacht hast. probier mal einfach so in einem test 
programm, die funktionalität der fat-lib (neuste version mmc-0.4.3.zip). 
so kommst du vielleicht auf den fehler.
hab auch nicht deinen ganzen code um mir das mal anzusehen.
z.b. hast du

unsigned char ffwrite(unsigned char c){
   unsigned long int clusterOld;
   clusterOld=currentCluster;
   ...
   ...

das so geändert. da wird beim schreiben von einem byte immer direkt auch 
eine unnötige long int operation gemacht (4 byte operation), das ist 
ungünstig.

die von dir beschriebene lücke klingt für mich so, als wenn da ffclose 
irgendwo falsch aufgerufen wird.

grüße daniel

hallo,

als anhang mal eine ganz einfache nutzung der lib.
erstellt eine datei, schreibt daten rein und hängt daten an.
erstellt einen ordner und erstellt die datei nochmal darin.

grüße daniel

Hallo,
saubere Arbeit!
Vielleicht wäre es bald übersichtlicher einen wiki Artikel zu schreiben, 
wo auch Minimal und Optimalschaltplan drin sind und immer die neuste 
Version drin steht. Eine SD Lib für Codevision wäre super, poste also 
bitte mal den Code sobald er läuft.
Viel Spaß noch

Kai

hallo,

@ Lolipop Er
wie siehts denn jetzt aus bei dir? läuft es oder nicht?
wenn es dir nichts ausmacht, poste doch auch mal so eine mini version 
mit den änderungen für codevision. falls das noch nicht läuft, können ja 
vielleicht auch andere mal mitschauen.

@  Kai Franke
zum thema wiki, hab ich noch nie gemacht. interesse scheint auch nicht 
allzu groß zu sein. übersichtilicher wäre es allerdings schon ;)

grüße daniel

hey Daniel,

jetzt rennt er!! ;)
Ich habe noch mal die Version 0.4.3 neu portiert. Anscheinend war die 
Kleinigkeit, die Du da geändert hast ausschlaggebend.

Bevor ich das online stelle, möchte ich noch mal ein bisle mit den 
Ordneroperationen rumspielen um zu sehen ob das auch fehlerfrei 
funktioniert.
Und alles n bisle ordentlich machen. (also *.c - & *.h files erstellen.)

Müsste ich bis heut Abend hinbekommen.

bis dann..

hallo,

äh ja, ordner operationen da gibt es noch was... tritt selten auf, aber 
hier der bugfix, sorry.

muss man denn viel ändern zu codevision? ist doch auch ein standart c 
compiler, oder?

Da ich bis zum 15. meinen Artikel für den Artikelwettbewerb fertig haben 
muss, werde ich wohl bis dahin auch wissen wie man einen wiki Artikel 
erstellt und biete an auch für diesen Artikel einen zu erstellen.
Ich sage dann nochmal Bescheid, dann könnt ihr mir ja beide eure 
Errungenschaften schicken und ich vereine sie im wiki.
Editieren und hinzufügen wird ja jeder hinbekommen :P

Gruß
Kai

Soo..
denn stelle ich mal den Code online.

So viel ist nicht zu ändern für CV. Hauptsächlich die 
Variablendeklarationen. Ist aber schon immer etwas Aufwand.
Aber nun hab ichs noch mal mit der V0.4.4 gemacht. (Allerdings hab ich 
die Funktionen nicht noch mal sauber formatiert.)
Wenn da noch irgendwo was zukommt, änder ichs auch gern noch mal.(Wäre 
natürlich schöner, wenn ich wüßte in welchem Teil was geändert wurde, 
dann muss ich nicht alles neu machen.)

Der Code wurde auch nicht in irgendeiner Weise extrem optimiert. Wichtig 
war mir in erster Linie, dass alles einwandfrei funktioniert und das 
ist, soweit ich weiß, auch gegeben.

@Daniel:
Wenn Fehler gemeldet werden, wäre es klasse, wenn du da mit nachschauen 
könntest und ich übernehme die Änderungen für CV.

hallo,

@ Kai Franke

fänd ich super, wenn du daraus einen wiki artikel machen würdest. ich 
schreibe gerne ein paar allgemeine sachen zur fat oder auch speziell zu 
dem code oder so...

@ Lolipop Er

werde die änderungen die ich jetzt ab version 0.4.4 mache in den dateien 
dokumentieren. angepeilt ist so ab version 0.5.x dass die statische 
variable sector[512] dynamisch übergeben wird. so könnte man, wenn das 
programm grade nicht den fat teil nutzt, 512 bytes ram sparen.
werde mir später mal deine umsetzung ansehen.

grüße und danke für die aktive teilnahme

daniel

hallo,
seltsam, also die initialisierung klappt?
was benutzt du für eine karte und wie ist die karte angeschlossen?
wie lautet der genaue aufruf von ffopen, also mit welchen parametern 
usw.

du benutzt die aktuelle version (mmc-0.4.4.zip)?

grüße daniel

hm,
ffopen mit option 'w' gibt auch 1 zurück wenn die datei schon vorhanden 
ist.
versuch mal ein

ffrm("DELME   TXT");

vor dem öffnen mit ffopen. das würde die datei löschen für den fall das 
sie da ist.
sieht sonst richtig aus...

ach was ich grad sehe,
der code von dir ist teilweise aus einem blöden beispiel...
der string str[22] müsste 23 zeichen lang sein, weil
"das soll auf die karte" sind 22 zeichen.

hm

das ist mal komisch. ist die karte vielleicht partitioniert? dann muss 
man das umstellen auf:

#define superfloppy  0

in der fat-0.4.h

standartmäßig ist das so eingestellt, das die karte unpartitioniert ist.

würde erklären warum der pc keine daten sieht, aber die initialisierung 
der karte am mc durchläuft und auch geschrieben werden kann. bei 
fat_initfat() wird nicht auf sinnigkeit der ausgelesenen daten geprüft. 
ergo landen die daten an merkwürdigen stellen der karte, weil die 
bereiche der fat falsch ausgelesen werden...

hallo,

schön das es klappt. muss mir mal überlegen wie ich erkennen kann ob im 
sektor 0 ein mbr steht oder der erste sektor der fat, dann könnte man 
das automatisieren...

grüße daniel

ein neues update.
die änderungen sind in den *.c dateien dokumentiert.
änderungen nur in der fat-0.4.c und file-0.4.c.

grüße daniel

äh hier auch noch die dateien...

hallo,

bei "smallFileSys 0" fällt das löschen von dateien und das rekursive 
löschen von ordnern weg, das anlegen von ordnern und das wechseln in 
einen höheren ordner auch ("cd.." quasi). der rest ist dabei.

einen schalter um nur schreib bzw lese zugriffe zu machen hatte ich auch 
schon vor. werd ich auch die tage noch machen. das problem dabei ist, 
dass einige funktionen die zum lesen gebraucht werden auch zum schreiben 
gebraucht werden, ich kann grad nicht so abschätzen wieviel kleiner das 
wird. nur lesen wird man wohl auf weniger als 3 kByte bekommen.

bei mir gab -O2 den kleinsten code


gruß daniel

also,

ich bekomme eine nur lesen version auf 3618 bytes code gedrückt, ohne 
weitere optimierungen und ohne tolle ff-funktionen wie ffseek usw.
eine nur schreiben variante wird aber nicht viel kleiner werden können 
als 5990 bytes an code. das liegt daran, dass man ja auf jeden fall auch 
das dateisystem lesen muss um schreiben zu können...
will man ein verzeichniss wechseln können, muss der ganze lese kram mit 
rein...
möchte man nur einen daten logger bauen, so wird wohl ein atmega88 oder 
8 mit 8 kBytes flash reichen, will man da mehr, braucht mann mehr flash.

grüße daniel

hallo,

sorry hat etwas gedauert...
die änderungen sind nicht wild...

avr-size main_.hex
mit den schaltern (nur schreiben ohne große datei funktionen) :

#define smallFileSys 0  
#define write 0   

gibt nach dem kompilieren 6538 bytes an code an. sind doch 500 mehr, 
weil ich übersehen hatte das man beim schreiben auf jeden fall auch noch 
ffseek braucht.

mit den schaltern (komplette unterstützung):

#define smallFileSys 1
#define write 0   

wird der code 8228 bytes groß.

mit den schaltern (minimal system, nur lesend):

#define smallFileSys 1
#define write 1   

wird der code 3618 bytes groß.


güße daniel

hallo,

-1 nein das ist alles andere als normal. es sei denn man möchte eine 
datei in einem ordner anlegen in dem es schon sehr sehr viele 
dateien/ordner gibt.

-2 poste doch mal eine funktionsaufrufe damit ich mir ein bild davon 
machen kann woran es liegt.

wie sind die karten formatiert, also mit fat32 oder fat16? mit welchem 
betriebssystem sind die karten formatiert worden? hast du sie vor der 
benutzung der lib neu formatiert?

klingt ein bischen so als würde fat_loadFileDataFromDir irgendwie ne 
macke haben, weil alle drei optionen/funktionen diese funktion nutzen, 
also ffopen (w/a) und ffclose auch, wenn mit ffopen(a) geöffnet war...
schau ich mir mal genauer an...

hm,

die header dateien sind relativ egal denke ich.

es kann sein das wegen der partition irgendwo ein bug ist. versuch mal 
die karte unpartitioniert zu benutzen, dass sollte auf jeden fall 
problemlos funktionieren.

ich komme erst später heute abend zum testen...
ich gehe mal davon aus das nur die header dateien geändert wurden, falls 
nicht, müsste ich mal den ganzen code sehen.

güße daniel

hallo,

es gab keine bugs in dem partitions bereich, hätte mich sonst vorher mal 
gemeldet.

hier trozdem mal eine neue version, ist schneller geworden, aber auch 
etwas gefährlicher ;)

es ist jetzt umbedingt erforderlich zu prüfen ob richtig geöffnet wurde 
bevor man schreibt !
ein beispiel:

// neu erstellen wenn nicht vorhanden und reinscheiben
if(0==ffopen('w',datei)){      // prüfen ob öffnen erfolgreich
   for(z=0;z<60000;z++){  
      ffwrite('a');    
      }  
   ffclose();
   }

nur wenn ffopen null zurück gibt wird ffwrite aufgerufen. ffwrite prüft 
nicht mehr ob öffnen erfolgreich war. zudem ist ffwrite und ffread 
inline geworden.
code ist allgemein kleiner geworden durch vielfache optimierungen !

durchschnittswerte mit einem atmega168 @ 16 mhz:

165 kByte lesend
146 kByte schreibend

...

hier mal noch der erste wiki versuch...

http://www.mikrocontroller.net/articles/FAT32

werde da noch weiter daran arbeiten. jeder der zu fat etwas beitragen 
kann/möchte ist eingeladen dort mitzuarbeiten...

grüße daniel

hallo,

ja hm das avr-studio...
hab da letztens auch mal die dateien kompilieren wollen, ging aber 
nicht. irgendwie löst das die c abhänigkeiten nicht alleine?!?. am 
einfachsten ist es wenn du das makefile das bei meiner lib babei ist 
benutzt. beim avr-studio kann man in den projekt eigenschaften ein 
externes makefile angeben. dann gehts. außerdem ist dringend davon 
abzuraten eine ältere version als 0.4.5 zu nutzen (besser 4.5.6), da 
doch noch einige fehler in den vorherigen versionen waren.
um ein lcd zu nutzen, könntest du einfach die lcd routinen mit 
übernehmen...

güße daniel

also über das makefile oder wie?

bist du Holger Klabunde?

hallo,

hab grad kein windows da um avr-studio zu starten. aber ich meine mich 
zu erinnern, dass ein projekt und die haupt c datei gleich heißen 
müssen. also solltest du ein projekt namens main_ erstellen und da dann 
alle dateien einfügen...

gruß daniel

hab jetzt mal die header dateien so umgebaut wie die portierbarkeit wohl 
am größten ist.
leider zu lasten der ausführungsgeschwindigkeit. alleine durch die 
header dateien gehen 20KBytes pro sekunde lesend 
verloren...seltsamerweise wird der code kleiner aber auch langsamer...

@ Alex
probier mal die neue version, damit sollte es besser klappen.
ich denke es liegt nicht am code der 0.4.6 sondern am einbinden im 
avr-studio, daher könnte es mit der 0.4.7 einfacher sein.

grüße daniel

lol moment bei windows wird das warscheinlich eher

c:\WinAVR\bin\avr-gcc.exe heißen...

mit optimierung s wird der code jetzt wieder kleiner als mit 2 und der 
geschwindigkeitsverlust geht auf 10KBytes /sec zurück. also von 165 auf 
155KB damit kann ich leben (atmega 168 @ 16mhz).

neue version

kleine änderungen.
mit windows und linux makefiles usw..

Moin Daniel,

wollte mich heute auch mal näher mit deinem SD-Code beschäftigen, 
nachdem meine Platine ansonsten funktioniert. Die Funktionsweise sieht 
verständlich aus.

Was mich momentan am Einsatz hindert ist, dass SPI, Usart wie auch die 
Command-Shell fest mit dem eigentlichen Code verbunden ist. Da ich 
hierfür bereits eigene Bibliotheken habe.... wie kann ich diese auf 
Dauer am besten einbinden und zwar so, dass der Wartungsaufwand bei 
einer Codeaktualisierung deinerseits nicht zu umständlich wird?

Oder hast du schon einmal überlegt, die ganzen relevanten #defines in 
eine Config.h auszulagern. Hierin könnten z. B. Methodennamen für Usart 
und SPI definiert sein oder auch, ob file.h->methode() auf den Usart 
ausgeben soll.... Und diese Datei wäre dann problemlos anpassbar durch 
einen anderen Anwender.

Anders gefragt - wenn ich dir einen entsprechenden Patch schicke würde, 
hättest du Interesse?

cu, Michael

Ich nochmal.... anbei als zip eine kleine Abwandlung deiner Lib mit 
einem globalem Config-Header-File. Es kompiliert; ausprobiert habe ich 
es aber nicht.

Zur Idee: In mmc_defs.h werden für uart, spi und spi hardware die 
entsprechenden Methodennamen als #define angegeben. Beispiel Uart:

#include "uart.h"
#define MMC_UART_INIT      uinit
#define MMC_UART_PUTC      uputc
#define MMC_UART_PUTS      uputs
#define MMC_UART_GETC      ugetc
#define MMC_UART_GETS      ugets

Möchte ich einen anderen Uart-Code verwenden, so include ich die 
entsprechende Header-Datei und passe die Methodennamen an.
- ugets wird z. Zt. nicht verwendet.
- Die SPI Methoden sollte man nochmal überdenken... da wollte ich dein 
Feedback abwarten bevor ich deinen Code vollständig verstehen will

Somit kann ich flexibel unterschiedliche Basisfunktionen für die 
Peripherieansteuerung verwenden (buffered, unbuffered usart; hardware 
spi, software spi; evtl. debug Lösungen) und bin deutlich flexibler, was 
die gesamte Konfigurierbarkeit anbetrifft. Die restlichen Code-Dateieen 
enthalten jetzt nur noch die SD-Card-Logik allein.

Was hälst du davon?

Michael

hallo Michael,

gute idee das so zu ändern, dass man unterschiedliche "unterbauten" 
nehmen kann, würde es auch einfacher machen das ganze auf andere 
controller zu portieren.
eine globale "hardware" header datei zu machen, wo die funktionen vom 
spi und die funktionen des uart, also der hardware anbindung der karte 
und der ausgabe, definiert werden ist eine gute lösung. die von dir 
beschriebenen vorteile sind es wert.

leider komme ich vor freitag wohl kaum zur umsetzung, weil ich umziehe 
und lernen mich voll in beschlag nimmt.

bis spätestens sonntag sollte es aber ohne probleme drin sein, wie im 
einzelnen, werde ich mir noch überlegen. weitere ideen sind sehr 
willkommen !

grüße daniel

Moin Daniel,
Das klingt ja sehr schön :-) Wenn du Zeit hast, dann schau dir meine 
Abwandlung mal an... vielleicht sind ja ein paar brauchbare Ideen drin.

Eine "globale" Hardware-header-Datei würde ich zuerst mal auf die 
mmc-lib beschränken. Warum? Viele dürften für die Ansteuerung der 
peripherie etc. bereits eigene Code-Sammlungen haben. Die mmc-lib müsste 
dann nur noch an diese Libs angedockt werden.

Die SPI Ports und Pins könnte man auch nochmal in eine weitere 
Config-Datei auslagern. So habe ich es jedenfalls bei mir gemacht, siehe 
Attachement SpiDefs.h

Zweite Idee: Ein Debug-Switch. Ist dieser gesetzt, so wird an eine 
ebenfalls frei definierbare Debug-Funktion die aktuelle Aktion (open 
file, read directory etc.) gesendet. Sowas kann man schön so 
programmieren:

#define MMC_DEBUG 0

#if defined(MMC_DEBUG)
  logDebug("bla");
#endif

Anyway, denn erstmal viel Erfolg beim Lernen und Umziehen....

Michael

Moin!

Wieso sollte dies ein Problem sein?

In der MMC-Config kannst du imho frei definieren, welchen Pin du als 
SS-Pin verwenden willst. Ob dies nun der "offizielle" SS-Pin des AVRs 
oder ein anderer Pin ist spielt hierbei keine Rolle. Somit kannst du 
auch problemlos mehere SPI-Chips oder -Geräte an den AVR anschließen 
solange du die gleiche Ansteuerungslogik (send_byte etc.) verwendest.

Aufwändiger wird es allerdings, wenn du unterschiedliche 
Busgeschwindigkeiten fahren willst. Da hast du recht.

Michael

hallo,
leider hab ich doch extrem weniger zeit als ich dachte.
bugs würden geändert werden, aber mehr ist momentan nicht drin, sorry.
nächste woche hab ich wohl etwas mehr zeit, hoffe ich...

grüße daniel

Daniel,

hast du inzwischen ein bisschen Zeit gefunden, die Debug- und sonstigen 
Änderungen einzuarbeiten? Dann könnte ich meine selbstgestrickten Dinge 
verwerfen und zurück zu deinem Code wechseln :-)

Michael

hallo,
bin momentan bis oben hin zu mit arbeit...

ich hab auch die karten meist selber nur mit linux gedebugt,
da hatte ich mir auch eine kleine mmc.c und mmc.h geschrieben, der rest 
code ist platformunabhänig...
das ist die bequemste art den code zu testen.
zudem kann man mit programmen wie WinHex auch images von datenträger 
machen und so kann man sogar ganz ohne mmc karten code debugen und 
testen.
einfach immer eine mmc.c und mmc.h an die hardwaremäßige plattform 
anpassen, schon ist die lib portiert (sofern standart c darauf läuft).
daher tendiere ich momentan dazu die debug geschichte erst in den 
semesterferien mal anzusehen (wie gesagt, debug mit linux ich wesentlich 
komfortabler).
den rest, also die uart und die mmc/spi geschichte so umzubauen, dass 
andere bibliotheken genutzt werden können mach ich über weihnachten, als 
kleines present ;)
spass beiseite, da werd ich wohl endlich ein wenig zeit haben mich 
meinem hobby zu widmen...

grüße daniel

Hi,
ich versuche gerade die Dateien aus mmc-0.4.8.zip unter Linux zu 
kompilieren. Das geht auch Problemlos, nur wenn ich den Schalter write 
auf 1 (read only) setze bekomme ich folgende Fehlermeldungen:

~/sd_test/main_.c:50: undefined reference to `ffmkdir'
~/sd_test/main_.c:53: undefined reference to `ffmkdir'
~/sd_test/main_.c:68: undefined reference to `ffwrite'
command.o: In function `run_cmd':
~/sd_test/command.c:94: undefined reference to `ffrm'
~/sd_test/command.c:101: undefined reference to `ffmkdir'
~/sd_test/command.c:149: undefined reference to `ffwrite'
make: *** [main_.elf] Fehler 1

Ist das ein Bug oder habe ich etwas übersehen.
Bei "read only" werden diese Funktionen natürlich nicht gebraucht, aber 
ich dachte der write Schalter berücksichtigt diese Option.

Danke
Andi

hallo,

besser spät als nie ^^

also, in der main_.c wird auf die schreib funktionen zugegriffen, 
genauso wie in der command.c . den schalter auf nur lesend setzen 
funktioniert nicht, wenn man dann doch auf die schreib funktionen 
zugreift.
in der bibliothek selber stimmt das soweit alles. wenn du nur lesen 
möchtest, musst du dir eine main schreiben und nur auf die lesen 
funktionen zugreifen...

grüße daniel

Hallo,
also du könntest z.B. aus der fat.c direkt die Funktion:

unsigned char fat_loadSector(unsigned long int sec)

aufrufen. Als Parameter bekommt die Funktion den zu ladenden Sektor 
übergeben. Danach ist der Sektor auf sector[].
Setzt allerdings Voraus, dass du den Sektor kennst.
Wenn du damit BMP's lesen möchtest, muss du ja auch die folge Sektoren 
kennen. Deshalb ist die ffread etwas umständlicher. Im Regelfall, gibt 
es aber ja aber nur einen Index der erhöht wird und eine Abfrage... erst 
wenn man 512 Bytes gelesen hat wird es etwas umständlicher, wegen dem 
Problem der folge Sektoren.

Grüße Daniel

Also Prinzipiell schon,
aber es kann mehrere Sektoren in einem Cluster geben, diese Cluster 
können auch nicht aufeinanderfolgen. Deshalb muss man zwischendurch in 
der Fat nach dem folge Cluster suchen, diesen auf Sektoren umrechnen und 
dann weiter lesen...
Wenn Du das alles beachtest, bist Du genau bei dem was ffread macht.

Das Prinzip wie Fat funktioniert habe ich versucht im Wiki Artikel 
FAT32 zu erklären.

PS: Ist Dir ffread nicht schnell genug? Wieso willst Du da was selber 
machen?

Grüße Daniel

Hi Martin,
das mit der 1 Sekunde ist seltsam wenn du mit 16 Mhz @ Avr arbeitest,
weil mit Deiner Angabe komm ich auf 371712 Bit, ist ja 46464 Byte/Bild, 
da sollte wesentlich mehr drin sein, oder hab ich mich verrechnet?

Zu dem Windows, welches benutzt Du? Vista?
Ich bin da nicht ganz Spezifikations-konform, weil normalerweise müsste 
man die Uhrzeit der Zugriffszeiten (erstellen/lesen...) richtig 
eintragen. Der Einfachheit halber schreib ich Nullen rein...
Hatte beim Testen aber dieses Problem auch nie.
Würde Vista ähnlich sehen, beim Datum 00-00-0000 nicht klar zukommen ^^

Güße Daniel

Hallo,
nur um mal abzuklopfen,
Du hast den Code nicht geändert oder so und Du achtest darauf, dass 
ffclose() aufgerufen wurde bevor du den Strom von der Karte nimmst, bzw. 
diese aus der Halterung ziehst (beim schreiben, beim lesen egal).

Mich würde dann auch der Aufruf und so interessieren, um abschätzen zu 
können wo da vielleicht der Fehler liegt.
Hab den Code so in der 0.4.8 Version selber im Gebrauch und mit Datei 
Größen noch nie Probleme gehabt.

Grüße Daniel

Hallo,
also auch beim Versuch die Karten zu Formatieren gibt es 
Fehlermeldungen?

Generell ist das sehr seltsam. Eigentlich geht Schreibschutz über 
Software nur mit einem bestimmten Kommando an die Karte, was aber auch 
nicht jede Karte unterstützt...

Einen Versuch die Datei mit ffrm() zu löschen ist es auf jeden Fall 
wert. Schlimmstenfalls bleibt ein bisschen Datenmüll in der Fat über. 
Sollte aber mit einem Scandisk Tool zu beheben sein.

Ich vermute, dass im Dateieintrag der Datei irgendwas steht was keinen 
Sinn macht. Hast Du einen Hex-Editor mit dem Du Dir die Rohdaten auf der 
Karte ansehen kannst? Davon ein Screenshot wäre super :)

Um soetwas zu verhindern, könnte man einen Taster anschließen, der einen 
Interrupt auslöst und ffclose() aufruft.

Hi,
also das mit dem Sprung ins Nirvana versteh ich nicht. Wenn Du sagen wir 
mal konstant Daten wegspeicherst, und ein ffclose wird aufgerufen, wird 
halt nur die Datei ordentlich geschlossen, also die aktuelle Größe usw. 
geschrieben. Macht jedes Betriebssystem ähnlich...
Also Daten Direkt schreiben und den Fat und Datenbereich zum Schluss 
aktualisieren. Deshalb kann man bei Usb-Sticks die einfach so 
herausgezogen wurden (beim schreiben) die Daten meist recovern.

Da Du keinen Code gepostet hast, kann ich nicht genau sagen wo der 
Fehler eigentlich liegen kann... Rechne Dir das mal durch, wie oft man 
eine Zelle beschreiben kann und wie oft du Tatsächlich schreibst.

Interessant wäre für mich der Sektor des Ordners in dem der Dateieintrag 
steht.

Die einzige Möglichkeit eine Karte mit der Lib zu zerstören wird zu oft 
schreiben auf die Karte sein, dass ist definitiv sicher. Wäre aber auch 
mit einem großen Betriebssystem nicht anders !

Wenn Du mit Linux und mkfs keinen Erfolg beim Formatieren der Karten 
hast ist da was ganz anderes im argen.
Aber interessehalber, schick mir mal eine. Dann schau ich da nach. Das 
glaub ich nämlich irgendwie nicht, formatieren mit Linux und dann sind 
da noch Daten so lesbar?!?

Güße Daniel

Also ich nehm auch immer winhex. Musste halt nen gesamt Screenshot 
machen...

Was hat der Prozessor mit der mmc/sd karte zu tun? Die ganze Geschichte 
kommuniziert ja über SPI, also AVR <-> mmc/sd Karte. Da hat keiner 
direkten Zugriff auf Stack oder so des anderen..

Schick mir ne Mail an zerrome aT gmail PunKt com, dann schick ich Dir 
meine Adresse.

Meinst du mit Daten gesehen, dass Du die Daten mit dem Hex-Editor 
gesehen hast? Wäre klar, weil Formatieren nur den Fat Bereich ändert, 
sonst müsste ja immer die Ganze Karte platt gemacht werden.

Grüße Daniel

Hallo,

jetzt versteh ich glaube ich endlich was Du mit dem Nirvana meinst...
Klar, nach der ISR nochmal ins normale Programm zu springen macht in dem 
Fall keinen Sinn. Da wäre dann in der ISR ein exit() oder so angebracht.

Wenn Du einen Screenshot vom gesamten Bildschirm machst wenn Winhex 
offen ist geht nichts in die Zwischenablage? Versuchs mal mit dem tool 
Printkey...

Grüße Daniel

Hallo,
ich glaube ich würde das an Deiner Stelle so machen,

ein struct anlegen mit Spielername, Score usw.
Für sagen wir, die Top 10.
Jetzt aus einer Datei die Daten auslesen und ins struct schreiben.
Wenn jetzt ein Spiel vorbei ist, einfach den Score überprüfen und wenn 
nötig einen aus den Top 10 rauswerfen und den aktuellen Spieler ins 
struct schreiben.
Zuletzt noch das aktualisierte struct wieder in die Datei schreiben.

Das Problem ist ja, dass man lese und schreib Vorgänge trennen muss, 
weil nur eine Datei zum schreiben oder lesen geöffnet werden kann. Wäre 
mit dem oben beschriebenen Beispiel kein Problem. Denkbar wären auch 
noch andere Möglichkeiten, solange man lesen und schreiben trennt...

Werde mir da mal was überlegen, weil es ja schon schick wäre, eine Datei 
zu öffnen und dann lesen und schreiben zu können... muss man halt 
bisschen aufpassen was man macht ^^
Das Problem ist ja nicht das überschreiben von alten Daten (da ändert 
sich ja nix am Datei Eintrag in FAT und Ordner), sondern wenn über das 
alte Datei Ende hinweg neu geschrieben wird. Da muss dann ne menge mehr 
gemacht werden...

Grüße Daniel

Hallo,
deine SD Karten sind angekommen. Die Controller darauf sind OK. Aber es 
sind massenhaft kaputte Sektoren. Zu viele. Ich vermute ja bei so billig 
Herstellern, dass die keine Algorithmen zum mappen von logischen auf 
physikalische Sektoren einbauen...
mkdosfs wirft in der Standart ausgabe (Konsole) keine Fehler, aber dmesg 
liefert die ganzen Fehler...
Die eine Karte kann man sogar an manchen stellen noch beschreiben, die 
andere weigert sich einfach.
Ist eindeutig kaputter Flash, weil die Controller sich noch 
ordnungsgemäß verhalten.

Bin gerade an einer neuen Version der Lib... die 0.5,
da wird es große Änderungen geben. Es wird dann auch möglich sein zu 
lesen und schreiben auf einer geöffneten Datei. Muss aber viel umbauen 
dafür...



Grüße Daniel

Hallo Martin,

wenn du magst kann ich die Karten auch zurück schicken, dann kannste Dir 
die vielleicht auch nochmal ansehen.
Mit Massenhaft kaputten Sektoren meinte ich, dass so bei 10 gemeckert 
wurde. Das ist schon viel, weil eine gute Karte normalerweise noch 
Reserven hat, die benutzt werden wenn wenn defekte entdeckt werden.
Es ist auf jeden Fall Vorsicht geboten bei Flash Speicher..

Die Lib ist jetzt soweit fertig. Bin am testen und Debuggen.
Es entfällt der Parameter beim öffnen einer Datei. Also 'w','r', und 'a' 
sind nun überflüssig.
Es wird entweder die vorhandene Datei geöffnet oder wenn nicht vorhanden 
eine erstellt. Diese kann man dann lesen und beschreiben.
Will man an eine Datei etwas anhängen, wird diese einfach geöffnet und 
mit ffseek(file.length) ans ende gespult. Dann einfach schreiben...
Dazu und zu anderen neuen Aspekten aber noch Code Beispiele.

Denke ich werde Sonntag die Version mmc-0.5 Posten können.

Grüße Daniel

Es gibt noch Probleme bei fragmentierten Fat-Tabellen. Wenn ich das in 
den Griff bekommen habe ists fertig  :)
Im Idealfall, wo die FAT unfragmentiert voliegt, kann man 256000 
Byte-Blöcke in einem Rutsch lesen. Sollte also auch alles schneller 
werden. Beim schreiben ähnlich...

Hallo,

also wenn ich teste, dann eh nur mit images von Karten, nie mit den 
Karten selber...
Wäre auch viel zu umständlich da immer neu zu Formatieren und Dateien 
drauf zu kopieren um auf einen definierten Zustand zu kommen. So is das 
ne Sache von 2 Sekunden...


Grüße Daniel


edit:

Man stelle sich vor, eine schleife läuft Amok und das über mehrere 
Sekunden/Minuten oder so -> defekte Karte...

Hallo,

also ich mache ein Image von einer Karte (z.B. mit winhex), also von 
allen Sektoren.
Dieses Image öffne ich in meinem c-Programm als Datei (c-Programm auf 
PC). Diese Datei hat ja die Struktur der Karte und kann somit genau so 
benutzt werden.
Jetzt braucht man nur noch eine angepasste mmc.c und schon kann man 
problemlos Testen, ohne Karten zu gefährden und bequem am PC.
Abschließende Tests mit realer Hardware kommen dann natürlich dazu, aber 
da geht es nicht mehr so darum ob der Code das macht was er soll...

Grüße Daniel

Sooo,
ist fertig.

Ist gut geworden, schneller und kleiner...
Viel Spaß damit.
Werde morgen oder so mal das Wiki mit bisschen Doku undso füttern.

Wer den Link noch nicht kennt:

http://www.mikrocontroller.net/articles/FAT32



Grüße Daniel

Hi,

ich bin blutiger Anfänger, zumindest was SD-Karten angeht.
Deswegen auch nen Anfängerfrage :)

Wie beschalte ich denn so eine SD-Karte? Kann mir mal jemand nen 
Schaltplan hochladen? Wär total nett!

Gruß
Matze

aller besten dank für die hilfee bei der beschaltung!

ich habe zwar keine ordner operationen vor, aber ich werde aufpassen :)

was den einstieg vielleicht für alle anfänger erleichern würde, wäre ein 
beispielprogramm, in dem die meisten / wichtigsten funktionen einmal 
durchlaufen werden (Datei erstellen und öffnen, daten hinein schreiben 
und anhängen, etc (natürlich auch für ordner)). ähnlich wie die 
libraries von fleury und seine testprogramme - muß aber nich soo 
ausführlich und allumspannend sein. ich denke, ein atmega8 hat jeder 
zuhause rumfliegen...

ich muß nämlich gestehen, daß die fülle von dateien und die auf den 
ersten blick recht kryptischen befehlsnamen einen echt abschrecken 
können :)

gruß,
matze

Das klingt doch gut. Ich muß nämlich für die Uni Messwerte auf eine 
SD-Karte bannen und deine Library ist goldwert. - aber einen kleinen 
Denkanstoß brauche ich wohl noch :)

Ich habe vielleicht auch gleich noch eine Anmerkung (bitte versteh mich 
nicht falsch, ich finde deine Arbeit klasse und ziehe den Hut!):
So wie ich das verstehe, kann die Funktion ffwrite nur ein einzelnes 
Zeichen auf die Karte schreiben. Für viele Anwendungen ist es aber 
häufig nötig gleich einen ganzen String zu schreiben. Man müßte also 
jeden "Buchstaben" einzeln anweisen.
Wäre es nicht pfiffiger einfach eine Funktion alla:

void ffwrites(const char *s )
{
    while (*s) 
      ffwrite(*s++);
}

zu schreiben bzw.in die file.c zu packen?!

gruß matze

Hallo zusammen,

danke das ihr mit testet.

Die angesprochene Funktion ffwrites ist aufgenommen.
Zudem ist in der fat.c noch eine Funktion fat_str hinzu gekommen, die 
sonst immer woanders untergebracht war.
Mit dieser Funktion kann man einen String von "test.txt" in "TEST 
TXT" wandeln, so muss ja schließlich alles auf die karte...

Anbei sind jetzt, wie ich denke einfache Beispiele zur Benutzung der 
Lib, für einen atmega8. Der is leider ein bisschen zu klein für den 
vollen Umfang der Lib (z.B. Ordner Rekursiv löschen und anlegen).

Der Bug in ffmkdir ist behoben. Keine weiteren Bugs bekannt...

Was mich noch stört, ist die Tatsache, dass mehr als 100 KBytes 
schreiben möglich wären, aber durch einen blöden Vergleich von zwei 
unsigned long int (ist nötig wegen der überschreiben Funktionalität) nur 
80-85 KBytes geschrieben werden...
Muss mal sehen ob das nicht einfacher geht...

Grüße Daniel

Hi,

ich verzweifel langsam. ich komm einfach nicht durch die mmc_init.

ich denke, es liegt an meiner verkabelung. hier eine kleine ascii-skizze 
:)
(ATmega162)

--------\
09 (NC)  \
01 (CS)  | ---------- (PB1)
02 (DI)  | ---------- MOSI   (PB6)
03 (GND) | -------------------------- (-)
04 (VCC) | -------------------------- (+)
05 (CLK) | ---------- SCK    (PB7)
06 (GND) | -------------------------- (-)
07 (DO)  | ---------- MISO   (PB5)
08 (NC)  |
---------

Ich habe den ATmega162 mit 3,3V laufen, daher kein HC4050 dazwischen. 
Ich hoffe, daß ist soweit richtig und ich habe nur ein brett vorm kopf.
Als quellcode habe ich das beispiel von "mmc_0.5.1" genommen.

oder mache ich was falsch, wenn ich mein ISP kabel, das ja die selben 
ports benutzt, dranlasse?

ich komm echt nicht weiter und brauche wirklich hilfe!

gruß und danke, matze

So, habe den fehler nach langem probieren gefunden. irgendwie hat der 
uart nicht geklappt, wenn der isp nicht angeschlossen war. ich habe 
jetzt als work-around einfach die masse, an der es lag, von PC zum uC 
extra gezogen.
jetzt geht alles.

aber wie zum kuckkuck mach ich nen zeilenumbruch?
ich hab schon alles probiert: \n und \r sogar schon den 0x0D (ascii code 
für zeilenumbruch).

hilfe.

danke,
matze

Hallo,
schön das es jetzt klappt.

Zeilenumbruch wo? Im Terminal Programm?
Je nachdem welches du benutzt musst du das auf vt100 oder so 
umstellen... dann sollte uputc('\n') oder uputs("\n") auf jeden Fall 
gehen.

Anbei ein Funktionsübersichts Diagramm der ganzen Lib.
Krieg leider die Größe nicht in den Griff. Also hier die Warnung: 2412 x 
7946 Pixel :)

ne,  im terminalprogramm weiß ich das (ich mach das immer mit 0x0D). 
aber in der*.txt auf der SD karte.
Ich kriegs einfach nicht hin.

gruß
matze

Update,
bei Linux ist ein Zeilenumbruch nur 0x0A...

Hallo,

nee das ist kein Problem, da ja schon 512 Bytes gepuffert werden.
Halt ein Sektor, bevor geschrieben wird.

Was allerdings schlecht wäre, ist nach dem schreiben immer direkt ein 
ffclose (obwohl man später eigentlich noch mehr schreiben will), weil 
dabei die Datei Daten ein Update erfahren. Dies bedeutet, dass einmal 
der Sektor wo der Dateieintrag drin steht neu geschrieben wird und evlt. 
muss auch die FAT geupdatet werden (wenn mehr Bytes geschrieben wurden 
als über Cluster schon verkettet sind). Und natürlich der Sektor in dem 
man gerade geschrieben hat auch.

Also einfach öffnen und dann immer mal wieder schreiben ist überhaupt 
kein problem...

Ein Problem könnte sein, wenn man oft innerhalb einer Datei hin und her 
springt. Beispiel:
Ich schreibe in Sektor 1928 ein Byte, jetzt springe ich (mit ffseek) zu 
Sektor 1929 und schreibe wieder ein Byte, weil ich aber Sektor 1928 
verlasse und dieser geändert wurde, muss er vorher geschrieben werden.

Wenn ich jetzt zurück springe, passiert das gleiche wie vorher mit 
Sektor 1928 jetzt mit Sektor 1929.
Das ist der schlimmste Fall, weil für nur 1 geändertes Byte immer ein 
ganzer Sektor geschrieben wird... Würde also 512 Sektor schreib Vorgange 
(also 512*512 Bytes) für 512 Bytes machen. Das wäre schlecht und 
langsam...

Wenn eine Datei angelegt wird, gibt es mindestens 3 Sektor schreib 
Operationen.

1. Anlegen des Datei Eintrags im Ordner.
2. Mindestens einen Sektor mit Daten beschreiben (auch wenn weniger 
Bytes geschrieben werden).
3. Update des Datei Eintrags (Größe usw.).

Macht 3 beschriebene Sektoren. Das wird so gemacht, weil wenn schon mal 
ein Datei Eintrag besteht, kann man mit Recovery-Tools möglicherweise 
bei Datenverlust Daten retten. Dient also rein der Sicherheit. Nötig 
wären nur 2 Sektor schreib Operationen...

Da ein Sektor (512 Bytes) die kleinste Einheit ist die man auf eine 
Karte schreiben kann werden ja eben 512 Bytes gepuffert.

Grüße Daniel

Hi,

ich habe noch einen kleinen Zusatz zur file.c (ist vielleicht etwa 
übertrieben, aber vielleicht als Addon nicht schlech):
Wenn man z.B. Messwerte aufnehmen will, macht ein Zeilenumbruch recht 
viel sinn. Ich habe in meine file.c daher hinzugefügt:

ffzeilenumbruch ()
   {
     ffwrite(0x0D);
     ffwrite(0x0A);
   }

Macht zugegebener Maßen nicht in jeder Anwendung sinn, bei mir 
allerdings schon und ich denke auch bei so mach anderem.

Gruß,
ein Fan dieser Speicherfressenden Library :)
Matze

Hallo zusammen.
Jetzt sind wieder alle 3 Schalter in der Lib zu benutzbar.
Zudem einige Verbesserungen.
Lesend ist bis zu 230 KBytes/s möglich. Beim Roh lesen, also ohne 
Dateisystem kommt man ungefähr auf 300 KBytes/s. Das ist nur ein relativ 
geringer Overhead.
Schreiben geht jetzt bis zu 140 KBytes/s trotz 
überschreiben-Funktionalität.

Bisschen Doku gibts auch hier :
http://www.mikrocontroller.net/articles/AVR_FAT32

PS: Die Zeilenumbruch Funktion wird erstmal nicht aufgenommen, 
allerdings sind weitere Anregungen erwünscht.

Viel Spaß damit :)

Grüße Daniel

Hallo zusammen.

@Alex
Wahrscheinlich ist die Karte jetzt nicht mehr partitioniert, du musst 
also in der fat.h "superfloppy  1" ändern.

@sucher

Ausschnitt Datenblatt:

"The 74HC4050 provides six non-inverting buffers with a
modified input protection structure, which has no diode connected to 
VCC. Input voltages of up to 15 V may therefore be used. This feature 
enables the non-inverting buffers to be used as logic level translators, 
which will convert high level logic to low level logic, while operating 
from a low voltage power supply. For example 15 V logic
(“4000B series”) can be converted down to 2 V logic."

Das verstehe ich so, dass da eine irgendwie geartete Eingangssicherung 
besteht, damit der Eingang nicht kaputt geht. Deshalb kann man bis zu 
15V auf den Eingang machen selbst wenn das Ding nur mit 2V betrieben 
wird.
Rest vom Datenblatt gibt das auch so her...

Grüße Daniel

Hallo.


@Achim

Tatsache, in dem Datenblatt von Thomson steht nur ein schlanker Satz 
dazu, im Rest der Daten finde ich das auch nicht so bestätigt..

"The VCC side diodes are designed to allow logic-level convertion from 
high-level voltages (up to 15 V) to low-level voltages."



@C.Alex

So wie es aussieht, gibt es möglicherweise Probleme mit FAT16 und nur 
einem Sektor pro Cluster... hatte ich nicht getestet, sorry.
Werd ich aber schleunigst beheben.
Bis zum erbrechen hatte ich FAT32 mit mehreren Sektoren pro Cluster 
getestet...
Als workaround, meine Empfehlung: FAT32 mit mehreren Sektoren pro 
Cluster.

Grüße Daniel

Hallo,

also das einzige Problem ist die Formatierung mit Linux, da dabei, warum 
auch immer, das root-Dir wenn es nur 1 Cluster groß ist als Ende 
Markierung nicht 0xfffffff0 erhält, sondern 0xffffff80.
Ich hatte einfach keine Lust mich mit 3 Ende Markierungen 
herumzuschlagen.

Windows ist manchmal etwas eigen beim Formatieren, da wird schon mal aus 
einer partitionierten Karte eine unpartitionierte ohne Kommentar ^^
Muss man nachsehen und in der Lib umstellen.

Andere Probleme gibt es eigentlich nicht im Zusammenhang mit 
Formatierungen.

Was haben die Karten, die nicht durch den Boot Vorgang kommen, denn für 
Eckdaten? MB Größe, Sektoren/Cluster und partitioniert oder 
unpartitioniert?

Grüße Daniel