Datenlogger mit uC basteln

Peter Blancke schrieb:

Ich hätte gedacht, dass der 4 Mbit Dataflash da drauf genügt, um die paar Messwerte zu speichern. 512 KB / 8000, da könnte jeder Messwert

64 Bytes haben, das wären zwei Gleitkommazahlen.

--
Jörg Wunsch

"Verwende Perl. Shell will man können, dann aber nicht verwenden."
				Kristian Köhntopp, de.comp.os.unix.misc

Hallo Joerg

Danke, für den Hinweis.

Nun, 4 Mbit sind nicht schlecht, aber mehr wär' besser. Sagen wir mal es sind 10 Sensoren angeschlossen, wir messen alle 5 Minuten, speichern pro Sensor 16 Bit (auch wenn's eigentlich nur 12 sind) und noch die die Zeit mit 32 Bit dazu, dann passen in die 4 MBit 20000 Messungen das sind aber dann nur etwa 2 Monate Messzeit.

Grüße Flo

Hallo Peter

Oh ja, schönes Projekt, hab ich schon mal was drüber gelesen (c't?). Fand's sehr interessant, wäre in der Tat eine feine Sache den Logger an's LAN anschließen zu können.

Und den kann man dann noch die Messdaten sammeln und speichern lassen, oder ist der mit Netzwerken schon ausgelastet?

Naja, wär' schon nett, aber eine einfache serielle Schnittstelle würde auch reichen.

Grüße Flo

Wenn man sich die Stomversorgung/Energieverwaltung baut sollten ein paar zusätzliche Dataflashs kein problem sein.

Ich hab schon versuche mit einem FM24c16 als zwischenspeicher und einer

128Mb MMC gemacht. Wenn keine hohe Geschwindichkeit gefordert ist geht das.

--
MFG Gernot

snipped-for-privacy@gmx.net (Gernot Fink) schrieb:

SD-Card sollte doch fast noch einfacher sein, oder? Das ist doch schon ein SPI-Protokoll, wenn mich nicht alles täuscht, außerdem kann man bei Bedarf die Karte rausnehmen und woanders auslesen.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Hallo Joerg

Eine Flash Karte, SD oder MMC, als Massenspeicher wär schon schön, aber vielleicht ist das erst was für Version 2.0, allerdings brauch ich viel Platz gleich von Anfang an. Mal sehen was es mit diesem SPI Protokoll auf sich hat.

Grüße Flo

MMC kann genau wie SD SPI. Leider unterstützen beide Karten meist nur

512 byte grosse Blöcke. Das ist fur die in frage kommenden Microcontroller meist zu viel.

Um die Karten unter Windows auszulesen wird ein Dateisystem darauf benötigt. Das erfordert noch mehr puffer im controller.

Achja die Atmel Dataflashs benutzen auch eine SPI-schnittstelle, haben aber 2

264 byte grosse Puffer eingebaut. Die Blockgrösse ist auch 264 byte.

--
MFG Gernot

Gernot Finkschrieb: "

Deshalb schrieb ich auch zu Anfang, man sollte nicht den kleinsten Controller nehmen. ATMega32 mit 2k RAM sollte dafür völlig reichen. Aber wenn man unbedingt noch 2 EUR sparen muss...

Das handling unter Windows wäre mir das zumindest wert.

Nur sind die erst in großen Stückzahlen bei Ineltek zu vernünftigen Preisen zu bekommen.

Dirk

SPI ist wie i2c ein serieller Bus, aber mit getrennten Pins für Din, DOut und mit CS für jeden Baustein.

Wenn Du VIEL Platz brauchst: ST M25P32. 32 MBit mit 256 Byte Pages sollten doch erstmal reichen, und ein SO8 ist auch noch handlich.

Bei SPI-EEPROMs/Flashes gibts einen Befehlssatz-Standard. MMC/SD-Karten halten sich an den leider nicht, sondern haben was eigenes. Mit freundlichen Grüßen

Frank-Christian Krügel

Hallo,

ich hab mir sagen lassen, dass das mit den SD gar nicht so tragisch sei, wenn man sie einmal im PC formatiert und eine einzige Datei mit FFFFFF... anlegt, die dann vom µC nur überschrieben werden. Man braucht dann nur zuerst nach den FFFs zu suchen, damit man weiss ab welcher Adresse man schreiben darf, ohne das Filesystem zu killen ;-). Die so erstellte Datei kann man dann auch leicht auslesen und wieder auf ein gesundes Maß stutzen. Dauert zwar beim Lesen, macht aber wohl die Programmierung schlank. Die 512 Byte Blockgröße sei auch nicht das Problem, weil man wohl beliebig langsam schreiben darf. Nur sollte man wohl den Block dann mit Dummy-Werten zuschreiben, bevor man das Teil herausnimmt. Alles vom Hörensagen, bin noch nicht dazu gekommen es ausuprobieren. Kann das hier jemand bestätigen oder verwerfen?

Danke

MArte

Marte Schwarzschrieb: "

Warum soll das nicht gehen? Es fehlt dann zwar ein EOF, bzw. man schreibt es gleich mit drauf und hat dann eine Menge FFFFs, aber damit kann man sicher gut leben. Ist sicher die einfachste Lösung, wenn Win die Sectoren ordendlich hintereinander kettet, was frisch formatiert aber so sein sollte. Vielleicht nochmal defrag 'drüber laufen lassen ;-))

Dirk

Hallo Rainer,

Kleiner Nachtrag: "Miss Hiss" ist gestern schon wieder ausgebuechst. Das sah so aus, als haette sie sich ein Loch in die Seite des Gebaeudes gebrochen und ist da hinausgekrochen. Es handelt sich um eine 5 Meter lange Python. Dieses Mal wurde sie von fuenf Leuten in einen Laster getragen und erst einmal zum Tierheim gebracht. Sie darf jetzt nicht mehr bei Herrchen wohnen und es muss ein neues Zuhause gefunden werden.

Regards, Joerg

Hallo Joerg

Oh, die Ärmste.

Dazu passend:

Grüße Flo

"Florian Rist" schrieb:

Na ja, ich bin Dipl.rer.soc. aber ich entwickle ständig uC Applikationen für Diesen und Jenen, tschja, so kann's kommen...

Du könntest das Bastelprojekt

"abkupfern"...

Statt 16C71 nimmst du den viel billigeren 16F627, der ist pinkompatibel. Die Software musst du geringfügig ändern (__CONFIG) und für das I2C kannst du ja auch ein grösseres Modell nehmen (Auch Software ein wenig ändern, andere Ansteuerung ab 24C08, glaub').

Sollte kein Problem sein, alles modular.

Ich hab' das mal vor Jahren gemacht. So, wie es ist, funktioniert es, d.h. es loggt, speichert Daten ins EEPROM und lässt sich über RS232 zu manchem überreden, z.B. zur Herausgabe der gespeicherten Daten...

Allerdings ist *alles* in Software gemacht, RS232, I2C, der Interpreter für die Befehle via RS232 u.s.w. Du kannst das natürlich so übernehmen, du kannst aber auch die Hardware des 16F627 benutzen, ganz wie du willst...

Quellcode liegt ja bei, also beiss dich durch (den Reisberg, der ins Schlaraffenland führt :)

Rüdiger

Na ja, "*Sir* Hiss" ist ja klassisch!

Hallo Florian,

Ist sie auch. Wenn man schon Tiere haelt, muss man auch bis zu deren Lebensende fuer sie da sein und ein artgerechtes Zuhause bieten.

Pythons koennen ein Kind erwuergen. Aber vielleicht ist es ja auch wie bei grossen Hunden, alles eine Frage der Erziehung (von Hund und Kind).

Gruesse, Joerg

"Florian Rist" schrieb:

Erstens: Warum willst du *jedesmal* die Zeit abspeichern, wenn von vorneherein feststeht dass "alle 5 Minuten" gemessen wird?

Zweitens: Wenn nur 12 bit pro Messung anfallen (echt, so viel?), würde ich auch nur 12 bit abspeichern.

Drittens: Warum 32 bit für die timestamp? (Willst du wirklich fast 40 830 Jahre abdecken bei fixen Fünfminutenintervallen? (2^32 / (288 * 365.25))

Tschja, nach 61 Tagen ist mit 120 bit pro Messzeitpunkt (10 Sensoren) und mit

288 Messzeitpunkten/d rund die Hälfte deiner 500 kB (4Mbit) voll belegt, wohl wahr; aber das mit den 32 bit für die timestamp kommt dann bei Weitem nicht hin d.h. der Speicher ist/wäre viel früher voll! Typisch übrigens, das zu unterschätzen (obwohl man es doch, wie hier gezeigt, im Kopf überschlagen kann)...

P.P.S.: Solche Programmiererei ist PC-like d.h. man kommt bei uC's *immer* mit mindestens einer (wenn nicht zwei) Grössenordnung(en) weniger Ressourcen aus, wenn man sich die Sache *vorher* gut überlegt!

Hi!

Nunja, in dieser Applikation würde man den Schreibzyklus wohl lieber beenden, damit man die Karte für die nächsten fünf Minuten "entsaften" kann.

Gruß, Michael.

Wie hoch ist denn dein Preislimit?

Schau mal auf

Ciao Ralf