Forum: Mikrocontroller und Digitale Elektronik Datenlogger: SD oder CF?


von Jörg O. (joerchi)


Lesenswert?

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

von Tilo (Gast)


Lesenswert?

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.

von ea (Gast)


Lesenswert?

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.

von Martin (Gast)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Jörg O. (joerchi)


Lesenswert?

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

von Benedikt K. (benedikt)


Lesenswert?

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

von Martin (Gast)


Lesenswert?

<< ü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?? ;)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Martin schrieb:

> Schon mal an nen FPGA/CPLD gedacht mit IDE ansteuerung?? ;)

Kannste auch gleich einen kleinen PC nehmen dann...

von Martin (Gast)


Lesenswert?

<< Kannste auch gleich einen kleinen PC nehmen dann... >>

Das ist doch schon sowas wie n eigener PC ;)

von Bernd (Gast)


Lesenswert?

...  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?

von Benedikt K. (benedikt)


Lesenswert?

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"

von ah (Gast)


Lesenswert?

Es gibt Speicherkarten, die haben die Schreibgeschwindigkeit angegeben. 
zB Sandisk Ultra und dergleichen.

von Jörg O. (joerchi)


Lesenswert?

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.

von holger (Gast)


Lesenswert?

>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.

von Martin (Gast)


Lesenswert?

An was für ein Controller hattest du eigentlich gedacht??
Du müsstest ja irgendwie ein paar sachen auf einmal erledigen..

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Benedikt K. (benedikt)


Lesenswert?

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.

von Uhu U. (uhu)


Lesenswert?

Benedikt, wenn ich deine Links anklicke, lande ich hier: 
http://www.pir.org/

Wie das?

von holger (Gast)


Lesenswert?

>Wenn ich deine Links anklicke, lande ich hier: http://www.pir.org/
>Wie das?

Hatte ich zuerst auch. Scheint nur temporär aufzutreten.

von Uhu U. (uhu)


Lesenswert?

Hier ist es sehr konstant.

von holger (Gast)


Lesenswert?

Geh mal mal hier drüber rein:

http://elm-chan.org/fsw/ff/00index_e.html

Links ganz unten Benchmark1/2.

von Benedikt K. (benedikt)


Lesenswert?

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.

von Uhu U. (uhu)


Lesenswert?

Danke, so klappts.

von holger (Gast)


Angehängte Dateien:

Lesenswert?

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 ;)

von Martin T. (mthomas) (Moderator) Benutzerseite


Lesenswert?

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.

von ah (Gast)


Lesenswert?

Das Wear Leveling kann man wahrscheinlich deaktivieren indem man das 
maximal grosse File an einem Stueck schreibt und das Directory nachher.

von Benedikt K. (benedikt)


Lesenswert?

Das geht leider nicht, denn Travel Rec verwendet kein Dateisystem und 
hat trotzdem die Pausen beim Schreiben:
Beitrag "SD-Karten-Wave-Recorder"

von Uhu U. (uhu)


Lesenswert?

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.

von ah (Gast)


Lesenswert?

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.

von holger (Gast)


Lesenswert?

>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 ;)

von Benedikt K. (benedikt)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

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

von Wolfgang Mües (Gast)


Lesenswert?

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

von Jörg O. (joerchi)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von RAY (Gast)


Lesenswert?

BTW: was für ein Fahrzeug ist das, dass da gleich vier schnelle 
CAN-Busse werkeln?

von Jörg O. (joerchi)


Lesenswert?

> 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.

von RAY (Gast)


Lesenswert?

>> 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

von Jörg O. (joerchi)


Lesenswert?

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.

von Jörg O. (joerchi)


Lesenswert?

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

von peterguy (Gast)


Lesenswert?

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

von Jörg O. (joerchi)


Lesenswert?

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

von Tobias M. (mhad-ngad)


Lesenswert?

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

von Jörg O. (joerchi)


Lesenswert?

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

von Tobias M. (mhad-ngad)


Lesenswert?

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

von Jörg O. (joerchi)


Lesenswert?

> 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

von Pacer (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von holger (Gast)


Lesenswert?

>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
Noch kein Account? Hier anmelden.