Forum: Projekte & Code Datenlogger mit Atmel AT45DB081D + ATMEGA88 in C


von Michael S. (Gast)


Angehängte Dateien:

Lesenswert?

Datenlogger mit Atmel AT45DB081D + ATMEGA88 in C

Vor ungefähr einem Monat  hatte ich einen Datenlogger auf der Basis des 
VDIP1 mit USB-Stick als Datenträger ins Netz gestellt.
 Der Vorteil dieses Loggers ist seine schier unbegrenzte 
Speicherfähigkeit auf dem USB-Stick.
Nachteilig sind die hohen Kosten des VDIP1/Stick, der hohe 
Stromverbrauch des Gesamtsystems sowie das Volumen des Gerätes.

Daher ist ein weiterer Logger auf der Basis eines serial-interfaced 
Flash Memory (Atmel DataFlash) entstanden.
Die Vorteile dieser Variante:
preisgüstig, kompaktes Gehäuse realisierbar, schnell, stromsparend (auch 
im Batteriebetrieb einsetzbar),
kein kompletter Dateiverlust bei Stromausfall oder versehentlichem 
Abschalten (beim VDIP1 muss eine Datei immer ordentlich geschlossen 
werden).
Einziger kleiner Haken: der Speicher wird als smd-Chip geliefert.

Im  beigefügten Programm wird ein ATMEL AT45DB081D mit 1 MB Speicher an 
einem ATMEGA168 betrieben.
Der Speicherbedarf des Programms liegt unter 4kB für die "passive" 
Variante, etwas ca. 5 kB für die "aktive" Variante.

Wo liegt der Unterschied:

In der "passiven" Variante nimmt der Logger Daten via TWI oder RS232 
entgegen.
Passiv deswegen, weil er eben abwartet, bis ihm irgendjemand 
irgendwelche Bytes zuschiebt.
Diese Variante ist nur für einen einzelnen Sensor sinnvoll (z.B. eine 
GPS-Maus).

Um mehrere Sensoren abzufragen, ist die "aktive" Variante entstanden.
Hier aggiert der Logger als TWI-Master und fragt in einstellbaren 
Zeitabständen seine Slaves ab.
Im Beispielcode werden die Temperaturdaten von vier Dallas DS1631 
ausgelesen.

Die Ausgabe der aufgenommenen Daten erfolgt bei beiden Fällen über die 
serielle Schnittstelle.
Weitere Beschreibungen in der readme sowie im dokumentierten 
Programmcode (in C).

Viel Spaß beim Loggen,

Michael S.

von Michael S. (Gast)


Lesenswert?

Hallo allerseits,

hier noch eine vielleicht frustvermeidende Anmerkung.
Der (passive) Logger bietet die Möglichkeit, Daten über RS232 oder TWI 
zu empfangen.
Sinvollerweise wird man in der Regel nur einen der beiden Eingänge (zur 
selben Zeit) nutzen.

Unbeschaltete aktive Eingänge (RxD, SCL, SDA) muss man aber unbedingt 
terminieren !

Bei mir äußerte sich das Problem beim Loggen via TWI (RxD driftete frei 
"im Raum").
Gelegentlich und ohne Systematik wurden unsinnige Daten zusätzlich zu 
den Nutzdaten geloggt - sogar dann, wenn der Sensor inaktiv war.

Ein Pullup von 22k zwischen RxD und VCC hat dem Spuk ein Ende bereitet.
SCA und SCL sind bei mir am Master grundsätzlich mit 5K nach VCC gezogen
(zusätzliche Pullups dann noch am Ende längerer Leitungen).

Michael S.

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

Das DataFlash gibt es pinkompatibel und weitgehend befehlskompatibel 
inzwischen bis 64MBit (8MByte) als AT45DB641D.

von Michael S. (Gast)


Angehängte Dateien:

Lesenswert?

@ Travel Rec.

gibt's den AT45DB641D wirklich ? Ich finde nur den AT45DB642D.
Und der hat leider keine Pins sondern Lötpads.
Damit kriege ich sicherlich ein Problem.

Ansonsten:

Um meinen Logger auch an einem Dataflash mit mehr als 1 Mb verwenden zu 
können, waren einige Veränderungen an den Pageheadern erforderlich (ich 
hatte mich dummerweise auf eine feste Page-Größe von 264 Byte 
eingeschossen).
Diese Gelegenheit habe ich gleich genutzt, um auch die Programmstruktur 
etwas zu straffen.

Hier angehängt ist eine überarbeitete Version des passiven Loggers - 
weiterhin für den AT45DB081D.
Das Programm benötigt weniger als 4 KB Flash - aber ca. 1 KB SRAM.
Daher ist mindestens ein ATMEGA88 oder ATMEGA8 angesagt.

Funktional ist das Programms fast identisch mit der letzten Version (neu 
ist lediglich, dass sich bei Bedarf die LEDs
während des Loggens ausschalten lassen).

Eine allgemeine Anpassung für den Einsatz des AT45DB161D/AT45DB321D ist 
nun leicht nachrüstenbar (aber hier nicht eingebaut!), mangels 
geeigneter Hardwares konnte ich das Programm noch nicht praktisch 
testen.



Viel Spaß beim Loggen,

Michael S.

von Michael S. (Gast)


Angehängte Dateien:

Lesenswert?

Häufig sind ja die einfacheren Lösungen die besseren ...

In gewisser Weise ist der nochmalig überarbeitete Logger einfacher.
Er schreibt nämlich eingehende Daten direkt (ohne Zwischenpufferung auf 
dem ATMEGA) in einen der beiden Buffer des DataFlash.
Dadurch läßt sich der SRAM-Bedarf kräftig (auf unter 256 Byte) 
reduzieren.
Ein ATMEGA48 reicht nun als Controller aus.

Und gleichzeitig ist der Programmcode mit einigen wenigen Änderung auch 
mit den größeren DataFlash's lauffähig.

Aufwändiger oder umfangreicher geworden ist lediglich die Kommunikation 
zwischen ATMEGA und DataFlash:
für jedes zu speichernde Byte müssen 4 Byte für Kommando und Adresse 
gesendet werden.
Aber die SPI-Schnittstelle ist ja sehr schnell und stemmt das ohne 
Murren.

Michael S.

von Michael S. (Gast)


Angehängte Dateien:

Lesenswert?

Hallo allerseits,

mittlerweile hatte ich die Möglichkeit, auch einen AT45DB321 mit 4MB 
auszuprobieren.
Es gab natürlich noch ein paar Bugs auszubügeln, jetzt läuft aber auch 
der größere DataFlash.

Anbei der Quellcode, der durch Änderung der Header-Datei auch auf dem 
AT45D081 (1MB) läuft und auf dem AT45DB161 (2MB) laufen sollte (nicht 
getestet).
Vermutlich auch auf den noch kleineren Chips, deren Datenblätter ich mir 
aber nicht angesehen habe.

Getestet habe ich das Loggen von Daten über die Serielle Schnittstelle 
mit 9600 Baud bzw. über TWI mit 100kHz.

Damit ist für mich das Projekt abgeschlossen.


Michael S.

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

Michael S. schrieb:
> gibt's den AT45DB641D wirklich ? Ich finde nur den AT45DB642D.
> Und der hat leider keine Pins sondern Lötpads.
> Damit kriege ich sicherlich ein Problem.

Du hast recht. Aber das CASON Package könnte man als DeadBug mit 
Fädeldraht anlöten. Hat dasselbe Pinout wie SO8.

von Matthias (Gast)


Lesenswert?

Welche Datenraten kann man beim Schreiben erreichen?
Wir würden diesen Chip gerne als schnellen Speicher integrieren?
Muss man mit den selben langen Wartezeiten (Busy Times) wie bei den 
Karten rechnen?

Wir würden eine Schreibgeschwindigkeit von min. 200 kByte / s benötigen.

von (prx) A. K. (prx)


Lesenswert?

Die Lösch/Schreibzeit pro Block steht im Datasheet. Da parallel dazu der 
jeweils andere Puffer gefüllt werden kann, entsteht kein weiterer 
Zeitverlust.

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.