Hallo,
es gibt ja FAT32 für ATMEL µCs, nur kommt man da bei den großen SD
Karten nicht mehr weiter.
Die Karte soll vom µC gelesen und geschrieben werden können und danach
auf dem PC ausgewertet.
Hier gab's einen Thread wo die einzelnen Dateisysteme genannt wurden,
finde ich aber gerade nicht.
Gibt es für die großen Karten ein passendes FS als Freeware ?
Wie sollte ich die großen Karten anschließen und ansteuern, SPI dürfte
etwas zu langsam werden.
Danke.
abc schrieb:> es gibt ja FAT32 für ATMEL µCs, nur kommt man da bei den großen SD> Karten nicht mehr weiter.
warum nicht?
[...]
Das Dateisystem ist auf 8 Tebibyte (243 Byte) begrenzt, was ca. 8,8
Terabyte entspricht. Dies ergibt sich wie folgt: Die Clustergröße ist
maximal 215 Byte. Es gibt 228 Adressierungsmöglichkeiten. Also kann
maximal ein Bereich von 215 · 228 = 243 Byte adressiert werden.
[...]
Draco schrieb:> Was hast du vor? Was willst du auf diese Karte schreiben das du> Geschwindigkeiten > SPI brauchst?!
Mir wurde gesagt das SPI mit den großen Karten nicht immer richtig
funktioniert.
Ist mein erstes Projekt mit sdcard.
Soll ein Datenlogger werden, dürften schon >1MB/s sein.
Je schneller desto sicherer denke ich.
@ abc (Gast)
>es gibt ja FAT32 für ATMEL µCs, nur kommt man da bei den großen SD>Karten nicht mehr weiter.
Ja, bei Y32 GB braucht man exFAT.
https://de.wikipedia.org/wiki/File_Allocation_Table#exFAT>Die Karte soll vom µC gelesen und geschrieben werden können und danach>auf dem PC ausgewertet.
Schon mal grob überlegt, wie lange man allein an 32 GB mit einem kleinen
AVR schreibt?
Bei 100kB/s dauert das ~92 Stunden im DAUERBETRIEB!
>Gibt es für die großen Karten ein passendes FS als Freeware ?
Kann sein.
>Wie sollte ich die großen Karten anschließen und ansteuern, SPI dürfte>etwas zu langsam werden.
Alles relativ, siehe oben. Was willst du denn dort speichern?
Alle größeren Controller haben heute ein SDIO-Interface. damit kann man
SD-Karten normal mit 4 Bit Busbreite anschließen.
@ abc (Gast)
>Mir wurde gesagt das SPI mit den großen Karten nicht immer richtig>funktioniert.
Kann sein.
>Ist mein erstes Projekt mit sdcard.
Und da willst du gleich den GANZ großen Wurf landen? ;-)
Fang mal ne Nummer kleiner an. SDHC bis 32 GB reicht hier vollkommen.
>Soll ein Datenlogger werden, dürften schon >1MB/s sein.
Das schafft ein kleiner AVR nicht mehr, da braucht man schon was
größeres, wahrscheinlich einen 32 Bit ARM mit SDIO.
>Je schneller desto sicherer denke ich.
Jajaja, höher, schneller, weiter. Siehe oben!
Hier steht es auch noch mal drin:
[...]
Unter Windows 2000 und Nachfolgern darf der Benutzer mit der eingebauten
Funktion „Formatieren“ maximal 32 GiB große FAT32-Dateisysteme neu
erstellen. Auch das Kommandozeilen-Programm format.com hat diese
Beschränkung. Der Zugriff auf größere FAT32-Dateisysteme, die mit
alternativen Werkzeugen erstellt wurden, ist aber immer möglich.
[...]
Fat32 ist nicht auf 32GB begrenzt
Peter II schrieb:> abc schrieb:>> es gibt ja FAT32 für ATMEL µCs, nur kommt man da bei den großen SD>> Karten nicht mehr weiter.>> warum nicht?>> [...]> Das Dateisystem ist auf 8 Tebibyte (243 Byte) begrenzt, was ca. 8,8> Terabyte entspricht. Dies ergibt sich wie folgt: Die Clustergröße ist> maximal 215 Byte. Es gibt 228 Adressierungsmöglichkeiten. Also kann> maximal ein Bereich von 215 · 228 = 243 Byte adressiert werden.> [...]
Was ist denn das für ein Müll. Du kannst weder kopieren noch zitieren.
Falk B. schrieb:> @ abc (Gast)>>>Mir wurde gesagt das SPI mit den großen Karten nicht immer richtig>>funktioniert.>> Kann sein.>>>Ist mein erstes Projekt mit sdcard.>> Und da willst du gleich den GANZ großen Wurf landen? ;-)> Fang mal ne Nummer kleiner an. SDHC bis 32 GB reicht hier vollkommen.>
Kann ich mir leider nicht aussuchen, das soll "zukunftssicher" sein ...
>>Soll ein Datenlogger werden, dürften schon >1MB/s sein.>> Das schafft ein kleiner AVR nicht mehr, da braucht man schon was> größeres, wahrscheinlich einen 32 Bit ARM mit SDIO.>
OK, da könnte ich nachhaken ob der µC auch ein anderer werden darf.
>>Je schneller desto sicherer denke ich.>> Jajaja, höher, schneller, weiter. Siehe oben!
"zukunftssicher" ist halt das "BINGO" Wort hier ...
Gibt's irgendwo Beispielcode zum exFAT auf µC, C wäre schön ?
Danke.
Bernd schrieb:> Was ist denn das für ein Müll. Du kannst weder kopieren noch zitieren.
kannst du das auch begründen? Der "Müll" steht so im Wiki und es steht
dort auch drin, das Windows mit größeren FAT32 Partition zurechtkommt.
Peter II schrieb:> Falk B. schrieb:>> Doch, per Konvention und Standard. Dort rumzufummeln ist nichts als>> Murks.>> nach deinem Standard oder nach welchen?
Ist doch klar.
Der FAT32 - Standard erlaubt Dateisysteme größer 64 GB.
Microsoft hat an den Windows-Format-Tools herumgefummelt, und dort das
erzeugen solcher Dateisysteme mutwillig sabotiert.
Das ist Murks.
Die SDXC-Spec schreibt als Dateisystem exFAT vor.
Seine SD-Karte anders zu formatieren ist deshalb ebenfalls Murks.
Murks² = OK?
Peter II schrieb:> Bernd schrieb:>> Was ist denn das für ein Müll. Du kannst weder kopieren noch zitieren.>> kannst du das auch begründen? Der "Müll" steht so im Wiki und es steht> dort auch drin, das Windows mit größeren FAT32 Partition zurechtkommt.
Willst du mich verarschen?
Planlos schrieb:> Seine SD-Karte anders zu formatieren ist deshalb ebenfalls Murks.
kommt wohl auf das Ziel an.
Wenn er 2min braucht um seine Karte mit Fat32 zu formatieren und schon
funktioniert alles was er braucht dann ist das eine sinnvolle Lösung.
exFat zu Lizensieren und zu Implantieren wird wohl länger dauern.
Falk B. schrieb:>>Fat32 ist nicht auf 32GB begrenzt>> Doch, per Konvention und Standard. Dort rumzufummeln ist nichts als> Murks.
Quellnachweis, bitte.
Ich habe längere Zeit mein WinXP unter FAT32 auf 'ner 80GB Platte
betrieben.
Außer öfteren Scandisk Läufen (nach Bluescreens u.ä.) war das stabil.
M$ will das aus hauptsächlich finanziellen Gründen nicht auf >32GB
haben. Technisch spricht nur dagegen das Files >=4GB nicht auf FAT32
möglich sind.
ExFAT Implementationen für µCs sind mir nicht bekannt, jedenfalls nicht
als Open Source.
Größere Karten könnte man übrigens auch einfach auf <=32GB
partitionieren. Auf einem µC über SPI dauert ansonsten der "Free
Cluster" Check extrem lange, da die FAT dann Größen im MB Bereich hat.
Braucht unter Windoof aber IIRC 3rd partiy Tools.
Peter II schrieb:> Bernd schrieb:>> Willst du mich verarschen?>> kannst du auch etwas sinnvolles schreiben, Kommentare ohne Begründung> sind nicht sehr hilfreich.
Das ist keine Antwort auf meine Frage.
Könntet Ihr Euch bitte mal wieder einkriegen ?
Ist Fön oder was ?
Mein aktuelles Problem ist die Vorgabe:
- ATMEL AVR µC (Modell egal)
- microSD >32GB lesen/schreiben
- Logging >=1MB/s
Und das dollste ist das noch keiner weiß was konkret geloggt werden
soll.
Was ich mir jetzt ausgedacht habe wäre ein Zwischenspeicher um langsamer
schreiben zu können.
Ich finde aber außer kommerziellen Produkten keinen Beispielcode für
exFAT auf µC.
Typischer Fall mal wieder m(
Fassen wir mal zusammen:
-- FAT32 ist auch bei Partitionsgrößen >> 32 GB zulässig, möglich und
durchaus sinnvoll.
-- Der windows-eigene Formatierer setzt eine völlig willkürliche
Obergrenze auf 32 GB. Windows selbst ist aber ohne irgendwelche Probleme
in der Lage, auch mit ganz erheblich größeren Partitionen mit FAT32 zu
arbeiten.
-- Die SD-Karten-Spezifikation schreibt das verwendete Dateisystem vor:
SD(SC) mit maximal 2 GB Größe: FAT16
SDHC mit maximal 32 GB Größe: FAT32
SDXC mit mehr als 32 GB Größe: exFAT
Wenn man ein Gerät als SD-kompatibel verkaufen möchte, sollte es sich an
die Spezifikation halten und kein Umformatieren der Karte mit einem
anderen Dateisystem erfordern.
Wenn einem die Kompatibilität schnurz ist, weil die Speicherkarte nicht
wechselweise in verschiedenen Geräten genutzt werden soll, kann man die
Karte nach Lust und Laune mit irgendwas anderem formatieren. Nur darf
man sich dann nicht wundern, wenn es Probleme gibt, sollte die Karte
dann mal in ein Smartphone, einen mp3-Player oder eine Digitalkamera
gesteckt werden. Diese Geräte rechnen nicht unbedingt damit, andere als
die in der Spezifikation vorgesehenen Dateisysteme vorgesetzt zu bekomen
und können mit interessanten Fehlerbildern reagieren.
Der Schritt zu exFAT war natürlich ein marketing- und
lizenzpolitischer Schritt von MS, weil für den Gebrauch von exFAT
Lizenzgebühren an MS abgeführt werden müssen. Für die anderen
FAT-Varianten theroretisch auch (so jedenfalls hätte es MS gerne), aber
die Praxis scheint da soweit von abzuweichen, daß MS wohl keine
Klagechancen mehr hat.
abc schrieb:> Mein aktuelles Problem ist die Vorgabe:> - ATMEL AVR µC (Modell egal)> - microSD >32GB lesen/schreiben> - Logging >=1MB/s
Darf man fragen wozu du das brauchst? Wo kriegst du kontinuierlich 1MB/s
Daten her? Dazu müsstest du dann alle 20 Takte (bei 20MHz) ein Byte
Daten produzieren und auch noch auf die SD Karte schreiben. Da scheint
mit der AVR doch arg unterdimensioniert.
Was soll dann die Geschichte mit dem Zwischenspeicher? Der bringt ja nur
etwas wenn du nicht kontinuierlich Daten verarbeiten musst. Wie groß
sind die durchschnittlich anfallenden Daten pro Minute/Stunde oder
irgendeiner anderen sinnvollen Größenordnung? Warum bist du der Meinung
man braucht dafür Speicherkarten >32GB?
Sebastian V. schrieb:> abc schrieb:>> Mein aktuelles Problem ist die Vorgabe:>> - ATMEL AVR µC (Modell egal)>> - microSD >32GB lesen/schreiben>> - Logging >=1MB/s>> Darf man fragen wozu du das brauchst? Wo kriegst du kontinuierlich 1MB/s> Daten her? Dazu müsstest du dann alle 20 Takte (bei 20MHz) ein Byte> Daten produzieren und auch noch auf die SD Karte schreiben. Da scheint> mit der AVR doch arg unterdimensioniert.>
Das ist nicht auf meinem Mist gewachsen.
So wie mir der Abteilungsleiter das erklärt hat soll es ein
"universelles, zukunftsicheres, mobiles Datenloggergerät" werden
("BINGO" Worte hatte ich ja schon erwähnt).
> Was soll dann die Geschichte mit dem Zwischenspeicher? Der bringt ja nur> etwas wenn du nicht kontinuierlich Daten verarbeiten musst. Wie groß> sind die durchschnittlich anfallenden Daten pro Minute/Stunde oder> irgendeiner anderen sinnvollen Größenordnung? Warum bist du der Meinung> man braucht dafür Speicherkarten >32GB?
Das das eine Frickellösung ist die wahrscheinlich nicht geht ist mir
auch klar, nur wie kommuniziere ich das nach "oben" ?
Wenn ich jetzt meinen Leiter ignoriere und direkt weiter oben erkläre
das das so nie gehen kann habe ich genauso die A...Karte wie jetzt.
Wenn ich dagegen einen Prototypen aufbauen kann und exFAT lesen bin ich
nicht derjenige welcher ...
Im Grunde brauche ich nur einen Beispielcode für exFAT, aber wenn das
wirklich von MS unter dem Daumen gehalten wird muß ich das mal
weitergeben.
Gibt's da konkrete offizielle Dokumente die man nicht bezahlen muß ?
> Das ist nicht auf meinem Mist gewachsen.> So wie mir der Abteilungsleiter das erklärt hat soll es ein> "universelles, zukunftsicheres, mobiles Datenloggergerät" werden> ("BINGO" Worte hatte ich ja schon erwähnt).
Und dafür setzt man auf einen solches Urgestein? Damit können wir
"universell" und "zukunftssicher" eindeutig streichen.
Rufus Τ. F. schrieb:> Der Schritt zu exFAT war natürlich ein marketing- und> lizenzpolitischer Schritt von MS, weil für den Gebrauch von exFAT> Lizenzgebühren an MS abgeführt werden müssen.
Das scheint mir die Crux dieser Diskussion zu sein.
Sebastian V. schrieb:> abc schrieb:>> Mein aktuelles Problem ist die Vorgabe:>> - ATMEL AVR µC (Modell egal)>> - microSD >32GB lesen/schreiben>> - Logging >=1MB/s>> Darf man fragen wozu du das brauchst? Wo kriegst du kontinuierlich 1MB/s> Daten her? Dazu müsstest du dann alle 20 Takte (bei 20MHz) ein Byte> Daten produzieren und auch noch auf die SD Karte schreiben.
Das ist doch schon die Erklärung warum das nicht gehen kann.
Mach einfach eine Abschätzung wie viele Takte Overhead du pro
Schleifendurchlauf zum Schreiben und Einlesen pro Byte hast.
Dafür gibts im Datenblatt die Anzahl der Takte pro Befehl (in den
meisten Fällen 1 Takt).
Dann siehst du in etwa, wieviel Zeit zum Einlesen der (externen) Daten
und Schreiben auf die (recht langsame) SD Karte bleibt.
Wenn da kein (annehmbarer) Puffer mehr bleibt, dann ist das Projekt mit
den Anforderungen nicht umsetzbar
Da ist es doch einfacher du nimmst gleich einfach einen RPi. Oder sowas
ähnliches. Die können die Datenraten und das Filesystem auch.
Oder warum muss da das Rad neu erfunden werden?
Oder anders gefragt: Warum haltet ihr am AVR fest? Da gibt es sicher
geeignetere Plattformen.
Ist es wichtig dass die Daten geloggt werden oder dass man den AVR
verwendet?
Das gilt es zu klären mit deinen Vorgesetzten.
Gruß, Jens
abc schrieb:> Das das eine Frickellösung ist die wahrscheinlich nicht geht ist mir> auch klar, nur wie kommuniziere ich das nach "oben" ?> Wenn ich jetzt meinen Leiter ignoriere und direkt weiter oben erkläre> das das so nie gehen kann habe ich genauso die A...Karte wie jetzt.
Ganz einfach: Technisch begründet, da ein AVR für diese
Rahmenbedingungen ungeeignet ist. Also die Fakten zusammenfassen,
hingehen und besprechen. Vielleicht will Dein Chef auch nur mal sehen ob
Du an einer sinnfreien Aufgabe weiter machst oder zu ihm kommst um es zu
besprechen...
Natürlich könnte Dein Chef auch einfach nur selber einen Denkfehler
gemacht haben. Ist es denn so schwer ihn einfach mal anzusprechen!?
@ abc (Gast)
>> Und da willst du gleich den GANZ großen Wurf landen? ;-)>> Fang mal ne Nummer kleiner an. SDHC bis 32 GB reicht hier vollkommen.>Kann ich mir leider nicht aussuchen, das soll "zukunftssicher" sein ...
Jaja, und dabei in der Gegenwart vollkommen absaufen. Akademischer
Unsinn!
>"zukunftssicher" ist halt das "BINGO" Wort hier ...
Na dann viel Spaß mit deinem Overkill.
@ Jim Meba (turboj)
>> Doch, per Konvention und Standard. Dort rumzufummeln ist nichts als>> Murks.>Quellnachweis, bitte.
hab ich auch nur Wikipedia, welche auf den SD-Card Standard verweist.
Den hab ich nicht im Orignal angeschaut, glaube der Aussage aber.
>Ich habe längere Zeit mein WinXP unter FAT32 auf 'ner 80GB Platte>betrieben.>Außer öfteren Scandisk Läufen (nach Bluescreens u.ä.) war das stabil.
Mag sein, ist trotzdem nicht standardkonform. Nein, ich bin der
allerletzt, der zum Paragraphenreiter wird, aber die Erfahrung zeigt,
daß solche Sachen in der Praxis immer irgendwie Ärger machen, der sich
einfach nicht lohnt.
@abc (Gast)
>- ATMEL AVR µC (Modell egal)
Da gibt es viele. 8051, AVR, ATXmega, dievers 32 Bit ARM. AVR32 auch
noch.
>- microSD >32GB lesen/schreiben
Haben wir bereits durchgekaut. Wenn es standardkonform sein soll, musst
du exFAT nutzen.
>- Logging >=1MB/s
Schafft ein normaler AVR nicht, dann bleibt nicht mal Zeit für
Datenerfassung!
ATXmega ist gut doppelt so schnell, den würde ich aber auch nicht
nehmen.
Wenn man den WIRKLICH 1 MB/s sicher schaffen will, muss man einen 32
Bitter nehmen. Und ausreichend RAM als Puffer für die SD-Karte, denn die
darf mit Wear Leveling auch mal ein paar 100ms Pause machen.
Rechne mal im schlimmsten Fall mit 1s Pause.
RaspberryPi könnte gehen, WENN man die Datenerfassung als Low Level
Treiber ausführen kann. Das ist aber was für Könner.
>Und das dollste ist das noch keiner weiß was konkret geloggt werden>soll.
Dann ist das Ganze mal wieder akademischer Unsinn. Uniprojekt?
Denn man muss die Daten schießlich auch erfassen.
>Was ich mir jetzt ausgedacht habe wäre ein Zwischenspeicher um langsamer>schreiben zu können.
Ein FIFO kann nur kurzfristig helfen, langfristig muss die mittlere
Ausgangsdatenrate mindestens so groß wie die Eingangsdatenrate sein.
>Ich finde aber außer kommerziellen Produkten keinen Beispielcode für>exFAT auf µC.
Keine Ahung ob das schon mal jemand als Open Source umgesetzt hat.
@ abc (Gast)
>> mit der AVR doch arg unterdimensioniert.>Das ist nicht auf meinem Mist gewachsen.>So wie mir der Abteilungsleiter das erklärt hat soll es ein>"universelles, zukunftsicheres, mobiles Datenloggergerät" werden>("BINGO" Worte hatte ich ja schon erwähnt).
;-)
>Das das eine Frickellösung ist die wahrscheinlich nicht geht ist mir>auch klar, nur wie kommuniziere ich das nach "oben" ?
Hat der Rufus doch schon schön zusammengefaßt.
Beitrag "Re: Gibt es für microSD >64GB ein FS für Atmel µC ?">Wenn ich jetzt meinen Leiter ignoriere und direkt weiter oben erkläre>das das so nie gehen kann habe ich genauso die A...Karte wie jetzt.
Es geht schon, aber mit Einschränkungen und Unsicherheiten.
Hier noch ein Praxisbeispiel.
Ich hab ein Board mit ATXmega @32 MHz. Das SPI läuft mit 8 MHz. Dort
werden bis zu 16 MB Daten aus dem SDRAM auf SD-Karte geschrieben. Das
Ganze kommt über ~180 kB/s nicht hinaus. Und das ist nur das Kopieren,
nebenbei wird nichts anderes gemacht.
OK, man könnte das SPI auf 16 MHz hochdrehen, macht aber auch nur
360kB/s und keinerlei CPU-Reserve.
> Rechne mal im schlimmsten Fall mit 1s Pause.
Gibt es eine Quelle (z. B. Hersteller) wo diese Pause genauer
spezifiziert wird. Eine Sekunde ist keine Pappenstiel bei einem MByte/s.
Das kann ich nur bestätigen. Ich betreibe meine SPI am XMEGA mit 16MHz.
Die doppelte Datenrate schafft man dann aber auch nicht. Ich komme so
auf 200kB/s bis 250kB/s effektiv.
abc schrieb:> Mein aktuelles Problem ist die Vorgabe:> - ATMEL AVR µC (Modell egal)> - microSD >32GB lesen/schreiben> - Logging >=1MB/s
Unmöglich. Aus Erfahrung kann ich dir verraten, dass du mindestens einen
ARM Cortex-M brauchst, mit SDIO und DMA (!!) wie z.B. einen STM32F7
(nimm nicht den F4, der hat da einen Hardware-Bug). Außerdem brauchst du
ein SDRAM-Interface, denn um die Geschwindigkeit zu erreichen brauchst
du viel Puffer-Speicher (>= 8MiB). Plane zudem mindestens ein Mannjahr
Entwicklungszeit ein für die Ansteuerung und den Algorithmus für das
Dateisystem. Die als "Beispiel" vorhandenen Treiber reichen dafür
natürlich nicht, da musst du schon selber ran.
Dass exFAT inkl. Lizenz benötigt wird sollte jetzt ja klar sein, denn
auf den Karten arbeitet ein intelligenter Controller, der das
Wear-Leveling und so anhand der Dateisystem-Strukturen macht, und
SDXC-Karten haben per Spezifikation nunmal exFAT.
Vor allem: Wer soll sich in dem Datenwurm nachher zurechtfinden?
Habe mich kürzlich mit 10000 Messpunkten auf 50 Kanälen rumgeschlagen.
Da ist man froh wenn die Softwareauswertung einem etwas helfen kann.
Tip: Wenn es um irgendwelche Analogwerte geht, schau Dir einen der
gängigen Datenlogger an. Keysight (Agilent), Fluke & Co.
Wenn es um digitale Geschichten geht schau Dir die Funktionalität von
Logicanalyzern an.
Druck das Datenblatt, streich alles weg was Ihr bei Eurem möglichen
Anwendungsspektrum nicht braucht und mach aus dem Rest ein
Pflichtenheft/Provisorisches Datenblatt. Ohne Vorgaben kann man nicht
entwickeln , weil man nicht sagen kann ob etwas funktioniert und ab
welchem Stand es fertig ist.
Ich persönlich schätze an einem unversellen Langzeitlogger wenn man
Daten auslesen kann ohne die Messung zu unterbrechen. Braucht
entsprechende Schnittstellen.
Ein paar Funktionen wie Echtzeituhr oder Kalibrierbarkeit übersieht man
bei schnell einmal.
Erst wenn man weis was man machen will wählt man aus wleches Material
dafür geeignet ist.
viel Erfolg
hauspapa
hauspapa schrieb:> Vor allem: Wer soll sich in dem Datenwurm nachher zurechtfinden?> Habe mich kürzlich mit 10000 Messpunkten auf 50 Kanälen rumgeschlagen.> Da ist man froh wenn die Softwareauswertung einem etwas helfen kann.>
So wie ich das zwischen den "BINGO" Wörtern kleingedruckt gehört habe
soll das wohl die Eierlegendewollmilchsau werden.
> Pflichtenheft/Provisorisches Datenblatt. Ohne Vorgaben kann man nicht> entwickeln , weil man nicht sagen kann ob etwas funktioniert und ab> welchem Stand es fertig ist.>
Der ist gut, es gibt ja nichtmal ein Lastenheft, aber schnell einen
Prototyp haben wollen :-(
> Ich persönlich schätze an einem unversellen Langzeitlogger wenn man> Daten auslesen kann ohne die Messung zu unterbrechen. Braucht> entsprechende Schnittstellen.>
Das wird wohl noch kommen, erstmal soll das Ding einfach angeklemmt
werden und dann nach einer Zeit wieder abgeholt.
> Ein paar Funktionen wie Echtzeituhr oder Kalibrierbarkeit übersieht man> bei schnell einmal.>
Was ich tun soll ist das SD Interface realisieren mit den genannten
Vorgaben.
> Erst wenn man weis was man machen will wählt man aus wleches Material> dafür geeignet ist.>
Ich weiß nicht was die "anderen" Wissen, glaube aber nicht das die
wirklich Plan haben ...
Werde es dann also mal über's WE sacken lassen und Montag versuchen da
einzelne Würmer und so weiter herauszuziehen.
Fasse ich mal zusammen:
- ATMEL AVR zu langsam
- exFAT patentiert
- Samplerate und Schreiben sollten gleich schnell sein
Änderungen:
- 32bit µC mit DMA & Co. >100MHz
- Lizensiertes exFAT für µC kaufen
- Herausfinden was eigentlich geloggt werden soll und Abtastrate
anpassen
Da habe ich Montag einen Gang nach Canossa vor mir.
Welchen µC/Evalboard könntet Ihr mir empfehlen ?
Da ich keine Größenvorgaben habe, hmmmm, ginge ein IndustriePC mit extra
PCIe Meßkarte auch, was meint Ihr ?
Danke für Eure Anregungen.
Peter II schrieb:> was meinst du damit, das ist die Beschreibung aus dem Wiki.>> https://de.wikipedia.org/wiki/File_Allocation_Table#FAT32
Dort steht es richtig. Deine Wiedergabe der Sache hier im Forum war
hingegen völlig falsch. Du hast Exponenten nicht also solche geschrieben
und damit kommt natürlich völliger Quatsch 'raus.
Rufus Τ. F. schrieb:> Fassen wir mal zusammen:>> -- FAT32 ist auch bei Partitionsgrößen >> 32 GB zulässig, möglich und> durchaus sinnvoll.>> -- Der windows-eigene Formatierer setzt eine völlig willkürliche> Obergrenze auf 32 GB.
Schlimmer noch: nur die Formatierungstools neuerer Windows-Systeme
setzen diese willkürliche Grenze. Mit DOS7.1 (AKA Win95b/Win98) z.B. ist
es durchaus noch möglich, wesentlich größere Partitionen mit FAT32 zu
formatieren.
Also GANZ KLAR eine rein strategische Maßnahme von Microsoft. Und man
muss nun nicht auch noch aktiv dafür sorgen, dass Microsofts Strategien
aufgehen...
> -- Die SD-Karten-Spezifikation schreibt das verwendete Dateisystem vor:
Auch dort hat Microsoft massiv strategisch gewirkt (wenn auch Jahre
später und mittlerweile aus ganz anderen Gründen, hier ging es darum,
unbedingt am schnell wachsenden Markt der Mobilgeräte mitzuverdienen).
Aber auch hier gilt: man muss nicht auch noch aktiv dafür sorgen, dass
Microsofts Strategien aufgehen...
> Nur darf> man sich dann nicht wundern, wenn es Probleme gibt, sollte die Karte> dann mal in ein Smartphone, einen mp3-Player oder eine Digitalkamera> gesteckt werden. Diese Geräte rechnen nicht unbedingt damit, andere als> die in der Spezifikation vorgesehenen Dateisysteme vorgesetzt zu bekomen> und können mit interessanten Fehlerbildern reagieren.
Das ist wohl wahr. Aber es zeigt doch nur eins: was für ein schreiender
Unsinn dabei herauskommt, wenn es genug Idioten gibt, die zulassen, dass
Microsofts Strategien aufgehen...
c-hater schrieb:> Rufus Τ. F. schrieb:>> Nur darf>> man sich dann nicht wundern, wenn es Probleme gibt, sollte die Karte>> dann mal in ein Smartphone, einen mp3-Player oder eine Digitalkamera>> gesteckt werden. Diese Geräte rechnen nicht unbedingt damit, andere als>> die in der Spezifikation vorgesehenen Dateisysteme vorgesetzt zu bekomen>> und können mit interessanten Fehlerbildern reagieren.> Das ist wohl wahr. Aber es zeigt doch nur eins: was für ein schreiender> Unsinn dabei herauskommt, wenn es genug Idioten gibt, die zulassen, dass> Microsofts Strategien aufgehen...
Dazu sollte man auch noch erwähnen, daß die Hersteller von Geräten die
SDXC Karten nutzen können sollen, von exFAT keinen Vorteil haben. Denn
bisher war es noch immer so, daß kleinere Karten ebenfalls unterstützt
werden mußten. Die Geräte müssen dann sowohl FAT (alle Karten bis 32GB)
als auch exFAT (ab SDXC) können.
Wenn solche Geräte dann FAT Filesysteme >32GB nicht unterstützen würden,
gäbe es auch dafür keinen triftigen Grund.
abc schrieb:> Könntet Ihr Euch bitte mal wieder einkriegen ?> Ist Fön oder was ?> Mein aktuelles Problem ist die Vorgabe:> - ATMEL AVR µC (Modell egal)
Dann nimm den AT32UC3A3256AU:
32-bit AVR Microcontroller, Audio version, 256KB Flash, 144-pin, SD/SDIO
Card. Alles was dein Herz (oder das deines Managers) begehrt ;-)
> - microSD >32GB lesen/schreiben> - Logging >=1MB/s> Und das dollste ist das noch keiner weiß was konkret geloggt werden> soll.> Was ich mir jetzt ausgedacht habe wäre ein Zwischenspeicher um langsamer> schreiben zu können.
Das hilft dir aber nix. Oder nur dann wenn der Durchschnittsdatenrate
der geloggten Daten immer noch kleiner ist als die Geschwindigkeit womit
du die Daten auf die SD-Karte schreibst.
abc schrieb:> Da habe ich Montag einen Gang nach Canossa vor mir.
Falsche Metapher. Du bist eher der Uberbringer der schlechten Nachricht.
Lasse durchblicken dass es heutzutage nicht mehr üblich ist diesen zu
töten.
Um mal ein Gespür dafür zu bekommen was einzelne Controller mit der
gleichen (in meinen Augen sehr guten FAT-Lib) leisten können, gibt es
Benchmarks bei elmChan:
http://elm-chan.org/fsw/ff/img/rwtest.pnghttp://elm-chan.org/fsw/ff/img/rwtest2.png
Da siehst Du dann dass die erreichten Datenrate neben dem uC / Interface
/ Taktrate am Interface auch sehr von der verwendeten Blockgröße (-->
ausreichend Zwischenspeicher im RAM o.ä. notwendig) und auch von der
verwendeten SD-Karte abhängt.
