Hallo Zusammen, Ich arbeite im Moment an einem Datenlogger und habe noch einige Fragen zum optimalen Programmieren in C. Der Dattenlogger ist bereits ferig und schreibt auch schön Daten auf die SD. Allerdings nur testweise einzelne Datensätze. Das ganze soll jetzt schneller besser usw. werden. 1. Optimale Speicherform Größtenteils sollen 8bit Datensätze aus dem ADC gespeichert werden, und 2 Drehzahlsignale die über Interrupts aufgenommen werden. Ich benutze die Lib von Elm Chan, und da ich später am PC zum auslesen eine .txt Datei brauchte, dachte ich mir die 8bit Daten in ASCII zu formatieren und als String in die .txt zu schreiben. Gibt es eine Funktion die integer in das zugehörige ASCII Zeichen wandelt? Idealerweise schneller wie wenn ich den Integer in einen String wandle und diesen auf die SD schreibe. Mit wie vielen Taktzyklen ist grob zu rechnen? ( Für Wandeln von Integer in ASCII Char bzw. Strings. ibt es allgemein irgendwo Übersichten Erfahrungswerte wie viele Zyklen welche Funktion braucht? Wenn ich mir die Benchmarks von Elm Chan ansehe, und ich sie richtig verstehe, wäre es am besten möglichst lange Strings zu schreiben, anstatt immer nur einzelne Datensätze hinzuzufügen? 2. Menü?! Einstellmöglichkeiten Im Moment habe ich 2 Variablen anhand denen die Daten die auf dem Display angezeigt werden sollen,ausgewählt werden. Diesen werden von if-else abgefragt , aber ich denke das ist nicht die beste Option, gibt es evtl einen Thread wo ähnliches Besprochen wurde? Bzw wonach muss ich suchen? Grüße Rico Im Moment benutze ich einen AtMega168A aber ich will mich da nicht festlegen.
@ Rico S. (donricone) >eine .txt Datei brauchte, dachte ich mir die 8bit Daten in ASCII zu >formatieren und als String in die .txt zu schreiben. Kann man machen. >Gibt es eine Funktion die integer in das zugehörige ASCII Zeichen >wandelt? itoa >Idealerweise schneller wie wenn ich den Integer in einen String >wandle und diesen auf die SD schreibe. Warum? Wieviele Millionen Zeichen willst du denn pro Sekunde wandeln? >Mit wie vielen Taktzyklen ist grob zu rechnen? ( Für Wandeln von Integer >in ASCII Char bzw. Strings. >ibt es allgemein irgendwo Übersichten Erfahrungswerte wie viele Zyklen >welche Funktion braucht? Frag den Simulator. Und viel wichtiger. Sag erstmal, was dein ZIEL ist. Einfach nur schnell, schnell ist Unsinn. >Wenn ich mir die Benchmarks von Elm Chan ansehe, und ich sie richtig >verstehe, wäre es am besten möglichst lange Strings zu schreiben, >anstatt immer nur einzelne Datensätze hinzuzufügen? Man schreibst lange BLÖCKE, aber das ist durch die Pufferung im FatFs nicht sooo kritisch. Ich hab es auch mal gemessen, siehe Anhang. Selbst mit 100 Byte Blöcken schafft man noch 100kB/s ! der Test lief mit 8 MHz SPI-Takt. >Im Moment habe ich 2 Variablen anhand denen die Daten die auf dem >Display angezeigt werden sollen,ausgewählt werden. Diesen werden von >if-else abgefragt , aber ich denke das ist nicht die beste Option, Muss es immer die BESTE sein? Reicht nicht auch mal ein "gut"?
>Gibt es eine Funktion die integer in das zugehörige ASCII Zeichen >wandelt? Idealerweise schneller wie wenn ich den Integer in einen String >wandle und diesen auf die SD schreibe. Das ist doch das gleiche. Am schnellsten geht es wenn der schlappe AVR die Daten einfach roh auf die SD Karte schreibt und die Auswertung auf dem PC erfolgt.
Falk Brunner schrieb: > Man schreibst lange BLÖCKE, aber das ist durch die Pufferung im FatFs > nicht sooo kritisch. Ich hab es auch mal gemessen, siehe Anhang. Selbst > mit 100 Byte Blöcken schafft man noch 100kB/s ! der Test lief mit 8 MHz > SPI-Takt. Hi Falk, (und sorry Rico falls meine Fragen nicht zu Deinen Überlegungen passt.) Ich habe mir den FatFS Code angeschaut - noch nicht im Detail aber doch - und so wie ich das sehe puffert FatFS nicht komplette 512 KB Blöcke bevor geschrieben wird? Oder? Wäre es nicht besser - auch in Hinblick auf die Lebensdauer der SD-Card - die Daten solange im SRAM zu speichern bis man einen kompletten 512 KB Block beinander hat und erst dann auf die SD speichert? Und zu guter letzt, wie viel SRAM braucht alleine die FatFS vom Chen? Oder anders gefragt, wie viel SRAM braucht man mindestens um noch einen kompletten Block zwischenzuspeichern wenn man die FatFS verwendet? LG Ernst
Ernst B. schrieb: > 512 KB Blöcke 512 Byte, nicht kilobyte. Welche Buffer benutzt werden, hängt von der FatFS-Konfiguration ab (FS_TINY etc.), es gibt aber mindestens einen Sektorbuffer (>= 512 Bytes).
Marian B. schrieb: > es gibt aber mindestens einen > Sektorbuffer (>= 512 Bytes). Hi Marian! Danke für den Hinweis auf einen kleinen Faktor 1024 Fehler! :-) Wenn man sich das Foolproof Beispiel ansieht da werden aber weniger als 512 Bytes auf die SD-Karte geschrieben? Irgendwie habe ich den Puffer noch nicht gecheckt... oder gefunden. Wenn man eine Datei auf der SD öffnet, dann ein paar Bytes Daten drauf schreibt und dann wieder die Datei schließt dann werden die doch gleich geschrieben? Wie gesagt, ich checke es nicht wann gepuffert wird oder nicht...
:
Bearbeitet durch User
@ Ernst B. (puravida) >- und so wie ich das sehe puffert FatFS nicht komplette 512 KB Blöcke >bevor geschrieben wird? Oder? Es puffer 512 Bytes = 1 Sektor. >Wäre es nicht besser - auch in Hinblick auf die Lebensdauer der SD-Card >- die Daten solange im SRAM zu speichern bis man einen kompletten 512 KB >Block beinander hat und erst dann auf die SD speichert? Nein, nicht nötig, darum kümmert sich FatFs und die SD-Karte. >Und zu guter letzt, wie viel SRAM braucht alleine die FatFS vom Chen? >Oder anders gefragt, wie viel SRAM braucht man mindestens um noch einen >kompletten Block zwischenzuspeichern wenn man die FatFS verwendet? Ich glaube etwas mehr als 1 kB. Also verkraftbar, wenn man einen 4kB SRAM AVR hat.
Die Variante, die am wenigsten Rechenzeit frisst: Die SD-Karte so vorbereiten, dass sie bereits eine (sehr große) Datei enthält. Dann kann man ohne Dateisystem schreiben, nämlich direkt an die Speicheradressen der Blocks. Zu den 512-Bytes-Blöcken: Wenn man direkt schreibt - wie gerade von mir vorgeschlagen - kann man so langsam schreiben wie man will. Gespeichert wird immer erst dann, wenn 512 Bytes fertig sind. Man braucht also gar keinen Puffer im SRAM. Zu itoa(): Das Thema hatte ich grad in einem anderen Thread. Wie lange braucht itoa() auf dem genannten ATmega168A für eine 5-Stellige Zahl? Wie lange für eine 10-stellige (wahrscheinlich dann ultoa oder so)? Gibt es da Erfahrungen?
>Die SD-Karte so vorbereiten, dass sie bereits eine (sehr große) Datei >enthält. Dann kann man ohne Dateisystem schreiben, nämlich direkt an die >Speicheradressen der Blocks. Ja, den Schwachsinn liest man immer wieder mal. Was ist wenn die Karte fragmentiert ist? Dann gehts in die Hose. Karte mal neu formatiert, Anfangsadresse des ersten Sektors der Datei muss neu bestimmt werden. Super klasse Idee so ein Müll. Wenn man schnell auf eine SD Karte schreiben will nimmt man halt keinen uralten AVR sondern einen ARM mit SDIO. Der hat dann auch genug RAM für Multiblock Writes. Erst diese Multiblock Writes machen das schreiben auf eine SD wirklich schnell. Womit wir dann wieder bei dem Thema sind warum alte 8 Bitter heute nur noch scheisse sind;)
Markus Weber schrieb: > Wenn man direkt schreibt - wie gerade von mir vorgeschlagen - kann man > so langsam schreiben wie man will. Gespeichert wird immer erst dann, > wenn 512 Bytes fertig sind. Man braucht also gar keinen Puffer im SRAM. Dann geht die SD Karte aber nie in Standby, oder?
Ernst B. schrieb: > Und zu guter letzt, wie viel SRAM braucht alleine die FatFS vom Chen? > Oder anders gefragt, wie viel SRAM braucht man mindestens um noch einen > kompletten Block zwischenzuspeichern wenn man die FatFS verwendet? http://elm-chan.org/fsw/ff/en/appnote.html Ohne _FS_TINY: 560 Bytes plus 544 Bytes pro offener Datei. D.h. ein Sektorbuffer fürs Volume plus ein Sektorbuffer pro Datei Mit _FS_TINY: 560 Bytes plus 32 Bytes pro offener Datei. Also ein gemeinsamer Sektorbuffer für alles. Wenn die SD-Karte nur unter z.B. Linux gelesen werden muss, kann man auch ein einfacheres Dateisystem als FAT nehmen. Minix 3 z.B. > The file I/O buffer is a sector buffer to read/write a partial > data on the sector. The sector buffer is either file private > sector buffer on each file object or shared sector buffer in the > file system object. The buffer configuration option _FS_TINY > determins which sector buffer is used for the file data > transfer. When tiny buffer (1) is selected, data memory > consumption is reduced 512 bytes each file object. In this case, > FatFs module uses only a sector buffer in the file system object > for file data transfer and FAT/directory access. The disadvantage > of the tiny buffer configuration is: the FAT data cached in the > sector buffer will be lost by file data transfer and it must be > reloaded at every cluster boundary. However it will be suitable > for most application from view point of the decent performance > and low memory comsumption.
:
Bearbeitet durch User
holger schrieb: > Womit wir dann wieder bei dem Thema sind warum alte 8 Bitter > heute nur noch scheisse sind;) Da kann schon was dran sein. Aber wenn man keine Ahnung von den Cortexen hat... :-) Und anders als der TE habe ich kein Zeitproblem, zumindest beim Speichern. Es wäre aber cool wenn jemand das mit dem Puffern erklären könnte in Zusammenhang mit FatFS und/oder SD-Karten. Oder einen Link hat wo man das nachlesen könnte.
Ernst B. schrieb: > Es wäre aber cool wenn jemand das mit dem Puffern erklären könnte in > Zusammenhang mit FatFS und/oder SD-Karten. Oder einen Link hat wo man > das nachlesen könnte. http://elm-chan.org/fsw/ff/en/appnote.html http://elm-chan.org/docs/mmc/mmc_e.html Beitrag "Re: Geschwindigkeitsfrage AVR auf SD"
:
Bearbeitet durch User
@Markus Weber (Firma: guloshop.de) (m-w) >Die SD-Karte so vorbereiten, dass sie bereits eine (sehr große) Datei >enthält. Dann kann man ohne Dateisystem schreiben, nämlich direkt an die >Speicheradressen der Blocks. Bastelmurks! Wenn man sich mal HALBWEGS mit dem Thema und z.B. dem VORZÜGLICHEN FatFs (sowohl die Software als auch Doku!) beschäftigt, wird man merken, dass eben genau DAS schon direkt möglich ist! Man kann beim Öffnen einer Datei erstmal die Maximalänge festlegen, dann wird schon mal der gesamte Speicher auf der Karte reserviert und der Schreibzugriff passiert mit minimalem Overhead! http://elm-chan.org/fsw/ff/en/lseek.html
1 | /* Cluster pre-allocation (to prevent buffer overrun on streaming write) */
|
2 | |
3 | res = f_open(fp, recfile, FA_CREATE_NEW | FA_WRITE); /* Create a file */ |
4 | |
5 | res = f_lseek(fp, PRE_SIZE); /* Expand file size (cluster pre-allocation) */ |
6 | if (res || f_tell(fp) != PRE_SIZE) ... /* Check if the file has been expanded */ |
7 | |
8 | res = f_lseek(fp, DATA_START); /* Record data stream WITHOUT cluster allocation delay */ |
9 | ... /* DATA_START and write block size should be aligned to sector boundary */ |
10 | |
11 | res = f_truncate(fp); /* Truncate unused area */ |
12 | res = f_lseek(fp, 0); /* Put file header */ |
13 | ...
|
14 | |
15 | res = f_close(fp); |
Ohne FAT auf ne SD-Karte zu schreiben ist einfach nur Bastelmurks. Wer mal einen Blick auf meine Messung wirft wird leicht merken, dass das mehr als schnell genug für einen AVR als Logger ist! Beitrag "Re: Geschwindigkeitsfrage AVR auf SD"
holger & Falk: Ich respektiere natürlich eure Sichtweise. :-) Trotzdem halte ich meinen Vorschlag, mit einem Pseudo-FAT zu arbeiten weder für "Schwachsinn" noch für Bastelmurks. Vielleicht hab ich es aber auch nicht klar genug beschrieben: Ich gehe davon aus, dass nur der Logger auf die Karte schreibt, alle anderen nur lesend drauf zugreifen. Dann liegt es doch nahe, dass die Karte (meinetwegen vom Logger) mit einem konstanten Header so vorbereitet wird, dass die zu schreibenden Daten in fortlaufenden Blöcken ab einer bestimmten Adresse geschrieben werden können. Der Logger braucht sich dann nicht um eine Allocation Table zu kümmern, er kann sich alleine aufs Schreiben konzentrieren. Vorteile: - man braucht keine FAT-Bibliotheken - Echtzeitbetrieb leichter möglich, weil der Logger nicht zwischendurch immer wieder lesend auf die SD-Karte (bzw. auf die gecachete FAT) zugreifen muss --> das Programm auf dem Logger läuft schneller und ist kleiner
Markus Weber schrieb: > Ich gehe davon aus, dass nur der Logger auf die Karte schreibt, alle > anderen nur lesend drauf zugreifen. Dann liegt es doch nahe, dass die > Karte (meinetwegen vom Logger) mit einem konstanten Header so > vorbereitet wird, dass die zu schreibenden Daten in fortlaufenden > Blöcken ab einer bestimmten Adresse geschrieben werden können. Und das findest du nicht Bastelmurks? Markus Weber schrieb: > - Echtzeitbetrieb leichter möglich, weil der Logger nicht zwischendurch > immer wieder lesend auf die SD-Karte (bzw. auf die gecachete FAT) > zugreifen muss Das ist in der Praxis falsch. Spätestens wenn der SD-Controller bei einem Write erstmal das Wear Leveling anwirft und das Schreiben vierhundert mal länger benötigt als normalerweise. Da du bei SD-Karten keinerlei Garantien hast, was wie lange dauert, sind sie als Medium für Echtzeit ( das Schreiben dieser Daten darf maximal 81 ms dauern ) denkbar schlecht geeignet.
:
Bearbeitet durch User
Hi Marian! Danke für die Links und die Mühe. Marian B. schrieb: > Beitrag "Re: Geschwindigkeitsfrage AVR auf SD" Diese Antwort hatte ich gar nicht gesehen, hat sich wohl überschnitten gehabt. LG Ernst
Nochmal zurück zu meiner Frage, bzw ich muss sie wohl nochmal genauer stellen, itao wandelt ja mein integer einfach um, aber das will ich nicht. Der 8 Bit Wandler liefert Werte zwischen 0 und 255 jeder dieser Werte hat ein zugeordnetes Zeichen in ASCII, 43 wird "+" 75 wird "K" usw. So hatte ich mir das vorgestellt, jedes Zeichen der Log Datei enthält nun einen Messwert.
@ Markus Weber (Firma: guloshop.de) (m-w) >Logger braucht sich dann nicht um eine Allocation Table zu kümmern, er >kann sich alleine aufs Schreiben konzentrieren. Das interessiert nicht, denn es funktioniert auch so sehr schnell. Der Beweis wurde mehrfach erbracht. >- man braucht keine FAT-Bibliotheken Die gibt es von vielen Leuten komplett fix und fertig und kostenlos. Die 10-15kB Flash interessieren keinen, schon gar nicht bei Hobbyprojekten. >- Echtzeitbetrieb leichter möglich, weil der Logger nicht zwischendurch >immer wieder lesend auf die SD-Karte (bzw. auf die gecachete FAT) >zugreifen muss Ebenfalls falsch, wie bereits mehrfach geschrieben. Erstens ist der Overhead mit FAT und Know How (Preallocation) nahe Null und zweitens spuckt dir Wear Leveling so oder so dazwischen. Ein ausreichend großer FIFO ist in JEDEM Fall nötig.
Marian B. schrieb: > Und das findest du nicht Bastelmurks? Nein. Warum sollte ich auch? Die Leute, die so eine FAT-Library programmieren, schreiben auch ihre Bits direkt auf die SD-Karte. Einer muss das am Ende ja machen. :-) Falk Brunner schrieb: > Das interessiert nicht, denn es funktioniert auch so sehr schnell. Der > Beweis wurde mehrfach erbracht. Ja, sehr schnell, aber in meinem Fall nicht schnell genug, weil der Mikrocontroller noch andere Aufgaben hatte, die er mit garantierten Reaktionszeiten erledigen musste. In solchen Fällen verbieten sich Aufrufe von Lib-Funktionen. Klar, das ist kein Standardfall, aber es gibt eben auch Nicht-Standard-Fälle. Pauschale Urteile helfen da nicht immer... > Die gibt es von vielen Leuten komplett fix und fertig und kostenlos. Die > 10-15kB Flash interessieren keinen, schon gar nicht bei Hobbyprojekten. Auch hier gilt: Stimmt meistens – aber eben nicht immer. Eine meiner Zielplattformen war ein ATtiny85. > Ebenfalls falsch, wie bereits mehrfach geschrieben. Erstens ist der > Overhead mit FAT und Know How (Preallocation) nahe Null und zweitens > spuckt dir Wear Leveling so oder so dazwischen. Ein ausreichend großer > FIFO ist in JEDEM Fall nötig. Hier hast du Recht, ich habs blöd ausgedrückt. Besser so: Bei Nutzung einer FAT-Lib lassen sich geringe Reaktionszeiten für andere Ereignisse schlecht garantieren. Damit meine ich Zeiten unter 1 µs. Dadurch schied die Lib-Lösung in meinem Fall aus. Für mich brachte der Lösungsansatz mit einer FAT-Library also viel mehr Nachteile als Vorteile. Es gab sogar K.O.-Kriterien. Für 99 % der Fälle ist die Lösung mit einer Lib natürlich besser und bequemer, das seh ich genauso. Aber unterschlage bitte nicht das verbleibende eine Prozent. :-)
@ Markus Weber (Firma: guloshop.de) (m-w) >Ja, sehr schnell, aber in meinem Fall nicht schnell genug, weil der >Mikrocontroller noch andere Aufgaben hatte, die er mit garantierten >Reaktionszeiten erledigen musste. In solchen Fällen verbieten sich >Aufrufe von Lib-Funktionen. Blödsinn. erzähl doch mal, was du da angeblich soooo kritisches machen willst? >Auch hier gilt: Stimmt meistens – aber eben nicht immer. Eine meiner >Zielplattformen war ein ATtiny85. Aha, weil ein AVR mit mehr Flash nicht dort reinpasst? >Hier hast du Recht, ich habs blöd ausgedrückt. Besser so: Bei Nutzung >einer FAT-Lib lassen sich geringe Reaktionszeiten für andere Ereignisse >schlecht garantieren. Damit meine ich Zeiten unter 1 µs. >Dadurch schied die Lib-Lösung in meinem Fall aus. Dann stimmt dein Konzept so oder so nicht. Auch ohne FAT schreibst du keine SD-Karte und hast nebenbei 1us Reaktionszeiten. btw, ein FAT heißt ja nicht, dass man keine Interrupts nutzen kann. >Für mich brachte der Lösungsansatz mit einer FAT-Library also viel mehr >Nachteile als Vorteile. Es gab sogar K.O.-Kriterien. Wollen wir wetten, dass das nur deine einseitige Sichtweise war/ist und das Problem auch MIT FAT lösbar wäre? >Für 99 % der Fälle ist die Lösung mit einer Lib natürlich besser und >bequemer, das seh ich genauso. Ach, auf einmal? > Aber unterschlage bitte nicht das >verbleibende eine Prozent. :-) Beschreibe DEIN verbleibendes Prozent?
>Nochmal zurück zu meiner Frage, bzw ich muss sie wohl nochmal genauer >stellen, itao wandelt ja mein integer einfach um, aber das will ich >nicht. Du musst gar nichts umwandeln. >Der 8 Bit Wandler liefert Werte zwischen 0 und 255 jeder dieser Werte >hat ein zugeordnetes Zeichen in ASCII, 43 wird "+" 75 wird "K" usw. Warum willst du da dann was umwandeln? 43 = '+' = 0x2B = 0b01000011 Ein Byte ist ein Byte ist ein Byte. >So hatte ich mir das vorgestellt, jedes Zeichen der Log Datei enthält >nun einen Messwert. Falsch, jedes Byte der Log Datei enthält einen Messwert. Ob du dieses Byte als ASCII Zeichen, Hex, oder Binär interpretierst ist deine Sache. Es ist für den uC oder den PC immer derselbe Wert. Du musst nichts anderes tun als dein Byte zu speichern. Eine Umwandlung ist nicht notwendig.
Falk Brunner schrieb: > @ Markus Weber (Firma: guloshop.de) (m-w) > >>Ja, sehr schnell, aber in meinem Fall nicht schnell genug, weil der >>Mikrocontroller noch andere Aufgaben hatte, die er mit garantierten >>Reaktionszeiten erledigen musste. In solchen Fällen verbieten sich >>Aufrufe von Lib-Funktionen. > > Blödsinn. erzähl doch mal, was du da angeblich soooo kritisches machen > willst? Frank, ich weiß, wovon ich rede, das kannst du mir glauben. Musst es aber natürlich nicht, das steht dir völlig frei. :-) Ich persönlich finde es auch nicht schlimm, wenn du mir nicht glaubst. Du hast deine eigenen Erfahrungen, andere Ansichten, das respektiere ich. Das wiederholte "Schwachsinn" und "Blödsinn" finde ich trotzdem irgednwie nicht passend. > Aha, weil ein AVR mit mehr Flash nicht dort reinpasst? Größe war eines von mehreren Kriterien, das ist richtig. Man kann aber auch sagen: "weil ein AVR mit mehr Flash nicht notwendig ist". > Dann stimmt dein Konzept so oder so nicht. Auch ohne FAT schreibst du > keine SD-Karte und hast nebenbei 1us Reaktionszeiten. Ich glaube, hier irrst du. Das ist durchaus möglich, sogar mit einem popeligen AVR. Wie du sicher weißt: Ein AVR macht bei 20 MHz Takt 20 Befehle je µs (in der Praxis eher 15, weil manche Befehle 2 Takte brauchen). Der angesprochene ATtiny85 läuft mit internem RC-Oszillator mit 16 MHz. Da kannst du sogar durch aktives Klappern der IO-Leitungen auf die SD-Karte schreiben. > btw, ein FAT heißt ja nicht, dass man keine Interrupts nutzen kann. Stimmt sicher. Dazu müsste ich aber den Quellcode der Bibliotheksfunktionen durchsehen, ob dort irgendwo vorübergehend die Interrupts blockiert werden. Hier wahrscheinlich nicht entscheidend, aber es gibt auch Fälle, in denen Interrupts zu langsam sind und man eben pollt. > Wollen wir wetten, dass das nur deine einseitige Sichtweise war/ist und > das Problem auch MIT FAT lösbar wäre? Du meinst "mit FAT-Library", oder? Weil FAT an sich verwende ich ja, nur eben ohne Bibliothek. Aber wenn du einen Weg mit Bibliothek und so geringen Reaktionszeiten findest, der dann auch noch mit einem billigen µC läuft, habe ich ein offenes Ohr. >>Für 99 % der Fälle ist die Lösung mit einer Lib natürlich besser und >>bequemer, das seh ich genauso. > > Ach, auf einmal? Klar. Sorry, wenn es vielleicht anders rübergekommen ist, ich bin nicht so verbohrt, dass ich meinen Ansatz für den einzig möglichen halte. Es hängt immer von den übrigen Unständen ab, welcher Weg für einen ganz bestimmten Anwendungsfall der "richtige" ist.
@ Markus Weber (Firma: guloshop.de) (m-w) >Frank, ich weiß, wovon ich rede, das kannst du mir glauben. Glauben kann man in der Kirche, hier geht es um technische FAKTEN! >Größe war eines von mehreren Kriterien, das ist richtig. Man kann aber >auch sagen: "weil ein AVR mit mehr Flash nicht notwendig ist". Schwaches Argument. >Da kannst du sogar durch aktives Klappern der IO-Leitungen auf die >SD-Karte schreiben. Das ist gar nicht der Punkt. >Aber wenn du einen Weg mit Bibliothek und so geringen Reaktionszeiten >findest, der dann auch noch mit einem billigen µC läuft, habe ich ein >offenes Ohr. Wenn du deine Applikation nicht beschreibst und immer nur gemeinnisvoll und selbstsicher tust, geht das wohl kaum. Beschreibe deine Anwendung und wir können drüber reden.
Wieso sollte eine Bibliothek einen signifikanten Unterschied in den Reaktionszeiten erzeugen? Das finde ich kein überzeugendes Argument — erst recht nicht ohne Untermauerung.
Falk Brunner schrieb: > Glauben kann man in der Kirche, hier geht es um technische FAKTEN! Ich habe das Gefühl, du gehst davon aus, ich müsse dir beweisen, dass meine konzeptionellen Entscheidungen in dem von mir betreuten Projekt richtig sind. Sogar darüber hinaus, dass sie in deinen Augen richtig sind. Hier muss ich dich enttäuschen. >>Größe war eines von mehreren Kriterien, das ist richtig. Man kann aber >>auch sagen: "weil ein AVR mit mehr Flash nicht notwendig ist". > > Schwaches Argument. Wie ebenfalls schon geschrieben: Du musst diese Ansicht nicht teilen. Es herrscht Meinungsfreiheit. :-) Du denkst, ich soll einen größeren Mikrocontroller verwenden, obwohl es gar nicht notwendig ist? Nunja, kann man freilich machen, das ist aber nicht mein Weg. > Wenn du deine Applikation nicht beschreibst und immer nur gemeinnisvoll > und selbstsicher tust, geht das wohl kaum. Ich bringe mich in diese Diskussion (in diesen Thread) ein, um zum Thema etwas beizutragen, nicht um das Pflichtenheft eines meiner Projekte zu veröffentlichen. Auf die Gefahr mich zu wiederholen: ich bin hier in keiner Beweispflicht. > Beschreibe deine Anwendung und wir können drüber reden. Dazu habe ich aber doch keinen Anlass. Sie funktioniert prima. Marian B. schrieb: > Wieso sollte eine Bibliothek einen signifikanten Unterschied in den > Reaktionszeiten erzeugen? Das finde ich kein überzeugendes Argument — > erst recht nicht ohne Untermauerung. Ich schlage vor, dass du das selbst ausprobierst und vergleichst. :-) Auf der einen Seite: ein Funktionsaufruf in der Bibliothek. Auf der anderen Seite: lineare Programmierung ohne Unterprogrammaufruf, die ohne Rückgriff auf die FA-Table einen Datenblock an eine absolute Adresse der SD-Karte schreibt. Bei der zweiten Methode hast du die Möglichkeit, jedes Byte des 512 Bytes großen Datenblocks einzeln zur SD-Karte rüberzuschieben und dich zwischen diesen Bytes um eine andere (hochpriore) Aufgabe zu kümmern. Das geht bei einer Bibliotheksfunktion natürlich nicht. Außer, du verwendest eine ISR – mit entsprechender negativer Auswirkung auf die Performance und dem Verlust der vollen Kontrolle, weil du normalerweise nicht sichergehen kannst, dass eine Bibliotheksfunktion die Interrupts nicht für kurze Zeit abschaltet um selbst irgendetwas Wichtiges zu erledigen.
@ Markus Weber (Firma: guloshop.de) (m-w) >Ich habe das Gefühl, du gehst davon aus, ich müsse dir beweisen, dass >meine konzeptionellen Entscheidungen in dem von mir betreuten Projekt >richtig sind. Das musst du, wenn du deine Aussage begründen willst. SOnst beleibt es nicht als eine Behauptung, die einfach so im Raum steht. Davon gibt es in diesem Forum schon genug. >Sogar darüber hinaus, dass sie in deinen Augen richtig >sind. Das ist der Sinn eines Forums! Technische Probleme und deren Lösungen diskutirerne, nicht einfach nur Meinungen und basta. >Wie ebenfalls schon geschrieben: Du musst diese Ansicht nicht teilen. Es >herrscht Meinungsfreiheit. :-) Sicher. Meinen kann man alles! Aber ohne sachliche Begründung darfst du auch keine Sekunde erwarten, ernst genommen zu werden. >Du denkst, ich soll einen größeren Mikrocontroller verwenden, obwohl es >gar nicht notwendig ist? Nunja, kann man freilich machen, das ist aber >nicht mein Weg. Hat kein Mensch gesagt. >Ich bringe mich in diese Diskussion (in diesen Thread) ein, um zum Thema >etwas beizutragen, Nein! Du kannst deine Aussage INHALTLICH nicht begründen, nur nebulös "ich weiß schon warum das so ist". Das ist keine technische Diskussion, das ist Voodoo. > nicht um das Pflichtenheft eines meiner Projekte zu >veröffentlichen. Auf die Gefahr mich zu wiederholen: ich bin hier in >keiner Beweispflicht. Doch! Für deine Aussage, warum eben die Lösung in diesem Fall so sein muss. Klar musst du nicht jedes (kommerzielle) Detail offenlegen, aber die Grundaussage muss erkennbar sein. >Dazu habe ich aber doch keinen Anlass. Sie funktioniert prima. Und ist geheim und somit indiskutabel. >Bei der zweiten Methode hast du die Möglichkeit, jedes Byte des 512 >Bytes großen Datenblocks einzeln zur SD-Karte rüberzuschieben und dich >zwischen diesen Bytes um eine andere (hochpriore) Aufgabe zu kümmern. Prinzipiell ja. Wenn es aber soweit kommt, hat man meist ein konzeptionelles Problem.
Markus Weber schrieb: > Bei der zweiten Methode hast du die Möglichkeit, jedes Byte des 512 > Bytes großen Datenblocks einzeln zur SD-Karte rüberzuschieben und dich > zwischen diesen Bytes um eine andere (hochpriore) Aufgabe zu kümmern. Ja eben nicht. Kann sein, dass das bei dir gut geht zeitlich, aber ich gehe davon aus, dass du — sofern du Busy korrekt auswertest — immer wieder Glitches hast, weil die Karte länger braucht, in deinem "Realtime".
Marian B. schrieb: > Ja eben nicht. Kann sein, dass das bei dir gut geht zeitlich, aber ich > gehe davon aus, dass du — sofern du Busy korrekt auswertest — immer > wieder Glitches hast, weil die Karte länger braucht, in deinem > "Realtime". Genau richtig, ich schreibe nicht, solange die SD-Karte "busy" anzeigt, das ist schon klar. Auf das Ende des Busy-Signals wartet das Programm aber nicht in einer leeren Dauerschleife; das Signal wird immer nur dann gepollt, wenn es die übrigen Aufgaben zulassen. Deswegen gibt es keine zeitlichen Lücken bei diesen anderen Aufgaben des Controllers.
@ Markus Weber (Firma: guloshop.de) (m-w) >Genau richtig, ich schreibe nicht, solange die SD-Karte "busy" anzeigt, >das ist schon klar. Auf das Ende des Busy-Signals wartet das Programm >aber nicht in einer leeren Dauerschleife; das Signal wird immer nur dann >gepollt, wenn es die übrigen Aufgaben zulassen. >Deswegen gibt es keine zeitlichen Lücken bei diesen anderen Aufgaben des >Controllers. OK, eine extreme Variante von Multitasking. Ist das in ASM oder C gemacht? Weil wenn es denn WIRKLICH SOO zeitkritisch ist, muss es ja fast ASM sein. Aber auch hier kann man mit ganz normalem FAT arbeiten, wenn gleich natürlich die Scheibfunktion derartig extrem gestaltet sein muss. Aber die Verwaltung und Sektoradressierung braucht keine Tricks. Der einzige Trick heißt Preallocation und cluster link map table, wie sie auch bei FatFs vom ELM CHAN benutzt wird. Wenn gleich sowas machbar ist, würde ich solche Stunts eher nicht machen sondern durch ein passendes Konzept ggf. mit etwas Vorverarbeitung in Hardware (CPLD & Co) den AVR soweit zeitlich entlasten, dass es mit dem Standardansatz und einer normalen FAT- Lib geht. Weil so einen Krampf würde ich mir nicht antun wollen, auch wenn es möglich ist. Aber was machst du, wenn die SD-Karte gerade ihr Wear Leveling macht? Dann KANNST du multitasken wie du willst, du KANNST KEINE Daten absetzen. Also MUSST du per FIFO puffern oder Daten wegwerfen! Und dann nützt dir auch der beste Multitaskingansatz NICHTS! Welche Datenraten schreibst du auf die Karte?
Falk Brunner schrieb: > OK, eine extreme Variante von Multitasking. Ist das in ASM oder C > gemacht? Weil wenn es denn WIRKLICH SOO zeitkritisch ist, muss es ja > fast ASM sein. 100 Punkte! :-) Ist natürlich Assembler. In C wäre das zu umständlich, weil z.B. das SRAM komplett für den Puffer verwendet wird und deswegen als Stack nicht zur Verfügung steht. Unterprogrammaufrufe gibt es trotzdem, die Rücksprungadresse landet aber nicht im Stack, sondern in einem Rücksprung-Register (Makros ZCALL und ZRET; läuft übrigens schneller als normale RCALLs/RETs). Ich kann aber gut verstehen, wenn dir das zu kryptisch ist und du diese Tricks selbst nicht verwenden würdest. Mag ja nicht jeder. > Aber was machst du, wenn die SD-Karte gerade ihr Wear Leveling macht? > Dann KANNST du multitasken wie du willst, du KANNST KEINE Daten > absetzen. Also MUSST du per FIFO puffern oder Daten wegwerfen! Puffern (siehe oben). Und im Extremfall einen Datensatz wegwerfen. > Welche Datenraten schreibst du auf die Karte? Die Daten kommen spontan und schnell, aber immer nur in kleinen Portionen, so dass Verlust nicht zu erwarten ist. Die 512 Bytes Puffer reichen aus.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.