Hallo allesamt,
ich möchte gerne einen kleinen Datenlogger aus einem kleinen AT89S52 und
mehreren ca. 20-30 1-Wire-Temperatursensoren (evtl. später auchnoch
andere Sensoren) bauen. Nun stellt sich für mich die Frage, wo speicher
ich die Daten, bei einem Messzeitraum von wsl mehreren Monaten bis vlt.
ein Jahr.
Die Daten sollten später mit einem Computer verarbeitet werden können.
Meine ersten Ideen waren in diesem Fall:
- SD-Karte
> Hier stellt sich für mich die Frage, wie schaffe ich es, Daten zu
speichern, so dass sie in dem Dateisystem der Karte als Datei
abgelegt werden und vom Computer als Datei wieder erkannt werden.
Und
vorallem wie viel Aufwand ist dies programmiertechnisch.
- Im internen Speicher des µC
> Hierbei vermute ich fast, dass falls der µC mal abstürzen sollte
dann
alle Daten weg sein werden, oder?
- Im externen Eeprom
Bei den letzten beiden Ideen, könnte ich mir vorstellen die Daten dann
zur Übertragung aus dem Speicher zu laden und per serieller
Schnittstelle an den PC zu schicken.
Eventuell soll irgendwann später noch die Möglichkeit hinzukommen, die
Daten Live in einem Web-Interface zu sehen. Hier könnte man
beispielsweise noch ein Raspberry-Pi hinzuschalten, dass von ein
paar-Pins-Daten einliest und diese weiter verarbeitet.
Was meint ihr, wäre wohl die einfachste und sinnvollste Möglichkeit?
Die SD-Karten Version gefällt mir persönlich am besten. Allerdings kann
ich momentan noch nicht abschätzen, wie viel Aufwand das ist.
Oder habt ihr evtl. eine ganz andere Idee?
Viele Grüße Anon1234
Anon Anon schrieb: > Hier stellt sich für mich die Frage, wie schaffe ich es, Daten zu > speichern, so dass sie in dem Dateisystem der Karte als Datei abgelegt > werden und vom Computer als Datei wieder erkannt werden. Und vorallem wie > viel Aufwand ist dies programmiertechnisch. Willkürlich herausgepicktes Ergebnis der Forensuche für den Suchausdruck "fatfs sd": Beitrag "FATFS Datei erstellen und beschreiben" Da beschreibt zwar jemand ein Problem, das er damit hat, aber die relevanten Grundinformationen solltest Du da trotzdem finden können.
:
Bearbeitet durch User
Ich würde zuerst fragen: 1. Batterie/Akku oder Netzbetrieb 2. Umgebungsbedingungen (draußen, drinnen, Erschütterungen etc.) 3. Wie viele Daten? Zu 3.: Mal angenommen es wären 50 Sensoren deren Daten jeweils zwei Byte verbrauchen. Dann wären das bei einer Messung pro Sekunde: 100 * 86400 Bytes pro Tag oder 3.1536 GB pro Jahr, bei einer Messung pro Minute noch 52.56 MB
Ich mach sowas ähnliches, aber stationär (überwachung meiner Wärmepumpe & KWL, 8 Temperaturen, Luftfeuchtigkeit, diverse andere Parameter). Stationär hat in dem Fall den Vorteil: ich schick die Daten per UART an meinen Server (der im selben Raum steht) dort läuft ein kleiner Daemon der die Daten in eine SQLite-Datenbank schreibt. Wenn du "mobil" und im gerät selbst loggen willst, hilft das natürlich nix...
Arc Net schrieb: > Ich würde zuerst fragen: > 1. Batterie/Akku oder Netzbetrieb > 2. Umgebungsbedingungen (draußen, drinnen, Erschütterungen etc.) > 3. Wie viele Daten? Hi, danke für die schnelle Antwort :) Zu 1. und 2. Batterie / Akku, da draußen. Erschütterungen wird es keine geben, die ganze Schaltung liegt die ganze Zeit unbewegt in einem Fleck, der Controller in einem Wasserdichten-Gehäuse und die Sensoren an Kabeln in der Umgebung verteilt. Zu 3. Ich schätze maximal 1x pro Stunde müsste reichen, dei Messwerte werden vermutlich nie große Unterschiede schnell hintereinander haben. Gruß Anon1234
Bei "wsl mehreren Monaten bis vlt. ein Jahr." würde ich persönlich Backups haben wollen. Ich würde zweierlei machen: 1. Kurzzeitspeicherung in einem seriellen, batteriegepufferten SRAM 23LCV1024 http://www.microchip.com/wwwproducts/Devices.aspx?product=23LCV1024 Dieses RAM hat einen extra Pin zum Anschluss einer Batterie. Du wirst sicher auch eine RTC haben wollen, die kannst Du auch von dort aus versorgen wollen; Empfehlung: DS3234 http://datasheets.maximintegrated.com/en/ds/DS3234.pdf Das externe SPI-RAM behält seinen Inhalt auch bei einem Reset oder Stromausfall. 2. Langzeitspeicherung eines ganzen Tages einmal pro Tag auf SD-Karte oder per FTP auf irgend einen Server oder so. Dieses Vorgehen hat den Vorteil, dass Du zwischendurch die SD-Karte wechseln kannst und die Schreibzyklen auf die Karte minimiert werden. Jeder Flash-Speicher hat ja nur begrenzt Schreib-Löschzyklen, und wenn Du nur einmal pro Tag eine große Datei speicherst, kommen VIEL weniger Schreibzyklen zusammen als wenn Du minütlich einen neuen Datensatz speicherst. Plus: Wenn das Schreiben einmal fehlschlägt (weil Karte defekt oder voll oder so), sind die Daten immer noch im RAM, und die Kiste kann das nach Kartenwechsel noch einmal versuchen. fchk
Manche µP haben eingebautes EEPROM. Man kann auch ins eingebaute RAM speichern. Bei manchen kommt man auch an den FLASH ran. Es gibt auch z.B. I²C EEPROM. Eventuell ein Batteriegepuffertes externes RAM. FLASH-Karte. Via Datenübertragung (seriell, Bus, Funk u.s.w.) auf einem Dingsbums. 1 x pro Stunde sagt Garnichts, ohne die Aufbewahrungszeit (Summe).
Anon Anon schrieb: > Hi, danke für die schnelle Antwort :) > Zu 1. und 2. Batterie / Akku, da draußen. Erschütterungen wird es keine > geben, die ganze Schaltung liegt die ganze Zeit unbewegt in einem Fleck, > der Controller in einem Wasserdichten-Gehäuse und die Sensoren an Kabeln > in der Umgebung verteilt. Wasserdicht ist so eine Sache. Mit etwas Pech sammelt sich im Laufe der Zeit u.U. trotzdem Wasser im Gehäuse... > Zu 3. Ich schätze maximal 1x pro Stunde müsste reichen, dei Messwerte > werden vermutlich nie große Unterschiede schnell hintereinander haben. Das wären bei 100 Sensoren a 2 Bytes gerade mal 1752000 Bytes pro Jahr. Bei so was würde ich z.B. SST25VF032B ( 4 MiB Flash) verwenden. Vorteil gegenüber SD-Karte: Keine zusätzliche Mechanik, Arbeitstemperaturbereich, Stromaufnahme, Timing usw. sind vollständig mit Maximalwerten spezifiziert. Wenn es noch ausfallsicherer sein soll, könnten auch mehrere parallel oder zusammen mit FRAMs (http://www.cypress.com/?id=4984) genutzt werden. > > Gruß Anon1234
Ich habe so etwas mit dem Raspberry und WLAN gelöst. Der Raspi klappert die Sensoren ab und schreibt alles in eine MySQL DB. Parallel dazu wird eine weitere MySQL DB auf meinem Webspace gefüllt, so dass ich auch ein Backup habe und die Daten auch von unterwegs abgreifen kann. Die Visualisierung erledigt dann highcharts.com.
Pete K. schrieb: > Ich habe so etwas mit dem Raspberry und WLAN gelöst. > > Der Raspi klappert die Sensoren ab und schreibt alles in eine MySQL DB. > Parallel dazu wird eine weitere MySQL DB auf meinem Webspace gefüllt, so > dass ich auch ein Backup habe und die Daten auch von unterwegs abgreifen > kann. > Die Visualisierung erledigt dann highcharts.com. Wie groß muss denn dann die Batterie sein, wenn der wie geplant ein Jahr draußen liegt (scnr)
Anon Anon schrieb: > Meine ersten Ideen waren in diesem Fall: > - SD-Karte... Nee, laß sowas mal. Nimm dir nen seriellen Flash oder mehrere davon. Die sind mechanisch recht klein, vertragen ne Menge an Schreib/Lösch-Zyklen und du kannst damit auch was OHNE ein Filesystem anfangen. Allerdings solltest du dir als Datenformat irgend etwas platzsparendes ausdenken, also definitiv KEIN Klartext, denn so groß wie ne derzeitige SDHC sind serielle Flash's nicht. Beispiel: Pro Wert zwei DWORD's, darin das kanonische Datum, Meßstellennummer, Meßwert als skalierter Integer. Macht 8 Bytes. Bei z.B. einem MB Flash reicht das für 128 K Werte. Das sollte wohl über ein Jahr reichen. W.S.
Arc Net schrieb: > Pete K. schrieb: >> Ich habe so etwas mit dem Raspberry und WLAN gelöst. >> >> Der Raspi klappert die Sensoren ab und schreibt alles in eine MySQL DB. >> Parallel dazu wird eine weitere MySQL DB auf meinem Webspace gefüllt, so >> dass ich auch ein Backup habe und die Daten auch von unterwegs abgreifen >> kann. >> Die Visualisierung erledigt dann highcharts.com. > > Wie groß muss denn dann die Batterie sein, wenn der wie geplant ein Jahr > draußen liegt (scnr) Er will doch sowieso Kabel legen, warum nicht gleich die Stromversorgung mit? Was soll das für eine Anwendung werden?
Frank K. schrieb: > 1. Kurzzeitspeicherung in einem seriellen, batteriegepufferten SRAM > 23LCV1024 > http://www.microchip.com/wwwproducts/Devices.aspx?product=23LCV1024 Danke für den Tipp, das sieht schon mal sehr gut aus. :) Pete K. schrieb: > Ich habe so etwas mit dem Raspberry und WLAN gelöst. Das habe ich auch schon gedacht.. Meine Idee wäre dann gewesen, dass die Daten die entweder im normalen Speicher vom µC oder im einem angeschlossenem (siehe oben) gespeichert sind, in bestimmten Zeitzyklen per serieller Schnittstelle rausgeschrieben werden und dann vom Raspberry-Pi eingelesen werden. Arc Net schrieb: > Wie groß muss denn dann die Batterie sein, wenn der wie geplant ein Jahr > draußen liegt (scnr) Pete K. schrieb: > Er will doch sowieso Kabel legen, warum nicht gleich die Stromversorgung > mit? Ich kann während dieser Zeit auf jeden Fall immer mal wieder an die Schaltung ran, von daher kann die Batterie auch getauscht werden. Bloß ein direkter Anschluss an eine Stromversorgung wird nicht funktionieren. W.S. schrieb: > Nee, laß sowas mal. > > Nimm dir nen seriellen Flash oder mehrere davon. Die sind mechanisch > recht klein, vertragen ne Menge an Schreib/Lösch-Zyklen und du kannst > damit auch was OHNE ein Filesystem anfangen. Allerdings solltest du dir > als Datenformat irgend etwas platzsparendes ausdenken, also definitiv > KEIN Klartext, denn so groß wie ne derzeitige SDHC sind serielle Flash's > nicht. Alles klar, dann wird die Sache mit der SD-Karten-Anbindung wsl erstmal nach hinten geschoben. Weil irgendwann will ich das sowieso mal können. Das mit dem Klartext ist dann schon klar :)
(Faßaufmach) Jetzt können sich die Arduino-hater wieder die Finger wund klappern. (gerne bitte mit funktionierenden Projekten. Ich habe nämlich nirgendwo welche gefunden) Bei Arduino gibt es das bei den Beispielen SD->datalogger. Dann bist Du in ein paar Minuten fertig. So ein System habe ich hier laufen. Nachteile: Der Prozessor läuft ständig und voll, also kein Stromspar-Modus. Nicht für Batterie geeignet. Die Lib's lassen sich nicht aus der IDE herauskopieren. (doch, aber da alles sehr verschachtelt ist, hat man sehr viel Arbeit damit bei fraglichem Erfolg) Aber gleichzeitig beiße ich mir die Zähne aus an einem Nicht-Arduino. Einfach nur 4 (oder 6) Analog-Kanäle auslesen und mit Echt-Zeitstempel als csv auf einer SD-Karte ablegen, soll auf m8-µC laufen und Batt-geeignet sein. Die Bibliotheken, die ich anpassen soll, sind seriell, DS1302, SD, evtl. noch 1-wire Temperatur. Nächste Baustelle ist, die csv-Daten anzuzeigen. Libre office calc wird bei >50k Zeilen schwach, Qtiplot geht grade so. GNUplot hat keine gescheite Klick-Oberfläche. Ingo's csv Viewer (hier im Forum) geht gut (unter wine), ist aber ein 1-Mann-Projekt (trotzdem volles Lob). (bei mir ist Linux die Voraussetzung). Option ist, nur bei Veränderung der Eingangswerte eine Zeile zu erzeugen, das ist aber eine Herausforderung an das plotprogramm. Ich rechne damit, zu verwendbaren Ergebnissen zum Ende dieses Jahres zu kommen, inkl Gehäuse im 3d-Druck. Wir können gerne in Kontakt bleiben.
Hallo zusammen, gerade habe ich einen Post zu diesem Thema eröffnet. Den kann ich dann wohl wieder löschen. Also klinke ich mich hier auch mit ein: Ich habe auch einen Datenlogger, der über einen längeren Zeitraum autark Daten aufnehmen soll. Der hat zwar eine Funkverbindung, die aber nicht ständig funktionieren könnte (verbindungsfehler, große Entfernung, Störungen,..). Bei Batterieausfall sollen die geloggten Daten auch erhalten bleiben. Also: SD-Card, Flash oder EEPROM. EEPROMs sind bis 1 Mbit erhältlich -> für mich zu wenig. Daher bleiben nur SD-Card oder Flash (32 Mbit SST25VF032B). SD Karte würde ich wegen des hohen Stromverbrauches für Standby (ca. 1mA) und Schreiben/Lesen (einige 10mA) ausschließen. Für aktuelle SD-Karten gibt es leider ausführlichen Datenblätter. Die Werte habe ich ergoogelt. Wenn es konkrete Erfahrungen gibt: Ich bin für jede Info dankbar. Mein Favorit ist auch aus den zuvor genannten Gründen das serielle Flash mit 32 Mbit. Allerdings stellt sich mir ein Problem: Vor den Schreiben muss die zu beschreibende Adresse / die Adreessen des Flashs auf gelöscht stehen (Speicherinhalt 0xff). Dies wird durch Löschen eines kompletten 4 KByte Blocks erreicht. D.h. der Block muss vor den Löschen im uC (xmega32A4u) gepuffert werden. Dieses Puffern braucht aber das gesamte RAM des uC auf. Läßt sich das Schreiben eines oder mehrerer Bytes auch ohne Puffern des 4KB Flashblocks schreiben? Hat jemand schon mal Routinen für einen Xmega32 geschrieben? Gruß Karsten
Nimm doch ein SPI-RAM zum Puffern. http://www.microchip.com/pagehandler/en-us/products/memory/serialSRAM/home.html fchk
@ Karsten (Gast) >Daher bleiben nur SD-Card oder Flash (32 Mbit SST25VF032B). >SD Karte würde ich wegen des hohen Stromverbrauches für Standby (ca. >1mA) und Schreiben/Lesen (einige 10mA) ausschließen. Man kann sie auch echt ausschalten (VCC abklemmen per MOSFET). Zwischendurch puffert man im RAM. >Vor den Schreiben muss die zu beschreibende Adresse / die Adreessen des >Flashs auf gelöscht stehen (Speicherinhalt 0xff). Ja. >Dies wird durch >Löschen eines kompletten 4 KByte Blocks erreicht. Sicher? Die meisten Flashs dieser Art schreiben seitenweise mit typisch 512 Byte/Seite. >D.h. der Block muss vor den Löschen im uC (xmega32A4u) gepuffert werden. Diese Flash haben einen, manchmal sogar ZWEI Puffer eingebaut! >Dieses Puffern braucht aber das gesamte RAM des uC auf. Nein.
Falk Brunner schrieb: > Diese Flash haben einen, manchmal sogar ZWEI Puffer eingebaut! Diese können die Daten in der Regel auch nur seitenweise beschreiben, daher gibt es einen Speicher. Die SSTs können aber byteweise beschrieben werden.
Ich nochmal: Was haltet Ihr von dem Flash (ist ein extra Data Flash): http://adestotech.com/products/dataflash-all-products AT45DB321E (4MB) bzw. AT45DB641E (8MB). Das hat einen 256 Byte Buffer, der auch in uC mit wenig RAM gehalten werden kann. Uasserdem bietet der Flashbaustein noch bequeme Befehle zum Schreiben/Lesen des Flashes, u.a. eine direktes byteweises beschreiben (read-modify-write) ohne, dass die gesamte Flash-Seite beeinflusst wird (quasi wie beim EEPROM). Ich werde mir diese Bausteine gleich bestellen. Für mich eine gute Alternative hinsichtlich des Stromverbrauchs zur SD-Karte. Und mit 8 MByte lässt sich eine Menge aufzeichnen :) Karsten
Olla, vielen Dank für die zahlreichen Antworten :) Der Reihe nach: @Frank >Nimm doch ein SPI-RAM zum Puffern. Für mich zu wenig Speicher. NVRAM brauch noch eine Batteriepufferung. Wenn die Spannung ausfällt ist der Inhalt. Für mich ist die Datensicherheit wichtiger, daher Flash oder EEPROM. @Falk >Man kann sie auch echt ausschalten (VCC abklemmen per MOSFET). >Zwischendurch puffert man im RAM. Der Strom zum Lesen und Schreiben ist bei SD-Karten höher als bei Flash-Bausteinen. Außerdem ist der Code zum Ansteuern der SD-Karte komplexer als bei einfachem Flash >Sicher? Die meisten Flashs dieser Art schreiben seitenweise mit typisch >512 Byte/Seite. >Diese Flash haben einen, manchmal sogar ZWEI Puffer eingebaut! Der SST25VF032B hat keine Buffer (im Datenblatt habe ich keinen Hinweis darauf gefunden). Ohne Puffer im Flash müssen die Daten vorher vom Flash in uC-RAM gelesen werden, damit die Daten während des Löschend erhalten bleiben. @D,ohh!!! >Diese können die Daten in der Regel auch nur seitenweise beschreiben, >daher gibt es einen Speicher. Die SSTs können aber byteweise beschrieben >werden. 1) Wird Byteweise programmiert, muss die Speicherstelle gelöscht sein, d.h. mit 0xff belegt sein. Das Löschen geht laut Datenblatt nur mit dem Sektor-lösch-Befehl, d.h. dort befindliche Daten sollten gepuffert werden. 2) Dann gibt es noch das Programmieren mit automatischem Adress-Inkrement. Auch muss der zur beschreibende Bereich gelöscht (mit 0xff belegt) sein. Also auch die In dem Block enthaltenen Daten puffern und den 4KB Block vor dem Beschreiben löschen. Ich denke, dass das AT45DB..E Data Flash von Adesto für die Anwendung als Datensammler besser geeignet ist. Der hat definitv Buffer eingebaut. Hat denn schon mal jemand z.B. 6 Byte in ein Sektor mit vorhandenen Daten geschrieben? Wie wurde das gemacht? Ich muss schon sagen, dass die Frage nach geeignetem Speicher für Datenlogger doch nicht so einfach zu beantworten ist wie auf dem ersten Blick vermuten lässt. Danke und Gruß Karsten
Karsten schrieb: >>Nimm doch ein SPI-RAM zum Puffern. > > Für mich zu wenig Speicher. NVRAM brauch noch eine Batteriepufferung. > Wenn die Spannung ausfällt ist der Inhalt. > Für mich ist die Datensicherheit wichtiger, daher Flash oder EEPROM. Nicht ent oder weder. Zusätzlich. Das kleinste SPI-RAM mit 8k reicht. Das schreibst Du erstmal voll, und wenn das voll ist, kopierst Du den Inhalt ins Flash. Das Flash ist damit seltener aktiv und auch die Pagegröße ist für Dich dann kein Problem mehr, weil Du dann ohnehin nur noch komplette Pages schreibst. Sehe es als Erweiterung des internen RAM an. fchk
Hallo Frank, ahhh...vorher falsch gedacht.. Ich soll das SRAM als "RAM-Erweiterung" des uC verwenden und den Inhalt der Flash-Seite dort hineinschreiben. Gute Idee, danke. Manchmal sieht man den Wald vor lauter Bäumen nicht :) VG Karsten
Angehängte Dateien:
Habe so ein Logger-Projekt auch schon gemacht. Bei meinem Logger werden die Daten in einem 24C1024 eeprom gespeichert. Man kann max 2 Eeproms verwenden, darin haben dann 131000 messwerte platz (1Messwert = 2bytes). Wenn du ein Jahr lang aufzeichnen möchtest, kannst du mit 50 Sensoren maximal 7 Messungen pro Tag speichern. Eine passende Auswertsoftware für den Computer ist natürlich auch schon vorhanden. Meine Sensoren werden jedoch mit i2c mit dem Logger verbunden, durch ein kleine Anpassung kannst du natürlich auch 1-wire verwenden (Programmiersprache Bascom).
Karsten schrieb: > Das hat einen 256 Byte Buffer, der auch in uC mit wenig RAM gehalten > werden kann. Karsten schrieb: > 1) Wird Byteweise programmiert, muss die Speicherstelle gelöscht sein, > d.h. mit 0xff belegt sein. Das Löschen geht laut Datenblatt nur mit dem > Sektor-lösch-Befehl, d.h. dort befindliche Daten sollten gepuffert > werden. Du scheinst nicht verstanden zu haben wie diese Chips funktionieren. Der AT45xx hat einen internen Puffer für eine Speicherseite. Dieser Puffer wird beschrieben und dann in den Flash gespeichert. Will man diese Seite editieren dann wird aus dem Flash in den Puffer kopiert, dort die neuen Daten geschrieben und dann aus dem Puffer wieder in den Flash geschrieben. Beim ST25xx löscht man zuerst den Sektor und dann kann man diesen individuell beschreiben. Es muss nichts im Controller gepuffert werden weil man den Flash ja entweder Byte-weise oder über den internen Puffer beschreiben kann.
nix und nul schrieb: > Bei Arduino gibt es das bei den Beispielen SD->datalogger. Dann bist Du > in ein paar Minuten fertig. So ein System habe ich hier laufen. Hi.. also stimmt mit Arduino wäre es wsl wesentlich einfacher. Aber ich habe diesmal den Anspruch an mich selbst gestellt, dass ich mal etwas mit einem "richtigen" µC bauen will und von daher denke ich mal wird es auch dabei bleiben. nix und nul schrieb: > Ich rechne damit, zu verwendbaren Ergebnissen zum Ende dieses Jahres zu > kommen, inkl Gehäuse im 3d-Druck. Wir können gerne in Kontakt bleiben In Kontakt könne wir aber trotzdem gerne bleiben, wie stellst du dir das vor? Hier im Forum oder per Mail? Michael L. schrieb: > Habe so ein Logger-Projekt auch schon gemacht. Bei meinem Logger werden > die Daten in einem 24C1024 eeprom gespeichert. Man kann max 2 Eeproms > verwenden, darin haben dann 131000 messwerte platz (1Messwert = 2bytes). > Wenn du ein Jahr lang aufzeichnen möchtest, kannst du mit 50 Sensoren > maximal 7 Messungen pro Tag speichern. > > Eine passende Auswertsoftware für den Computer ist natürlich auch schon > vorhanden. Meine Sensoren werden jedoch mit i2c mit dem Logger > verbunden, durch ein kleine Anpassung kannst du natürlich auch 1-wire > verwenden (Programmiersprache Bascom). Hört sich ziemlich interessant an. Wie hast du dann die Messwerte an dein Programm auf dem PC übertragen? Per serieller Schnittstelle? Über EEPROMs hab ich auch schon nachgedacht. Vor allem weil ich irgendwo noch welche liegen hab. aber ich muss mich erstmal in das Datenblatt von dem SRAM einlesen, was jetzt komplizierter ist.
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.