Hallo! Ich enwterfe zur Zeit einen Datenlogger. Dieser soll über einen langen Zeitraum sporadisch auftretende Ereignisse protokollieren. Das Datenaufkommen pro Ereignis liegt bei ca 40kB! Es sollten min. 100, besser mehr Ereignisse in den Speicher passen. Außerdem sollte er Permanent sein. Was nimmt am besten um sowetwas zu realisieren? Und wichtig wäre noch zu erwähnen, dass ich einen ext. RAM verwende, der Speicher müsste also aus Platzgründen seriell funktionieren. Vielen Dank im Vorraus, mit freundlichen Grüßen, Uwe
Meinst Du mit "permanent" vielleicht nichtflüchtig? Es gibt haufenweise EEPROMs und Flash-Bausteine für SPI- oder I²C-Anbindung. Einfach mal gugeln nach "SPI Flash" oder "I²C Flash"... Ansonsten nimmste ne SD- oder MM-Karte. Da gibt es hier im Forum einen ganzen Haufen Beispiele für die Anwendung.
@Uwe (Gast) >Das Datenaufkommen pro Ereignis liegt bei ca 40kB! >Es sollten min. 100, Macht ca. 4MByte. > besser mehr Ereignisse in den Speicher passen. >Außerdem sollte er Permanent sein. >Was nimmt am besten um sowetwas zu realisieren? Vieles. SD-Card, Serielles Flash, Compact-Flash, whatever. MFG Falk
DataFlash ist billig und unkompliziert.
Dank für die raschen Anworten. Entschuldigung. Ich hatte vergessen zu sagen: Der Speicher sollte nicht auswechselbar sein. Das ganze wird in einem Gehäuse verbaut und die Daten sollten nach möglichkeit ohne Dateisystem einfach nacheinander geschrieben werden. Ist soetwas mit einem Flash realisierbar? Ich habe gerade in einem Ergebnis der googlesuche gelesen, dass es I2C Flashs nur im kB Bereich gibt. Für MB müsste man mit SPI arbeiten. Ist das problematisch? An meiner PrototypenPlatine ist nämlich auch ein ISP-Adapter. Gruß, Uwe
DataFlashs lassen sich wunderbar an Software-SPI betreiben, da ihr Interface-Verhalten absolut unkompliziert ist. Kein /CS oder keine Clock und alle anderen Pins können wackeln, wie sie wollen.
Atmel-ISP und SPI kollidieren auch an den gleichen Leitungen nicht. 10K-100K Pullup-Widerstand an die CS/Select-Leitung vom SPI-Slave und schon kriegt der vom ISP garnichts mit. In manchen SPI-Slaves ist einer schon drin.
Ok, das hört sich ja schonmal ganz gut an. Noch zwei Dinge. Der größte DataFlash von Atmel hat 8192 Pages mit jeweils 1kB. Gibt es da noch was größeres? wenn nicht ist das ok, der Speicher reicht ja für genug Messungen. Wäre aber eine schöne Sache. Ich habe noch nie Flashs programmiert. Kann man trotz der Pages kontinuierlich programmieren? Also Zelle für Zelle beschreiben? Oder kennt wer ein gutes Tut diesbzgl.? Vielen Dank für die zahl- und vor allem hilfreichen Beiträge, gruß, Uwe
Viel grösser sind naturgemäss die Flash-Chips, die in Sticks und Flashkarten drin stecken. Aber bischen schlechter zu kriegen und mehr Pins. Problem bei Dataflashes ist normalerweise, dass sie blockweise geschrieben werden. Was etwas stört, wenn die Daten in 8 Byte Häppchen gespeichert werden sollen, denn das ist ein bischen viel kleiner als die Blöcke. Bei deinen 40KB ist das aber kein Thema.
Nein, die Datenfalsh von Atmel sind NOR-flash und daher viel sicherer als die ueblichen NAND-Flash. Ja. die muss man seitenweise beschreiben. Zuerst den internen RAM buffer fuellen und dann schreiben. Ja. Das geht kontinuierlich, da man einen zweiten buffer hat. Ja. das Datenblatt des Datenflash ist etwas mehsam und kompliziert. Aber machbar.
Hmm jetzt gibt es nur ein Problem. Das Device gibt es nicht in Eagle und ich habe noch nie eine Lib selbst gemacht! http://www.atmel.com/dyn/resources/prod_documents/doc3542.pdf hat das hier jemand parat? Ansonsten werde ich mich wohl oder übel daran setzen müssen.. ;) Gruß, uwe
> Viel grösser sind naturgemäss die Flash-Chips, > die in Sticks und Flashkarten drin stecken. USB-Stück kaufen, chip rauslöten, fertig > mehr Pins. Leider. Vielleicht doch lieber "löten lassen" und "platine fertigen lassen" ;-) Falls dir ein Dataflash zu wenig ist kannst du auch zwei oder drei verbauen. Jedes davon kriegt dann halt ne eigene chipselect-leitung
Wird dann einfacher sein, direkt eine MMC-Karte zu verwenden. Ist auch bloss SPI.
Eine Eagle-Lib für die Dataflashes müsste es eigentlich geben.
>Wird dann einfacher sein, direkt eine MMC-Karte zu verwenden. Ist auch >bloss SPI. Der Steueroverhead und die Bedienung einer SD/MMC-Karte ist ungleich schwieriger und ressourcenfressender, als die Anbindung eines/mehrerer DataFlashs. Bei riesigen Datenmengen ist die SD-Karte im Vorteil, für kleinere Datenlogger und gerade bei Batterieanwendung kann ein DataFlash klar punkten.
Entscheide mich auf jedenfall für den Dataflash. Den großen gibt es leider als 8 Pin nur in einem "CASON Gehäuse". Da sind die SMD-Pads unter dem Chip, ich glaube das kann man garnicht Löten. Das heißt durch die CS Pins kann ich die jeweils aktivieren bzw deaktivieren? Hmm, ich habe mal nach einer Lib gegooglet, aber nichts gefunden. Aus Lötgründen werde ich in dem Prototypen erstmal zwei http://www.atmel.com/dyn/resources/prod_documents/doc3597.pdf als SOIC verbauen. Später ev. dann was anderes. Ich wäre froh, wenn mir jmd. eine Lib zur Verfügung stellen könnte. Gruß, Uwe
Das Datenblatt zum AT45DBxxx beschreibt das Interface sehr ausführlich und genau. Mehr als ein paar Zeilen ASM brauchst Du für eine geschwinde Ansteuerung der wichtigsten Funktionen nicht. DataFlashs gibt es unter anderem auch bei CSD-electronics.
Hmm, ok. Mit Lib meinte ich eigentlich Eagle-Lib, aber habe gerade das atmel-Package nach ewigem Trial&Error um diesen Baustein erweitert. Wenn Interesse besteht (und mir jemand sagt wie ich es aus der Lib bekomme) kann ich das zur Verfügung stellen. Reichlichen Dank für die Hilfen. Noch etwas zu CS. Einfach jeden CS der Geräte an den AVR führen. wenn der den Pin auf Low zieht ist der Chip aktiv? Und was mache ich genau mit den PullUps wegen der ISP?
Pullups deshalb, weil die Pins vom AVR während und kurz nach Reset als Eingang ohne Pullup konfiguriert sind, und daher keinen definierten Pegel haben. Kann zur ungewollten Aktivierung der Slaves führen. Das gilt generell für alle SPI-Slaves, egal ob an Hardware-SPI oder an Software-SPI. Besonders wichtig ist das natürlich, wenn das SPI mehrfach verwendet wird, also ISP+SPI, oder bei mehreren SPI-Slaves. Atmel-ISP ist damit narrensicher abgedeckt, da dies stets von aktivem Reset begleitet ist, somit die Pullup an den CS-Leitungen die Slaves deaktivieren.
Ok, klingt einleuchtend ;) Mir ist da gerade etwas eingefallen. Ich betreibe meinen AVR wegen der 16 MHz mit 5V, die Flashs kriegen 3,3V. Das habe ich durch einen zweite Festspannungsregler "geregelt". :D Nur wie sieht das aus mit den Eingängen? Der AVR liefert ja einen 5V High-Pegel, vertragen die Flashs das?
Die ATMEL-Dataflashs der Serie 45DBxxxD sind 5V-tolerant an den Eingängen. Der Ausgang liefert knapp die Vcc des DataFlashs, was einem 5V-AVR gerade noch als High-Pegel reicht. Alternativ kannst Du den AVR mit 4V betreiben, dann versteht er die 3V-Pegel mit Sicherheit als High und kann auch noch mit 16Mhz laufen.
Das ist auf jedenfall die elganteste Lösung. Nur welcher Regler regelt auf 4 Volt. Gibt es hier eine Liste div. Regler?
Ein 3,3V-Regler, dessen Masse über einen Widerstand angehoben wird? Oder halt ein einstellbarer Festspannungsregler mit Adjust-Pin, der wiederum an einen Spannungsteiler angeschlossen wird.
Hmm, ich habe auf der Platine zusätzlich noch einen Ram+Latch und einen MAX232. Kommen die mit den Pegeln noch zurecht wenn der AVR auf 4V läuft? Wie sieht das denn aus, welchen bidirektionalen Pegelwandler würdet ihr für einen SPI verwenden? Ich denke dass ein Pegelwandler eine Saubere Lösng wäre. Das Anheben der Spannung durch Spg-Teiler bzw. Z-Diode ist nicht sehr professionell denke ich. Oder sehe ich das völlig falsch? Gruß, Uwe.
Also wir haben hier etliche Geräte im Einsatz, bei denen der AVR mit 5V und das DataFlash mit 3,3V ohne zusätzliche Pegelanpassung laufen und da ist es noch zu keinen Problemen gekommen. Im AVR-Eingang haben wir zusätzlich den PullUp gesetzt, um dem 3,3V Pegel vom DataFlash noch etwas Schwung nach oben zu verpassen. Die Clockrate zum / vom DataFlash liegt hier bei etwa 7MHz. Und wenn Du unbedingt einen Pegelwandler einsetzen wilst, brauchst Du nur einen einzigen von DO zum AVR, weil die Eingänge des DataFlashs - wie gesagt - 5V-tolerant sind.
Ok, klingt einleuchtend! Also einfach den PullUp im AVR aktivieren an dem SO hängt? Hört sich ja gut an. Ich denke so werde ich das machen, die Platine würde ja unnötig wachsen bei einem zusätzlichen Chip. Vielen Dank.
Travel Rec. wrote:
> weil die Eingänge des DataFlashs - wie gesagt - 5V-tolerant sind.
Wenn man die richtigen verwendet. Es gibt auch welche deren Eingänge
nicht 5V-tolerant sind.
Habe noch ein Frage bzgl. des Busy-Outputs. Sollte man diesen in seinem Algorithmus berücksichtigen. Oder kann man sich auf die Schreibgeschwindigkeit des Buffers verlassen? Wie löst ihr das?
Ein 3.3V Spannungsregler, wie ein LP2951 geht uebrigens nicht, denn das ist ein Serieregler. Der laesst den Strom vom 5V nach 3.3V fliessen und regelt da. Wenn die Pins an 5V angeschlossen werden, so wird dieses 3.3V Niveau auch auf 5V angehoben werden. Macht nichts, denn die Maximum ratings erlauben 5V. Allerdings erhoeht sich dann der Stromverbrauch ein wenig. Aber falls Stromsparen ein Thema waere, so wuerde die CPU eh nicht mit 5V laufen.
Ich fand das busy signal sehr hilfreich, besser als abfragen, besser als timen. dh ich hab das Busy auf Int_1 genommen. Das macht den Code etwas komplizierter, aber schneller.
Ok, ich werde in der Implementierung darüber nachdenken! Was meinst du denn mir dem Regler? Was soll ich denn für einen verwenden?
8421 wrote: > Ein 3.3V Spannungsregler, wie ein LP2951 geht uebrigens nicht, denn das > ist ein Serieregler. Habe ich nicht kapiert. Warum willst du partout einen Parallelregler verwenden? Wenn die Eingänge eines 3V-ICs per Datasheet 5V-kompatibel sind, dann haben sie logischerweise keine einfachen Schutzdioden gegen Vcc drin, Rückspeisung über die Eingänge findet also nicht statt. Sonst wär's ja grotesk. Nach deiner Logik würde der 3,3V-Parallelregler statt dessen die 5V-Versorgung auf 4V runterwürgen.
>Ich fand das busy signal sehr hilfreich, besser als abfragen, besser als >timen. dh ich hab das Busy auf Int_1 genommen. Das macht den Code etwas >komplizierter, aber schneller. Die o.g. DataFlashs haben keine Busy-Leitung. Da sie über 2 interne SRAM-Buffer verfügen, kann man sehr schnell einen Buffer füllen, eine Page schreiben und dann gleich den 2. Buffer füllen und so weiter. Vor dem Schreiben der Page fragt man einfach den Status ab und guckt, ob noch Busy oder nicht. In den allermeisten Fällen wird der Flashspeicher dann schon wieder bereit sein. In einem Experiment habe ich 16Bit Stereo-Audiodaten mit 50kHz Samplerate unter Verwendung beider Buffer auf das DataFlash geschrieben, ohne ein einziges Mal warten zu müssen.
http://www.atmel.com/dyn/resources/prod_documents/doc3597.pdf Dieser hat sehr wohl einen Busy-Output. Aber das hört sich schon sehr plausibel an. Zwei Buffer, damit kann man eine Menge veranstalten.. :D
>Dieser hat sehr wohl einen Busy-Output.
Yes, of course, aber nur in dem Megapin-Gehäuse. Beim schnuckeligen SO8
fehlt dieser Pin. Braucht man ja auch nicht wirklich.
stimmt, garnicht drauf geachtet.. Damit hat sich die Frage der benutzung auch geklärt :D Kein Pin da, dann verwende ich ihn auch nicht!
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.