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.
Was hast du vor? Was willst du auf diese Karte schreiben das du Geschwindigkeiten > SPI brauchst?!
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!
Falk B. schrieb: > @ Peter II (Gast) > > Keine Macht den Drogen! was meinst du damit, das ist die Beschreibung aus dem Wiki. https://de.wikipedia.org/wiki/File_Allocation_Table#FAT32
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 (Gast)
>Fat32 ist nicht auf 32GB begrenzt
Doch, per Konvention und Standard. Dort rumzufummeln ist nichts als
Murks.
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.
Falk B. schrieb: > Doch, per Konvention und Standard. Dort rumzufummeln ist nichts als > Murks. nach deinem Standard oder nach welchen?
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.
Bernd schrieb: > Willst du mich verarschen? kannst du auch etwas sinnvolles schreiben, Kommentare ohne Begründung sind nicht sehr hilfreich.
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?
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
> Gibt es für die großen Karten ein passendes FS als Freeware ?
tar - wird von jedem endlosen Speichermedium aufgenommen.
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.png http://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.
Kommandozeile vor dem Frühstück für Alle! schrieb: > tar - wird von jedem endlosen Speichermedium aufgenommen. Das ist kein Dateisystem.
Vor allem, wenn man die Hardwarevariante davon verwendet. Ich zitier' mich mal: Beitrag "Re: Microcontroller Arten"
> /dev/null/ hat auch viel Speicherkapazität ;-)
Nein, /dev/null speichert nichts.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.