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