Datenlogger mit uC basteln

Joerg Wunsch <j@ida.interface-business.de> dixit:
Florian Rist <frist@fs.tum.de> schrieb:

Ich möchte einen Datenlogger bauen, an den verschiedene digitale
Sensoren angeschlossen werden können sollen. Die Messwerte sollen
gespeichert und später mit einem PC ausgelesen und
weiterverarbeitet werden. Soweit mal nicht allzu Spannend, aber
auch nicht ganz einfach.

Guck dir doch mal den AVR Butterfly an.
Aehm, ja..., klein, preiswert. Aber der OP runzelte bei der
Moeglichkeit des Abspeicherns von "nur" 8000 Messwerten bei einer
anderen Technik bereits die Augenbrauen und ich befuerchte, ohne
externen Speicheranbau wird es knapp mit den Butterfly-Ressourcen.
Ich wies an anderer Stelle in diesen Thread einmal auf
http://www.ethernut.de/ hin.

Grusz,

Peter Blancke

--
Hoc est enim verbum meum!
 
Hallo Joerg

Guck dir doch mal den AVR Butterfly an.
Danke, für den Hinweis.

Aehm, ja..., klein, preiswert. Aber der OP runzelte bei der
Moeglichkeit des Abspeicherns von "nur" 8000 Messwerten bei einer
anderen Technik bereits die Augenbrauen und ich befuerchte, ohne
externen Speicheranbau wird es knapp mit den Butterfly-Ressourcen.

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

Ich habe zwar selber noch keinen praktischen Einsatz dafuer gehabt,
aber wenn Du Programmierkenntnisse hast, ist eventuell das
Ethernut-Projekt fuer Dich interessant. Guck mal rein:

http://www.ethernut.de/
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.

Die Platine ist AFAIK komplett fertig beziehbar, auf der Platine
werkelt ein AVR-Controller.
Und den kann man dann noch die Messdaten sammeln und speichern lassen,
oder ist der mit Netzwerken schon ausgelastet?

Fuer Din Vorhaben ist sicherlich die
On-Board-Ethernet-Schnittstelle von Bedeutung.
Naja, wär' schon nett, aber eine einfache serielle Schnittstelle
würde auch reichen.

Grüße
Flo
 
In article <iai6g11uepo3njqnvfle1qjq6o9jvd447h@4ax.com>,
Florian Rist <frist@fs.tum.de> writes:
Hallo Joerg

Guck dir doch mal den AVR Butterfly an.

Danke, für den Hinweis.

Aehm, ja..., klein, preiswert. Aber der OP runzelte bei der
Moeglichkeit des Abspeicherns von "nur" 8000 Messwerten bei einer
anderen Technik bereits die Augenbrauen und ich befuerchte, ohne
externen Speicheranbau wird es knapp mit den Butterfly-Ressourcen.

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.

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.

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
 
Peter Blancke <blancke@gmx.de> schrieb:

Guck dir doch mal den AVR Butterfly an.

Aehm, ja..., klein, preiswert. Aber der OP runzelte bei der
Moeglichkeit des Abspeicherns von "nur" 8000 Messwerten bei einer
anderen Technik bereits die Augenbrauen und ich befuerchte, ohne
externen Speicheranbau wird es knapp mit den Butterfly-Ressourcen.
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

Ich hab schon versuche mit einem FM24c16 als zwischenspeicher und
einer 128Mb MMC gemacht. Wenn keine hohe Geschwindichkeit gefordert
ist geht das.

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.
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
 
g.fink@gmx.net (Gernot Fink) schrieb:

Ich hab schon versuche mit einem FM24c16 als zwischenspeicher und
einer 128Mb MMC gemacht. Wenn keine hohe Geschwindichkeit gefordert
ist geht das.
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. ;-)
 
In article <de067u$1kft$1@uriah.heep.sax.de>,
j@uriah.heep.sax.de (Joerg Wunsch) writes:
g.fink@gmx.net (Gernot Fink) schrieb:

Ich hab schon versuche mit einem FM24c16 als zwischenspeicher und
einer 128Mb MMC gemacht. Wenn keine hohe Geschwindichkeit gefordert
ist geht das.

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.

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:
"
In article <de067u$1kft$1@uriah.heep.sax.de>,
j@uriah.heep.sax.de (Joerg Wunsch) writes:
g.fink@gmx.net (Gernot Fink) schrieb:

Ich hab schon versuche mit einem FM24c16 als zwischenspeicher und
einer 128Mb MMC gemacht. Wenn keine hohe Geschwindichkeit gefordert
ist geht das.

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.

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

Achja die Atmel Dataflashs benutzen auch eine SPI-schnittstelle, haben aber 2
264 byte grosse Puffer eingebaut. Die Blockgrösse ist auch 264 byte.
Nur sind die erst in großen Stückzahlen bei Ineltek zu vernünftigen
Preisen zu bekommen.

Dirk
 
On Wed, 17 Aug 2005 22:40:48 +0200, Florian Rist <frist@fs.tum.de> wrote:

Hallo Joerg

Ich hab schon versuche mit einem FM24c16 als zwischenspeicher und
einer 128Mb MMC gemacht. Wenn keine hohe Geschwindichkeit gefordert
ist geht das.

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.

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

Bei SPI-EEPROMs/Flashes gibts einen Befehlssatz-Standard. MMC/SD-Karten
halten sich an den leider nicht, sondern haben was eigenes.
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:
"
Hallo,

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

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

http://www.analogconsultants.com
 
Hallo Joerg

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.
Oh, die Ärmste.

Dazu passend:


http://www.sueddeutsche.de/panorama/bildstrecke/140/55085/p0/?img=1.0#bild


Grüße
Flo
 
"Florian Rist" schrieb:
Stimmt, aber ich bin eigentlich Architekt, also Jedenfalls Dipl. Ing.
Arch., und da sind wohl auch in Zukunft ľController eher ein
Randgebiet. :)
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
http://homepage.ruhr-uni-bochum.de/Ruediger.Klenner/platine/index2.html
"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
 
"Johannes Bauer" schrieb
Joerg wrote:

"Miss Hiss" hatte Freiheitsdrang und war mal wieder
ausgebuechst, aber bei einem leckeren Futterangebot ueberlegte sie es
sich doch noch mal.

"Miss Hiss" ist aber auch wieder so ein origineller Name für eine
Schlange. Wie "Hoppel" für Hasen oder "Bello" für Hunde. Muss ich mir
merken ;-)

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

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

Dazu passend:

http://www.sueddeutsche.de/panorama/bildstrecke/140/55085/p0/?img=1.0#bild
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

http://www.analogconsultants.com
 
"Florian Rist" schrieb:
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.
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!
 
Dirk Ruth <d.ruth@itecnet.de> wrote:

Hi!

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

On Tue, 16 Aug 2005 21:39:48 +0200, Florian Rist wrote:

Im Moment stehe ich aber nu vor der Wahl für ein paar hundert EUR
Equipment zu leihen oder mir was passendes zu basteln/kaufen.
Wie hoch ist denn dein Preislimit?

Schau mal auf

http://www.msr.ch/de/


Ciao Ralf
 

Welcome to EDABoard.com

Sponsor

Back
Top