Controller und Speicher

Gast #448738
Guten Abend zusammen! :)

Ich bin gerade in der Planungsphase für ein kleines Projekt und hätte 
gerne mal Euren Rat dazu.
Also, mein Ziel ist es einen Datenlogger zu basteln, der über einen 
gewissen Zeitraum drei Zeitverläufe aufnimmt und speichert. Innerhalb 
von einer Stunde fallen nach meiner Berechnung 72,12kByte an (und eine 
Stunde sollte er schon aufnehmen können). Also ist die minimale 
RAM-Größe 128kB, damit ich auch noch etwas Spielraum für Erweiterungen 
habe.
Als µC hatte ich den Atmega8 ins Auge gefasst, da er ausreichend schnell 
ist und genügend Reserve für kleinere Erweiterungen bietet. ... Dachte 
ich zumindest, bis ich zu dem Punkt kam, als ich mich damit beschäftigen 
musste den Speicher zu Planen. 20 freie Portpins müssten ja schon dafür 
herhalten.

Liege ich damit soweit richtig?
Wenn ja: Welchen µC/SRAM-Baustein würdet Ihr empfehlen?
Wenn nein: Seid bitte nachsichtig mit mir. Ich versuche zu lernen. :)

Mit den besten Grüßen Marcus
Gast #448747
Hallo Aufreger, hallo Hauke! :)

Danke schonmal für die schnelle Antwort.
Ich dachte eigentlich an SRAM, weil mir dabei auf Anhieb einleutet, wie 
ich es ansteuern muss. Also eigentlich aus Purem Respekt vor seriell 
ansprechbaren Speichern. :)
Man will sich ja als Anfänger auch nicht übernehmen.
Aber jetzt mal zu Eurem Vorschlag mit dem Flash-Speicher. Könnt Ihr mir 
dazu eine Quelle empfehlen, damit ich mich genauer einlesen kann?
Dann fällt es mir sicher leichter abzuschätzen, ob ich mir das schon 
zutrauen kann.

Gruß Marcus
#448749
Was soll mit den 76,12 kByte anschließend passieren? (seriell an PC, 
Transport über Wechselspeicher, Analyse im µC...)

Wie häufig werden die Daten erfasst? (EEPROMs sind ca. 100.000x 
wiederbeschreibbar...)

Die einfachste Lösung ist bestimmt die Zwischenspeicherung auf ein 
EEPROM und anschließende serielle Übertragung.
Gast #448759
@Ronny: Danke für den Link ich schaue ihn mir gerade an. Du hast recht. 
Ich messe wirklich nicht  mit einer besonders hohen Frequenz. Daher 
sollte die Geschwindigkeit des Speichers relativ egal sein.

@Jörg: Die Daten sollen an den PC übertragen und ausgewertet werden. Ich 
denke der Lebenszyklus eines EEPROMS ist mehr als ausreichend. :)
Gast #448760
Hätte auch einen Datenlogger anzubieten. Ist älteren Datums (2002 oder 
so) mit Mega32, 2 Latches und 128kB SRAM. SRAM ist Batteriegepuffert, 
verliert also nix, geht aber nur bis max. 128kB, da die einen nicht 
negierten CS - Pin haben. DCF-Uhr ist dran, misst auf 8 Kanälen im 
Sekundentakt. Schaltplan hab' ich leider nur vom Nachfolger mit 3 
Latches und 512kB Speicher, wenn Interesse besteht kann ich den ja als 
JPG posten.
Gast #448767
Hallo Sonic!

Ich weiss nicht, ob ich Dein Angebot richtig verstanden habe, aber ich 
würde den Datenlogger doch sehr gerne selber bauen. Sonst lerne ich ja 
nichts. :)
Denen Schaltplan würde ich mir aber sehr gerne ansehen. Das wäre 
wirklich klasse, wenn Du bereit wärst ihn hier zu posten.
Pufferung über Batterie habe ich auch vorgesehen. Allerdings wollte ich 
das ganze Board darüber versorgen. Nur den SPeicher zu versorgen wäre 
wahrscheinlich schlauer. Danke für den Tipp.

Gruß Marcus
Gast #448771
OK, dann stell' ich das Teil mal 'rein. Die Batteriepufferung ist bei 
diesem Teil nicht drin, weil er keinen nicht invertierten CS-Pin hat. 
Wie gesagt - ist älteren Datums, heute würde ich auch zu SD-Karten 
tendieren. Materialkosten sind ungefähr gleich, aber um ein Vielfaches 
mehr Speicher.
Ich hoff' mal du kannst was damit anfangen!
Angehängte Dateien:
Gast #448775
Super danke!
Ich denke ich muss noch etwas lesen, bis ich mich entscheiden kann.

Die SD-Karte hat natürlich den Reiz, dass man bei ihrer Benutzung auf 
die serielle Datenübertragung zum PC verzichten könnte. Aber wie groß 
wird der Programmieraufwand, wenn man die Daten gleich in einem 
auswertbaren Format auf der Karte ablegen will?
Gast #448776
Da gibt's schon einige gute Sachen, die schon eine FAT32 oder FAT16 auf 
die SD-Karte machen, dann kannste das am PC über den Kartenleser 
'rüberziehen. Hab' nur rade keinen Link parat ..
Persönliche Seite #448795
Alle pins die man nich braucht vorher mit m cutter wegschneiden :P Dann 
ist der einfacher zu löten.

Ne mal im ernst ... SD-Karte finde ich am Sinnvollsten, da du dir so die 
Serielle PC anbindung sparst, viel Speicher zur verfügung hast, falls du 
die ganze geschichte mal erweitern willst/länger laufen lassen willst.
Und du hast sehr wenige leitungen.
Gast #448798
@André:

Hast du schonmal mit einem AVR-Program den Flash selbigen AVRs 
beschrieben?Dank Harvard-Architektur ist das nicht ganz sooo einfach.Vor 
allem wen die Anwendung nicht in den Bootloader-Bereich passt...
Gast #448804
Hallo Andre :)

In der dritten Person ist wirklich lange nicht mit mehr mit mir 
gesprochen worden. lach
Nachdem ich gerade mal die Anforderungen für SD-Karten, die man mit 
einem FAT16-Dateisystem beschreiben will, überflogen habe, muss ich 
feststellen, dass ich auf jeden Fall mehr Speicher brauche. Ob ich das 
jetzt mit einem anderen Controller oder zusätzlichem Speicher mache muss 
ich mir noch überlegen. Vor möglichen Fehlern und dem größeren Aufwand 
fürchte ich mich eigentlich weniger. Ich lerne ja dabei. :)
Auch wenn die Beträge nicht die Welt ausmachen, finde ich es doch immer 
sschöner, wenn man mit möglichst wenig finanziellem Aufwand ein Aufgabe 
löst.
Aber vielen Dank für den Link. So eine Übersicht Hilft sehr beim 
Grübeln.

Gruß Marcus
Gast #448812
Die seriellen Flashs (SPI) besitzen meistens(immer?) eine Chip-Enable 
Leitung.Wenn man die an einen normalen I/O hängt,kann man mehrere der 
kleinen Flashs an einen Mikrocontroller hängen.Über I/O-Multiplexer auch 
deutlich mehr Flashs als I/O-Pins am Mikrocontroller verfügbar sind.Ist 
dann natürlich jedesmal mit einem weiteren IC pro Flash verbunden.Wenn 
man nur einige MB benötigt,macht sich das wirklich gut.Wenns deutlich 
mehr als 8MB werden soll,ist dann die bereits erwähnte SD-Karte die 
bessere Wahl.Allerdings ist man dann entweder auf ein FAT-Lib angewiesen 
(die es frei verfügbar geben sollte) oder beschäftigt sich einige Tage 
mit einem antiquierten Dateisystem.Allerdings ist das Einbinden einer 
Lib bei entsprechend großen Controllern dann auch nicht mehr das 
Problem.
Gast #448824
Bevor ich mich für heute verabschieden muss möchte ich mich noch 
rechtherzlich bei Euch allen für Eure Auskunftsfreude, die ANregungen 
und Tipps bedanken.
... ach ja und natürlich habe ich auch noch eine Frage ;)
Da mir die Idee mit der SD-Karte sehr gut gefällt habe ich überlegt, ob 
es Sinn machen könnte, die Daten ersteinmal auf einem EEPROM zu 
speichern, da ich ja sowieso zusätzlichen Speicher benötige. 
Anschließend könnte der µC auf Anforderung die Daten in einem FAT16 
Dateisystem auf die SD-Karte schieben. So hätte ich zwei schön 
übersichtlich getrennte Programmteile.
Andererseits hätte ich dann aber auch einen deutlich größeren Aufwand an 
Speicher, als wenn ich die Daten direkt auf die SD-Karte schiebe.

Was wäre Eurer Meinung nach die sinnvollere Lösung? Oder doch ganz 
anders?

Also bis hoffentlich Morgen. Ich wünsche eine Gute Nacht. :)

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 19 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.