Hallo, ich habe derzeit ein Projekt laufen, bei dem es um einen Datenlogger für vier CAN-Kanäle handelt. Der Logger soll in der Lage sein, alle vier Kanäle á 1Mbit/s gleichzeitig zu loggen. Als Speichermedium stehen zur Auswahl: SD-Karte oder CompactFlash-Karte Nun habe ich die Befürchtung, dass ich mit der SD-Karte im lizensfreien Modus (SPI-Mode) von den Schreibgeschwindigkeiten her zu langsam bin. Mal ein kleines Rechenspeispiel: (worst case) 1 Kanal 1000kbits/s - mit Standard-Frame pro Message sind das 111 Bits (130 Bits - 19 mögl. Stuffing Bits) effektive Übertragungsrate pro Kanal: (64 Nutzbits)/(111 Bits pro Message) * 1000 = 577 kBit/s bei vier Kanälen wären das ~ 2,3MBit/s Nun meine Frage, an die Leute, die schon mit einer SD-Karte gearbeitet haben: Kann ich dieses Vorhaben mit einer SD so umsetzen? Oder sollte ich doch lieber zur CF greifen? Vielen Dank schonmal, Jörg
Das hängt von dem SPI-Master ab. Afaik gehen die SD-Cards bis 40MHz, das sollte dann schon ausreichen. Die Frage ist nur, ob der SPI-Master das auch schafft.
nimm lieber eine CF Karte. Du kannst 8 Bits parallel schreiben, und schneller sie auch. Alternativ (wenn Du statt 1 Jahr nur ein paar Sekunden loggen willst) - ein großer RAM.
falls dir so max 16-32MB reichen würden kannst es mit nem FRAM oder SRAM probieren... ich wär für FRAM :) die Teile haben richtig Speed, ist halt nur die Frage ob dein Controller dann auch den Speed schafft XD
Tilo Lutz schrieb: > Das hängt von dem SPI-Master ab. Afaik gehen die SD-Cards bis 40MHz, das > sollte dann schon ausreichen. Die Frage ist nur, ob der SPI-Master das > auch schafft. Das Hauptproblem dürfte doch bei beiden nicht das Interface sein, sondern die Schreibgeschwindigkeit in den Flash an sich. Da gehen schnell einige 10 ms ins Land für einen Block, und irgendwo schrieb mal jemand, das man insbesonderen für den Fall, dass der eingebaute Controller ein "wear-levelling" anwirft, plötzlich mal ziemlich lange dauern kann, bis er mit einem Block fertig ist. Leider findet man kaum Angaben darüber bei den Herstellern. Daher wirst du vermutlich kaum um eigene Versuche herum kommen (und möglicherweise für das wear-levelling auch noch eine alte Karte nehmen müssen, die schon einige Schreibzyklen hinter sich hat). Da SD-Flash technologisch jünger als CF ist, würde ich dort die moderneren Speicher-ICs dahinter vermuten.
Vielen Dank erstmal. Die Hauptaufgabe des Loggers soll doch eher sein, über einen längeren Zeitraum (Tage/Nächte) mitzuloggen. Was mich bei der SD-Karte stört. Theoretisch können sie bis zu 20MB/s, aber hier im Forum haben nun schon so einige ihre Erfahrungen berichtet und in den bestreffenden Beispielen sind nur margere Datenraten von bis zu 100kB/s herausgekommen. In diesen Beispielen konnten sie den SPI-Clock auch nur bis zu 15 MHz laufen lassen, sodass SPI noch stabil lief. Mein Controller steht noch nicht fest, da der Logger auch noch so manch andere Sachen nebenbei machen soll, aber es wird auf jeden ein Mindesttakt von 40MHz verwendet. Daher sollte der Controller das schon schaffen. Viele Grüße Jörg
Das wear Leveling ist eindeutig das Problem, aber das wirst du bei jedem Flash basierten Speichermedium haben (USB Stick usw.). SD Karten benötigen durchaus mal 500ms dafür, bei deinen 2,3MBit/s musst du also mindestens 256kByte Zwischenspeicher vorsehen, damit es mit den üblichen SD Karten funktioniert. Der nächste Punkt ist natürlich noch, wie schnell der µC ist, bzw. wie intelligent das Dateisystem, denn die Suche nach einem freien Sektor kann auch einiges an Zeit beanspruchen, falls das Dateisystem fragmentiert wird. Hier mal noch ein paar Werte zum Vergleich der Geschwindigkeiten: http://elm-chan.org/fsw/ff/img/rwtest.png http://elm-chan.org/fsw/ff/00index_e.html
<< über einen längeren Zeitraum (Tage/Nächte) mitzuloggen. >> Ahem, reicht da eine Chip-Karte überhaubt aus?? du hast 3mbit das sind ca. ~307kbyte/s das sind in einer minute dann ca. ~18432kbyte da reicht dir glaub keine "kleine" Chip-Karte wenn du 1-2 Tage mit Loggen willst Schon mal an nen FPGA/CPLD gedacht mit IDE ansteuerung?? ;)
Martin schrieb:
> Schon mal an nen FPGA/CPLD gedacht mit IDE ansteuerung?? ;)
Kannste auch gleich einen kleinen PC nehmen dann...
<< Kannste auch gleich einen kleinen PC nehmen dann... >> Das ist doch schon sowas wie n eigener PC ;)
... SD Karten benötigen durchaus mal 500ms dafür ... Unter welchen Bedingungen treten die 500 ms auf? Hast du einen Link zu einem Hersteller wo dies näher beschrieben ist?
Bernd schrieb: > Unter welchen Bedingungen treten die 500 ms auf? Wenn man konstant Daten an die SD Karte sendet. Das Schreiben eines Sektors dauert üblicherweise einige Millisekunden bis ein paar 10ms. Ab und zu werden dann aber ein paar 100ms daraus. > Hast du einen Link zu > einem Hersteller wo dies näher beschrieben ist? Leider nicht. Das war mir nur mal aufgefallen als ich den CS Pin beobachtet habe. Es tritt nicht bei jeder SD Karte auf, man kann auch nicht sagen das ein bestimmter Hersteller dieses Problem hat, sondern man muss einfach mal ein paar Karten in der Richtung testen. Hier haben auch andere das Problem: Beitrag "Re: SD-Karten-Wave-Recorder"
Es gibt Speicherkarten, die haben die Schreibgeschwindigkeit angegeben. zB Sandisk Ultra und dergleichen.
Benedikt K. schrieb: > Der nächste Punkt ist natürlich noch, wie schnell der µC ist, bzw. wie > intelligent das Dateisystem, denn die Suche nach einem freien Sektor > kann auch einiges an Zeit beanspruchen, falls das Dateisystem > fragmentiert wird. Über das Dateisystem habe ich mir noch gar keine Gedanken gemacht. Aber es wird eines zum Einsatz kommen müssen, da die geloggten Daten gleich in Trace-Files abgelegt werden sollen. > Ahem, reicht da eine Chip-Karte überhaubt aus?? > du hast 3mbit das sind ca. ~307kbyte/s das sind in einer minute dann ca. > ~18432kbyte da reicht dir glaub keine "kleine" Chip-Karte wenn du 1-2 > Tage mit Loggen willst Der Preis und die Größe der Speicherkarte spielt keine Rolle, somit kommt auch eine 32GB Karte in Frage. Womit aber dann auch nur max. 30 Stunden geloggt werden können. Aber da erstens das System nur erstmal für 4 * 1MBit/s ausgelegt werden soll, aber bisher im PKW nur 500kbit/s üblich sind, würde dies die möglich Zeit zum loggen schon einmal verdoppeln und zweitens in der Nacht, wenn der PKW steht, ja sämtliche Systeme im Sleep-Mode sind, der Datenstrom auch recht gering bleibt. > Schon mal an nen FPGA/CPLD gedacht mit IDE ansteuerung?? ;) Nein, wäre aber eine Alternative. > Es gibt Speicherkarten, die haben die Schreibgeschwindigkeit angegeben. > zB Sandisk Ultra und dergleichen. Ja, das meinte ich in meinem ersten Beitrag. Diese Angaben sind aber leider meist nur unter optimalen Bedingungen und im SD-Mode (4bit parallel) zu erreichen. Meist sind es auch nur reine Marketinggags.
>Es gibt Speicherkarten, die haben die Schreibgeschwindigkeit angegeben.
Das sind mittlere Schreibgeschwindigkeiten.
Die Pausen treten bei allen meinen SD/MMC Karten auf.
Bei einigen häufiger bei anderen weniger häufig.
Und leider oft unvorhersehbar. Ohne größeren
RAM Puffer seh ich da keine Chance.
An was für ein Controller hattest du eigentlich gedacht?? Du müsstest ja irgendwie ein paar sachen auf einmal erledigen..
Jörg Oe schrieb: > Ja, das meinte ich in meinem ersten Beitrag. Diese Angaben sind aber > leider meist nur unter optimalen Bedingungen und im SD-Mode (4bit > parallel) > zu erreichen. Ich denke, dass die eigentlichen Schreibzeiten dich insgesamt viel mehr ausbremsen als die Art des benutzten Interfaces. Das hat eher einen Einfluss darauf, wie schnell man die Daten gelesen bekommt. > Meist sind es auch nur reine Marketinggags. Naja, selbst wenn man dir eine mittlere Schreibzeit angibt, weißt du halt immer noch nicht, wie lange sie zwischenzeitlich maximal sein kann.
Jörg Wunsch schrieb: > Ich denke, dass die eigentlichen Schreibzeiten dich insgesamt viel > mehr ausbremsen als die Art des benutzten Interfaces. Das hat eher > einen Einfluss darauf, wie schnell man die Daten gelesen bekommt. Kann man so nicht sagen, schau dir mal diese Grafiken an: http://elm-chan.org/fsw/ff/img/rwtest.png http://elm-chan.org/fsw/ff/img/rwtest2.png Man sieht einen deutlichen Unterschied zwischen CF und SD, sowie zwischen SD über SPI oder 4bit. Das ist auch meine Erfahrung, denn zu den Schreibzeiten kommen noch die Übertragungszeiten dazu. Bei Datenraten von ein paar 100kByte/s merkt man schon deutlich ob SPI mit 15MHz oder 8MHz läuft, sowohl beim Schreiben als auch beim Lesen.
>Wenn ich deine Links anklicke, lande ich hier: http://www.pir.org/ >Wie das? Hatte ich zuerst auch. Scheint nur temporär aufzutreten.
Geh mal mal hier drüber rein: http://elm-chan.org/fsw/ff/00index_e.html Links ganz unten Benchmark1/2.
ELM-chan hat eine sehr gute Sicherung auf seiner Seite die wirkungsvoll verhindert, dass man seine Sachen klaut. Weiter oben habe ich daher auch den Link auf die Hauptseite gepostet. Es reicht anscheinend wenn man einmal auf der Seite war, um auch die Bilder einzeln betrachten zu können.
Hier mal ein paar Logdateien (Text) zu ELM-Chan (V0.60). Nur MMC und SD Karten. Keine CF. uC ARM7 LPC2138, CPU 60MHz, SPI1 mit 15MHz. Hab ich letztes Jahr mal ein bisserl mit rumgespielt. Die langsamste Karte minisd64_nokia.log. Die schnellste Karte mmc256_extrememory.log. Da kann man sehr schön sehen das die Geschwindigkeit vom Interface (SPI) manchmal kaum eine Rolle spielt. Was noch ein bißchen was bringt ist der MultiBlock Mode. Gemessen unter idealen Bedingungen. Der RAM Puffer ist bereits fertig zum versenden. Wenn die Daten erst noch gesammelt werden müssen, dann kann man da wohl noch einen ordentlichen Einbruch in der Übertragungsrate erwarten. Die unterschiedlichen Übertragungsraten kommen von diesen netten kleinen Pausen die MMC/SD gerne mal einlegen ;)
Benedikt K. schrieb: > Bernd schrieb: > >> Unter welchen Bedingungen treten die 500 ms auf? > > Wenn man konstant Daten an die SD Karte sendet. Das Schreiben eines > Sektors dauert üblicherweise einige Millisekunden bis ein paar 10ms. > Ab und zu werden dann aber ein paar 100ms daraus. SanDisk SD Card Product Manual Version 2.2 (November 2004) gibt für Block Read Access Time: typical 0,5ms, max. 100ms und Block Write Access Time: typical 0,5ms, max. 250ms. Genaue "Bedingungen" wann man mit welcher Zeit zu rechnen hat, werden nicht genannt. Dies hängt wohl von der wear-leveling-Strategie des Controllers und internen Zwischenpuffern in der Karte ab. Bei eigenen - oberflächlichen - Messungen mit verschiedenen Karten keinen gemeinsamen Nenner gefunden, außer dass, wie von Benedikt K. schon beschreiben, ein Block write nach mehr oder weniger vielen "schnell" geschriebenen Blöcken irgendwann >100ms dauert. Bei einer meiner Karten passiert dies einmal, wenn vorher schon gut 1MByte zur Karte übertragen wurde, wann dann nochmals habe ich nicht gemessen. Bei keiner der Karten hier folgte auf eine Verzögerung unmittelbar eine weitere. >> Hast du einen Link zu >> einem Hersteller wo dies näher beschrieben ist? > > Leider nicht. Das war mir nur mal aufgefallen als ich den CS Pin > beobachtet habe. Es tritt nicht bei jeder SD Karte auf, man kann auch > nicht sagen das ein bestimmter Hersteller dieses Problem hat, sondern > man muss einfach mal ein paar Karten in der Richtung testen. > Hier haben auch andere das Problem: > Beitrag "Re: SD-Karten-Wave-Recorder" Hatte bei einem Hersteller mal angefragt, wie viele Blöcke mindestens schnell geschrieben werden, bevor die Karte reorganisiert und dabei mit einer Verzögerung zu rechnen ist und ob dies vorher errechnet werden kann. Die Antwort war nicht viel mehr als ein "kommt drauf an". Um wear-leveling/Speicherreorganistation wird ein großes Geheimnis gemacht. Selbst wenn man die Grundlagen irgendwo findet, gibt es noch viele Optimierungsmöglichkeiten, bei denen Controller- und Kartenhersteller sich scheinbar nicht in die Karten schauen lassen.
Das Wear Leveling kann man wahrscheinlich deaktivieren indem man das maximal grosse File an einem Stueck schreibt und das Directory nachher.
Das geht leider nicht, denn Travel Rec verwendet kein Dateisystem und hat trotzdem die Pausen beim Schreiben: Beitrag "SD-Karten-Wave-Recorder"
ah schrieb: > Das Wear Leveling kann man wahrscheinlich deaktivieren indem man das > maximal grosse File an einem Stueck schreibt und das Directory nachher. Die Chipkarte weiß nicht, was ein File ist, deswegen kann das nicht sein.
Nee. Das Wear Leveing fliegt von selbst raus wenn man selbst jeden sektor nur einmal pro vorgang schreibt. Also nicht nach ein paar sektoren das directory updaten.
>Das Wear Leveling kann man wahrscheinlich deaktivieren indem man das >maximal grosse File an einem Stueck schreibt und das Directory nachher. Entscheidend für Wear Leveling ist wie oft ein Block beschrieben wurde. Mit Dateisystem sind die FAT und Directory Blöcke je nach Software mehr oder weniger stark betroffen wenn dort keine Puffer verwendet werden. Mit Puffern hat man ein Problem bei Stromausfall. Man kann machen was man will, irgendwie hat man immer die Arschkarte gezogen ;)
ah schrieb: > Nee. Das Wear Leveing fliegt von selbst raus wenn man selbst jeden > sektor nur einmal pro vorgang schreibt. Nein, eben nicht, lies mal was ich ein paar Beiträge weiter oben geschrieben habe.
Solche billigen Tricks würde ich mir im Zeitalter der 32Bit uCs und fetter SDRAMs schenken. SD-Karte ganz normal nutzen, mit FAT32, einen ordentlichen FIFO in Software davorpacken, sinnvolle Blockgrössen schreiben (also nicht 16 Byte, eher 512 Byte und Vielfache)) und gut ist. Alles kompatibel, kein Gefrickel, passt. Das Ganze kann man sicher recht einfach auf einem der vielen fertigen 32Bit uC Evalboards recht fix zum Laufen kriegen. Hier würde ich amerikanisch denken wollen. THINK BIG! Mal so als Idee http://www.taskit.de/produkte/molux/index.htm MFG Falk
Ich habe einige Erfahrungen mit SD-Karten im SPI-Modus unter uCLinux, mit dem Blackfin BF 527. Die Datenraten beim Schreiben großer Dateien liegen so bei 750-1500 KByte/Sekunde, mit FAT-Dateisystem. SPI Clock war 20 MHz. Das Problem bei SPI ist, dass man sehr viel CPU-Last dafür braucht. Das Protokoll erfordert sehr viel einzelne, intelligente Aktionen. Es dürfte sehr viel einfacher sein, einen der heutzutage üblichen modernen Microcontroller mit SD/MMC-Interface zu verwenden. Da muss man sich dann auch nicht mit den ganzen Implementierungsfehlern des SPI-Modus auf der SD-Karte rumärgern. Viel Erfolg Wolfgang
Hallo Jungs, erst einmal vielen vielen Dank für die zahlreichen Antworten. Sorry, dass ich mich die letzten zwei Tage nicht mehr gemeldet habe, aber ich war leider unterwegs und hatte kein Internetzugang zur Verfügung. Ich habe jetzt aus euren Beiträgen entnehmen können, dass CompactFlash-Karten ansich schneller zu beschreiben sind. Es aber, so wie ihr das auch bei den SD-Karten beschrieben habt, zu recht langsamen Schreibzyklen kommen kann. Weiterhin ist eine gänzliche Einschränkung wie man mit dem wear-level des Flash umgeht. Ich würde dann doch eher zur CF-Karte greifen, die es mir von Haus aus schon ermöglicht, schneller auf den Flash zu schreiben. Viele Grüße Jörg
Benedikt K. schrieb: > Man sieht einen deutlichen Unterschied zwischen CF und SD, sowie > zwischen SD über SPI oder 4bit. Wo sieht man in den Bildern letzteres? Ich sehe da nur SD oder MMC, aber keinen Hinweis darauf, ob das 4-bit oder SPI war. Davon abgesehen, ich hatte mir über 4-bit auch schon mal Gedanken gemacht, da hat mich dann jemand drauf gebracht, dass das eigentlich nur Sinn hat, wenn der Controller das auch tatsächlich unterstützt. Wenn man sich die Bits in Software zusammenpusseln muss zu einem Byte, dann lohnt das gar nicht. Mein Fazit aus diesen Benchmarks ist aber, dass die exemplarabhängigen Unterschiede sehr viel mehr ausmachen als die des benutzten Interfaces. Wenn man also auf schnelles Schreiben aus ist, aber nur ein Einzel- exemplar braucht, sollte man sich wohl die Mühe machen, einige konkrete Karten selbst zu vergleichen.
BTW: was für ein Fahrzeug ist das, dass da gleich vier schnelle CAN-Busse werkeln?
> BTW: was für ein Fahrzeug ist das, dass da gleich vier schnelle > CAN-Busse werkeln? Der Datenlogger soll in der Fahrzeugerprobung eingesetzt werden. Bisher sind noch keine Systeme vorhanden, bei denen 4 CAN-Busse mit 1 Mbits/s gleichzeitig arbeiten. Es sollen lediglich 4 + 500 kBit/s CAN-Busser geloggt werden. Jedoch wenn ich den Logger jetzt schon mit ausreichend Performance versehen möchte, macht es auch Sinn, die Hardware gleich so abzustimmen, dass der worst-case abgedeckt werden kann. Der Logger soll ja über einen längeren Zeitraum genutzt werden können.
>> BTW: was für ein Fahrzeug ist das, dass da gleich vier schnelle >> CAN-Busse werkeln? > >Der Datenlogger soll in der Fahrzeugerprobung eingesetzt werden. Bisher >sind noch keine Systeme vorhanden, bei denen 4 CAN-Busse mit 1 Mbits/s >gleichzeitig arbeiten. Es sollen lediglich 4 + 500 kBit/s CAN-Busser >geloggt werden. Jedoch wenn ich den Logger jetzt schon mit ausreichend Danke, trotzdem nochmal nachhakend - vielleicht war die Frage missverständlich gestellt: ich dachte es gibt normal nur einen schnellen CAN-Bus für die Motorsteuerung etc und einen langsameren für die ganzen unkritschen Sachen z.B. Fensterheber etc. Wären zwei CAN-Busse, du willst aber gleich vier loggen - gut wenn das ein Forschungsfahrzeug ist, kann ich mir vorstellen, dass noch ein zusätzlicher Bus für Messzwecke reingebaut wird. Tschüss Ray
RAY schrieb: >>> BTW: was für ein Fahrzeug ist das, dass da gleich vier schnelle >>> CAN-Busse werkeln? >> >>Der Datenlogger soll in der Fahrzeugerprobung eingesetzt werden. Bisher >>sind noch keine Systeme vorhanden, bei denen 4 CAN-Busse mit 1 Mbits/s >>gleichzeitig arbeiten. Es sollen lediglich 4 + 500 kBit/s CAN-Busser >>geloggt werden. Jedoch wenn ich den Logger jetzt schon mit ausreichend > > Danke, trotzdem nochmal nachhakend - vielleicht war die Frage > missverständlich gestellt: ich dachte es gibt normal nur einen schnellen > CAN-Bus für die Motorsteuerung etc und einen langsameren für die ganzen > unkritschen Sachen z.B. Fensterheber etc. Wären zwei CAN-Busse, du > willst aber gleich vier loggen - gut wenn das ein Forschungsfahrzeug > ist, kann ich mir vorstellen, dass noch ein zusätzlicher Bus für > Messzwecke reingebaut wird. > > Tschüss > > Ray Nicht unbedingt. Es gibt da mittlerweile die unterschiedlichsten Konzepte. die von dir angesprochenen Fensterheber sind an einem LIN-Bus angeschlossen. In den meisten Türen werkeln LIN-Busse, die dann mittels Gateways auf den Komfort-CAN umgesetzt werden. Es gibt sogar einen eigenen CAN nur für die Airbags, aber das ist echt eine Konzeptfrage.
Ich habe nochmal eine Grundatzfrage: Bisher habe ich mitbekommen, dass es für die CF-Karte drei unterschiedliche Modes gibt: (laut Spec 2.0) - PC Card Memory Mode - PC Card I/O Mode - True IDE Mode Kann mir jemand ein Quelle sagen oder generell erklären, was der Unterschied dieser Modes ist und wozu diese im Detail verwendet werden? Ich möchte mich gern zu diesem Thema weiter einlesen. Die Spec verrät dazu auch nicht so viel. Ist die 2.0er Spec momentan die aktuellste, die frei verfügbar ist? Vielen Dank für eure Mithilfe. Viele Grüße Jörg
Hallo Jörg, vielleicht hilft Dir bei der Auswahl eines geeigneten Speichermediums folgende Information: Im Fahrzeugumfeld werden CAN Busse mit ca. 30% Auslastung geplant, durch spätere Modellpflegen oder Zusatzausstattungen kann die Auslastung dann auf ca. 50% ansteigen. Mehr ist mit CAN nicht sinnvoll umzusetzten, da es sich um ein eventgesteuertes System handelt. Im Fahrzeugeinsatz sind mir bisher keine Datenraten über 500kBit untergekommen. Und es wird nach meiner Einschätzung auch zukünftig keine CAN Busse mit 1MBit geben. Vielmehr tendieren die Hersteller im Moment dazu, für den Chassis Bus auf FlexRay zu wechseln. Wegen der hier gestellten Sinnfrage nach einem 4Kanal Logger: Es gibt deutlich mehr als 2 CAN Busse in aktuellen Oberklasse Fahrzeugen. Ich meine mich zu erinniern, daß z.B. Lexus sogar teilweise mit parallelen CAN Bussen arbeitet, um der Daten noch Herr zu werden. Wenns anders wäre würden die feinen Freescale µCs mit 5 CAN Modulen ja keinen Markt finden ;-) Ich persönlich würde ja zu USB-Sticks als Speichermedium tendieren, mit einem entsprechend potentem Embedded-Rechner im Hintergrund. Damit wäre das Ganze auch schön erweiterbar und mit Reserven für zukünftige Erweiterung ausgestattet... Denn wenn dein System gut ankommt, sind kundenspezifische Erweiterungswünsche so sicher wie das Amen in der Kirche. Was z.B. wenn ein Kunde kommt und auch noch FlexRay mitloggen möchte? Da kommen dann 10MBit auf Dich zu... :-) Gruß, Peter
Da hast du schon Recht, Ich habe mich jetzt allerdings ein das Speichermedium CompactFlash festgelegt, und so soll es auch werden. Was mir die Arbeit mit einer CF-Card enorm erleichtert ist das oftmals integrierte "EBI - External Bus Interface". Diese unterützt schon von Haus aus die Arbeit mit einer CF-Card. Was mir momentan noch Kopfzerbrechen bereitet, ist die Tatsache, wie ich diese vier CAN Kanäle realisiere. Denn die meisten Controller haben nur einen Controller onBoard. Stand-Alone Controller über SPI wären auch noch eine Möglichkeit. Viele Grüße Jörg
Hallo, grundsätzlich stimme ich peterguy zu. Es kann aber natürlich sein, dass er auch einen Mess-CAN-Bus mitloggen möchte auf dem die Sensordaten von zusätzlich installierter Sensorik rumlungern, das war zumindest bei uns gang und gäbe. Dann hat man durchaus Busse mit 1Mbit/s und hoher Auslastung. Auch wenn der Thread an dem Punkt schon längst vorbei ist, solltest Du bedenken, dass die 2,3Mbit/s die Du berechnet hast komplett ohne Overhead sind. Du musst die Daten ja auch zuordnen können und kannst sie nicht einfach hintereinander wegschreiben. Das heißt Du musst im schlimmsten Fall einen Timestamp ablegen, von welchem CAN-Bus der 4 Busse das kam und den Identifier. Deine effektiv benötige Schreibrate wird also noch wesentlich höher liegen. Die Dinger gibts fertig zu kaufen, wenn das also in der Forschung genutzt wird und das Projekt trägt die Kosten, spart Ihr Euch viel Zeit :) Gruß Tobias
Tobias M. schrieb: > Auch wenn der Thread an dem Punkt schon längst vorbei ist, solltest Du > bedenken, dass die 2,3Mbit/s die Du berechnet hast komplett ohne > Overhead sind. Du musst die Daten ja auch zuordnen können und kannst sie > nicht einfach hintereinander wegschreiben. Das heißt Du musst im > schlimmsten Fall einen Timestamp ablegen, von welchem CAN-Bus der 4 > Busse das kam und den Identifier. Deine effektiv benötige Schreibrate > wird also noch wesentlich höher liegen. Hallo Tobias, auch da hast du natürlich Recht. In diese Grobrechnung sind erstmal nur die reinen Daten berücksichtigt, um erstmal eine Tendenz zu erhalten und um vorab schonmal eine Speichermedium ausschließen zu können. Du hast das Thema der Zuordung der einzelnen Messages vollkommen richtig aufgegriffen. Es soll sogar ein Timestamp verwendet werden, der dann später bei der Auswertung die zeitliche Zuordnung wieder möglich macht. Genau damit beschäftige ich mich gerade, wie ich das am sinnvollsten lösen kann. > Die Dinger gibts fertig zu kaufen, wenn das also in der Forschung > genutzt wird und das Projekt trägt die Kosten, spart Ihr Euch viel Zeit > :) Ich glaube ich muss dazu eines noch ergänzen: Bei diesem Projekt handelt es sich um meine Diplomarbeit, von daher ist ein System kaufen ausgeschlossen. Viele Grüße Jörg
Jörg Oe schrieb: > Ich glaube ich muss dazu eines noch ergänzen: Bei diesem Projekt handelt > es sich um meine Diplomarbeit, von daher ist ein System kaufen > ausgeschlossen. Na das muss einem ja auch gesagt werden :) Hast Du mal dran gedacht mehrere µC's zu benutzen und das System modular aufzubauen? Das einzige Hässliche ist dann der Zugriff auf das Speichermedium und die Kosten. Ansonsten kann ich den MCP2515 von Microchip empfehlen. Das ist ein Standalone-CAN-Controller, den man per SPI an den µC anschließt. Der nimmt einem recht viel Arbeit ab, wenn man ihn per SPI konfiguriert hat und schiebt dann die empfangenen Daten per SPI in den µC. Dadurch nimmst Du im Zweifelsfall dem µC auch etwas Rechenlast. http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010406 Gruß Tobias
> Na das muss einem ja auch gesagt werden :) > Hast Du mal dran gedacht mehrere µC's zu benutzen und das System modular > aufzubauen? Das einzige Hässliche ist dann der Zugriff auf das > Speichermedium und die Kosten. Genau an das habe ich auch schon gedacht. Das System könnte sozusagen aus einer Mutter- und einer Tochterplatine bestehen. Da kommt aber wieder die Controllerauswahl ins Spiel. Entweder hat jeder Controller gleich zwei CAN-Controller on-Chip, oder ich muss jeweils einen Kanal mit einem externen Stand-Alone Controller versehen. Diese würden dann über SPI kommunizieren. > Ansonsten kann ich den MCP2515 von Microchip empfehlen. Das ist ein > Standalone-CAN-Controller, den man per SPI an den µC anschließt. Der > nimmt einem recht viel Arbeit ab, wenn man ihn per SPI konfiguriert hat > und schiebt dann die empfangenen Daten per SPI in den µC. Dadurch nimmst > Du im Zweifelsfall dem µC auch etwas Rechenlast. Den MCP kenne ich bereits und würde auch zu ihm greifen. Dann stellt sich nur die Frage, wie die beiden µC miteinander sprechen. Generell ginge das auch per SPI. Oder mannimmt eine zweite CFC, doch dann wirds schwierig einen globalen timestamp zu verwenden. Bin mir da selbst noch nicht so sicher, wie ich das umsetzen soll. Gru, Jörg
So, ich habe mal wieder eine Frage zu dem Thema: Da ich gerade dabei bin, ob ich in dem System eine oder doch zwei Speicherkarten verwenden soll, stellt sich mir noch eine Frage. Da auf den CFCs als Dateisystem FAT32 verwendet werden soll, bin ich gerade überfragt, wie hoch meine effektive Datenrate wirklich sein kann. Einen groben Überblick über den Aufbau und die Funktionsweise von FAT32 habe ich mir in letzten Tagen angelesen, aber zum Thema prozentualer Overhead konnte ich noch keine Angaben finden. In meinem Fall soll davon ausgegangen werden, dass die CFC mit FAT32 bereits formatiert ist und es auch nur eine Datei durchgehend geschrieben werden soll. Kann jemand dazu eine grobe Angabe machen? Vielen Dank schonmal.
Pacer schrieb: > In meinem Fall soll davon ausgegangen werden, dass die CFC mit FAT32 > bereits formatiert ist und es auch nur eine Datei durchgehend > geschrieben werden soll. Dann hast du praktisch keinerlei Overhead vom Dateisystem. Das Einzige, was davon noch verbleibt, ist das gelegentliche Hinzufügen eines Bits in die FAT (für jeden neuen Cluster, der angefangen werden muss) sowie das Aktualisieren der Länge im Verzeichnis. Allerdings müsstest du dir dann überlegen, wie du mit einem Medium umgehen willst, das dir einer unterschiebt, das aber nicht dieser Konvention (nur eine einzelne Datei im root-Verzeichnis) genügt.
>Dann hast du praktisch keinerlei Overhead vom Dateisystem. Das >Einzige, was davon noch verbleibt, ist das gelegentliche Hinzufügen >eines Bits in die FAT (für jeden neuen Cluster, der angefangen >werden muss) sowie das Aktualisieren der Länge im Verzeichnis. Wenn man eine Datei mit vorgegebener Größe auf den CF packt, spart man sich auch diese Zeiten. Alle Cluster und die Dateilänge sind dann schon eingetragen.
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.