Daten mit hoher Frequenz speichern! Aber wohin?

Allenfalls ein externes Datenflash. Zb ein AT45DB321 oder so.

>also ich lese 4 Digitale Ports am AVR und möchte diese nach einer
>kleinen Rechnung speichern. Dieses sollte möglicht mit einer frequenz
>bis zu max. 10 khz funktionieren und min. 1 kHz.
>Der RAM genügt nicht; EEPROM zu langsam;
>Is dafür der Flash geeignet ???

Nein. Nimm einen ATMega128 und papp da externes RAM dran.
Oder fang mal mit ARM an.

Bei begrenzten Datenmengen: FRAM über I2C oder SPI.

Oder SPI FRAM, da EEPROM nur begrezt oft beschrieben werden kann, oder 
wie  schon gesagt einen SPI FLash als Ringspeicher. Letztendlich kommt 
es drauf an, wieviel Daten gespeichert werden müssen

Das wären für eine 10 min  rund 90 MByte!!

Man könnte die Datenmenge noch runtersezten wenn man Mitteln würde dann 
würden aber immer noch rund 500kByte

Also das mit der SD-Karte klingt ja ganz gut, aber wie schnell kan ich 
diese beschreiben?? Kann ich die SD-Karte alle 100 ms beschreiben?

Und wie lange dauert der Schreibvorgang be einer SD-Karte von 512 Bytes 
über SPI?

>Man könnte die Datenmenge noch runtersezten wenn man Mitteln würde dann
>würden aber immer noch rund 500kByte

Passt doch. 512kB SRAM Banked an das external Memory Interface.

>Und wie lange dauert der Schreibvorgang be einer SD-Karte von 512 Bytes
>über SPI?

Inklusive sporadischem Wear Levelling länger als dir lieb ist.

Und wie sieht es mit I2C aus?

Damit kannst du nicht auf ne SD-Karte schreiben. Und wenn nicht SD, ist 
SPI genauso im Rennen.
Irgendwo hatte ich mal ein Projekt gesehen, dass PC-Ramriegel an einen 
AVR geklemmt hatte... An mögliche Kapazitäten oder wo das war kann ich 
mich leider gerade nicht erinnern.

Vielleicht wäre das wieder mal ne Anwendung für das beliebte WOM?

What are this?
Google liefert nur bullshit!

http://www.national.com/rap/files/datasheet.pdf

Ja das war mal nen Witz! :-)

Eine SD Karte ist in einer Knipse drin. die macht zB 4MByte Bilder. Und 
davon kann man mehrere hintereinander schnell wegspeichern. Die besten 
haben Transferraten von 20-30MByte pro Sekunde. Dazu benoetigt man dann 
aber schon einen 32bit controller.

Also ich will:
4 Sensoren lesen am Digitalen Port
Eine kleine Rechnung durchführen und die Daten Speichern und dass 
möglichst mit einer Frequenz von 10Khz.
Und mein Problem ist: Worauf soll/kann ich 16 Byte speichern, die alle 
100µs anfallen! Dabei sollte mein Schreibvorgang logischerweise 
schneller sein !


Gruß
GoldenEyes

160kByte/s ist doch kein problem für ne SD Karte. Aber du mußt natürlich 
die Pagegöße des Flash beachten und die Daten Puffern. Wärend du dann 
die Daten aus Puffer 1 zur SD Karte Schickst schreibst du neu ankommende 
Daten in Puffer 2. Wenn Puffer 1 geleert wurde schreibst kannst du ihn 
wieder mit neuen Daten Füllen und in der Zeit Puffer 2 zur SD Karte 
schicken. Natürlich alles per Interupt und mit Timern. DMA könnte man 
auch machen oder nen Ringpuffer.

Die SD Karten haben auch nen Controller drin und Puffern Die Pages vorm 
Schreiben. Wie Groß der Puffer ist weiß ich auch nicht habe ich mich 
noch nicht mit beschäftigt. Es gibt ja glaube ich auch SD Karten mit 
unglaublichen Schreibgeschwindigkeiten jenseits von 30MByte/s. Da sollte 
es auch ungepuffert keine probleme geben.

Uwe schrieb:
> 160kByte/s ist doch kein problem für ne SD Karte.

sie wird hier aber vemutlich nur über SPI gesteuert, als jedes bit 
einzeln.

Kurzum,
er braucht einen 32 Bit Controller mit ordentlicher RAM-Ausstattung, um 
die kontinuierlich anfallenden Daten in einem ordentlich großen 
Ringpuffer im RAM zwischenzuspeichern (nach meinem Gefühl sollte man 
dazu wenigstens 64K haben, notfalls extern ein halbes Megabyte, zB. 
256Kx16, also Controller mit herausgeführtem Bus) und er braucht einen 
Controller mit einem dedizierten 4 Bit breitem SD-Kartenanschluß. Das 
ist alles mehr, als man mit einem Atmel AVR zur Verfügung hat.

Mein Tip: Such bei Ebay nach einem fernöstlichen ARM- bzw. Cortex- 
Entwicklungsboard, da ist oftmals auch noch ein TFT-Display mit drauf, 
ADC's sind mit an Board und teuer sind die auch nicht.

W.S.

Uwe schrieb:
> Da sollte
> es auch ungepuffert keine probleme geben.

Bei einem kontinuierlichen Datenanfall ist Puffern sinnlos und kostet 
bloss noch mehr Zeit. Es sei denn, der Puffer ist gross genug für die 
längstmögliche Messzeit, aber dann besteht kein Grund mehr, die Daten 
noch irgendwohin weiterzuschieben.

Gruss Reinhard

> Bei einem kontinuierlichen Datenanfall ist Puffern sinnlos
Wenn die SD Karte zwar Schnell genug ist aber nicht kontinuierlich Daten
entgegennehmen kann muß man Puffern. Oder wie jetzt ?

Uwe schrieb:
> Wenn die SD Karte zwar Schnell genug ist aber nicht kontinuierlich Daten
> entgegennehmen kann muß man Puffern. Oder wie jetzt ?

Also das ist mal ein Wortspiel!
Der Puffer dient doch dazu, das wenn mehr Daten anfallen als man schnell 
schreiben kann diese dort zwischenspeichert! Das bedeutet wenn meine SD 
Karte schnell genug ist, muss ich nicht Puffern!

goldeneyes1987 schrieb:
> Das bedeutet wenn meine SD
> Karte schnell genug ist, muss ich nicht Puffern!

oder man sollte so lange puffern bis eine Page der SD karte voll ist, 
damit ist das schreiben schneller.

W.S. schrieb:
> Kurzum,
> er braucht einen 32 Bit Controller mit ordentlicher RAM-Ausstattung,

Das sehe ich auch so. Es wurden ja viele Zahlen genannt; ausgehend von 
160kB/s sehe ich nicht, wie ein ATmega diese zunächst errechnen und dann 
noch speichern soll.

FT232 chip dran und darüber die Daten per USB an ein Laptop/PC

Klaus De lisson schrieb:
> Ich finde es etwas konfus.

Ja, das sind auch 2 Paar Schuhe: Block Devices, das sind viele Speicher, 
die wie eine Festplatte in Blöcken organisiert sind, sollten auch 
blockweise angesprochen werden, auch wenn die Software was anderes 
zulässt. Das ist aber eher Blocking/Deblocking als Pufferung und wird 
auch in der Regel vom Betriebssystem übernommen, wenn vorhanden - es ist 
unter Windows nicht sinnvoll, sich um die Sektorgrösse der Festplatte zu 
kümmern, und so ohne weiteres weiss man sie auch garnicht.

Im vorliegenden Fall kann das aber wichtig sein, weil es sich bei diesem 
Teil der Software ja praktisch um einen Device Treiber handelt. Dann 
muss man aber sicher sein, wie gross ein Block ist und auch, dass man 
genau einen Block schreibt. Es ist ja bekannt, dass man moderne 
Festplatten mit 4k-Sektoren stark bremst, wenn die Partitionen nicht an 
den 4k-Grenzen ausgerichtet sind.

Eine Pufferung von Daten, um sie später zu verarbeiten, ist bei 
konstantem Datenfluss aber eher schädlich, weil es ein später nicht 
gibt, und das Puffern kostet auch Rechenzeit, also sollte man bei 
Speichern, die Byte für Byte speichern (z.B. RAM), die Daten auch direkt 
schreiben wie sie anfallen.

Eine noch mal andere Frage ist es, ob das Speichern den Empfang zu lange 
blockiert, so dass Zeichen verloren gehen, dann braucht man 2 oder einen 
2stufigen Blockpuffer oder eine funktionierende Interrupt-Lösung.

Gruss Reinhard

Klaus De lisson schrieb:
> Da kam es mir so vor als wäre ein Seitenweises Schreiben sinvoll.
> Vielleicht ist auch nicht so.
>
> Ich glaube ich muss, wie so immer , mal wieder darüber nachdenken,
> ob dass was ich meine zu wissen auch wirklich stimmt.

Das schadet bestimmt nicht, aber eigentlich genügt auch genaues Lesen: 
ich habe geschrieben "Block Devices ... sollten auch blockweise 
angesprochen werden", das ist so ziemlich das was du auch denkst. 
Allerdings muss das dann auch stimmen, denn wenn sich die zu 
schreibenden Blöcke nicht mit der Einteilung des Speichers decken, 
erreicht man das glatte Gegenteil.

So gesehen gehört die Blockverwaltung zum Treiber der Speicherkarte und 
nicht zur Datenerfassung.

Gruss Reinhard

Martin Schwaikert schrieb:
> Was spricht denn gegen einen D-Ram-Controller und genug Speicher dran?

Dass bei Stromausfall die Daten futsch sind - ich benutze aber seit 
Jahrzehnten statische RAMs mit einer Lithium-Batterie oder einem Akku, 
bis zu ein paar MByte ist das garkein Problem und man braucht keine 
spezielle Software dazu, ist eben RAM im Speicherbereich des Prozessors 
- höchstens eine Seitenumschaltung, wenn der Adressraum zu klein ist.

Gruss Reinhard

Klaus De lisson schrieb:
> Sram ist doch Static Ram oder nicht ?

ja