Hallo, 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 ??? Für eure Antworten bedanke ich mich im voraus! MfG GoldenEyes
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.
holger schrieb: > ATMega128 Oder einen ATMega162, die gibt's auch in DIL40. Aber mit 1 - 10 kHz auf den Flash schreiben... Der ist schneller kaputt, als Du "Staubsaugervertreter" sagen kannst (hält 1000 - 10000 Mal).
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
goldeneyes1987 schrieb: > 90 MByte!! Äh - hust - ich kenne keinen AVR, der mehr als 256KB Flash hat, geschweigedenn mehr als 64KB SRAM handhaben kann. Wenn Du einfach nur Daten schaufeln musst und Du diese nur selten wieder löschen musst - nimm 'ne SD-Karte.
Man könnte die Datenmenge noch runtersezten wenn man Mitteln würde dann würden aber immer noch rund 500kByte
goldeneyes1987 schrieb: > Das wären für eine 10 min rund 90 MByte!! da reicht ein avr kaum...was hast du denn genau vor, evlt kann man den algorithmus iterativ darstellen und braucht die neuen daten nur zu gewichten.. ansonsten einen ARM oder blackfin DSP mit richtig power und externem DDR Ram..
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?
goldeneyes1987 schrieb: > alle 100 ms beschreiben? Du meinst, mit einem Byte? Eigentlich schon, Du musst nur immer erst 512 Bytes vor jedem Schreibvorgang sammeln. Über 10 Bytes pro Sekunde lacht sich so eine SD-Karte doch tot...
Und wie lange dauert der Schreibvorgang be einer SD-Karte von 512 Bytes über SPI?
Vielleicht 10 bis 20 Millisekunden.
>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.
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?
goldeneyes1987 schrieb: > Ja das war mal nen Witz! :-) Meinst du das WOM ? Für deine Anwendung wäre ja vielleicht ein SRAM interessant. Die gibt es fast beliebig schnell und können als CacheRam fungieren. Klaus
Die SD-Karte wurde hier schon mehrfach genannt und klingt für Dein Projekt nach der passendsten Lösung... Mit ein wenig Mehraufwand kannst die gleich PC-kompatibel (aka FAT) beschreiben und hast damit auch gleiche eine bequeme Möglichkeit um die Daten aus Deinem Messaufbau rauszukriegen. Einfacher geht's nicht!
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.
goldeneyes1987 schrieb: > 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. Ich hätte da noch ein paar grundlegende Fragen: WOHER kommen die Daten? WIE schnell ändern die sich? Wenn das sowas wie ein Datenlogger ist, warum speicherst du dann nicht nur, wenn sich die Daten ÄNDERN? Kannst du die Information von 4 Byte auf z.B. 1 Byte REDUZIEREN? Kurz: WAS willst du denn überhaupt machen?
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
goldeneyes1987 schrieb: > 16 Byte alle 100 µs 16 Byte * (1 : 100µs) = 160000 Byte/s = 160KB/s. Wenn Du deine SD-Karte schnell genug takten kannst (vllt. 1 bis 2 MHz), dann könnte das klappen. Alternativ könnte ich Dir noch eine Festplatte empfehlen... Natürlich keine SATA-Platte, sondern eine IDE-Platte mit vielleicht 4GB Speicherplatz. Vorausgesetzt, Du hast so eine. Gruß Jonathan
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.
Siehe hier, Artikel STM32. Der hat bereits ein SDIO Interface für die SD-Card. Codedemos gibt auch irgendwo bei google, sogar mit FAT-Dateisystem.
Mir kommt es hier zuwenig zur Geltung dass die SD Karten ja Seitenweise beschrieben werden. Peter II schrieb: > 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. Das trifft es in etwa halb. Andere Aussagen gehen dahin , dass amn jedes Byte sofort schreiben sollte. Ich finde es etwas konfus. Meines Wissens nach speichern SD Karten im Page Modus und daher wäre es unsinnig einzene Bytes zu schreiben, da dieses Vorgehen die Karte früher kapuut schreibt als nötig. Zusätzlich is auch ein Blocktranfer. Was Uwe da schrieb schein mir am logischten. Uwe schrieb: > 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. Also richte schlichtweg eine 2 Page Puffer ein und immer wenn der eine voll ist wird er in die SD geschoben. Klaus
Jonathan Strobl schrieb: > Alternativ könnte ich Dir noch eine Festplatte empfehlen... > Natürlich keine SATA-Platte, sondern eine IDE-Platte mit vielleicht 4GB > Speicherplatz. Vorausgesetzt, Du hast so eine. CF-Karte. (Bis zu 90MB/s) Uwe schrieb: > Es gibt ja glaube ich auch SD Karten mit > unglaublichen Schreibgeschwindigkeiten jenseits von 30MByte/s. Aber die erreicht man im SPI-Mode nicht. 160kB/s (1,3MBit/s) sollten allerdings drin sein. Gruß Jobst
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
Hallo Reinhard, irgendwie verwirrst du mich. Ich musste zwar neulich schon eine Rüge einstecken wegen einer Zollgeschichte. Da wurde mir erklärt, dass meine Erkenntniss, die 30 jahre alt ist vielleicht nicht mer Up To Date ist. Aber mit den Speicherkarten hatte ich mich doch erst neulich (vor 3 Jahren) beschäftigt. 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. liebe Grüsse Klaus de Lisson
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
Mal blöd gefragt: Um welchen Controller handelt es sich überhaupt? Was spricht denn gegen einen D-Ram-Controller und genug Speicher dran? Hättest Du dafür überhaupt genügend Datenleitungen? Muss es ein AVR sein? Die Aufgabe wäre für den Nerdy fast langweilig.
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
Ja Reinhard, hatte ich das nicht schon erwähnt Klaus De lisson schrieb: > Für deine Anwendung wäre ja vielleicht ein SRAM interessant. > Die gibt es fast beliebig schnell und können als CacheRam > fungieren. Sram ist doch Static Ram oder nicht ? Klaus
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.