Festspeichererweiterung Atmega 32

[eule22]

Guten Morgen zusammen,

ich habe mal wieder ein kleines Problem und wende mich vertrauensvoll an euch.

Es geht um folgendes: Ich habe einen Atmega 32, der als Ladeüberwachung für 4 NiMh Akkus dient. Jetzt ist Ziel meiner Arbeit die Ladekennlinie der 4 Akkus aufzuzeichnen, sodass sie zu einem späteren Zeitpunkt am PC ausgewertet werden könne. (Die Ladekennlinie kann beim nächsten Ladevorgang im selben Schacht wieder überschrieben werden)

Bei kurzem Rechnen kam ich zu folgender Feststellung:

2 Byte pro Messwert x ca. 1000 Messwerte pro Ladkurve x 4 = ca. 8 Kb.
Eigentlich wollte ich das ganze im EEPROM Speichern, sodass die Daten auch nachdem das Ladegerät von Spannung getrennt war noch erhalten sind. Aber das hat ja leider nur 1024 Byte. Das könnte etwas knapp werden ;-)

Jetzt habe ich mir folgende Gedanken dazu gemacht:
1. Speichererweiterung durch SD Karte.
2. Speichererweiterung durch externes EEPROM.
3. Atmega mit einer Pufferbatterie versorgen, sodass Daten auch nach Stromasufall vorhanden bleiben. (jedoch weiß ich nicht ob das so einfach ist, und der Speicherplatz dim RAM dafür ausreichend ist) oder anderen externen Baustein mit Pufferbatterie versorgen, um speichern zu ermöglichen (externes RAM)

Was haltet ihr davon? Was ist die einfachste Möglichkeit, und wozu gibt es möglicherwieise schon vordefinierte Funktionen die das schreiben und lesen ermöglichen?

Gruß und Dank

[021aet04]

Ich würde es auf einer SD Karte o.Ä. speichern. Ich würde die Daten als CSV auf speichern, damit kannst du es mit z.B. Excel weiterverarbeiten. Ich weiß zwar nicht wie oft du die Daten speicherst (die Akkus lädtst), aber die EEPROMS haben nur eine bestimmte Anzahl an Schreib/Lesezyklen. Wenn diese überschritten wird müsstest du das IC ausbauen und gegen einen neuen ersetzte. Die SD Karte kannst du leicht besorgen, für andere Geräte verwenden und von jedem PC/Laptop lesen. Beim EEPROM brauchst du ein Programm (selbst schreiben) und noch Hardware, damit du diesen auslesen kannst.

MfG Hannes

[oberallgeier]

... Atmega 32 ... 4 Akkus aufzuzeichnen ... im EEPROM Speichern ... hat ja leider nur 1024 Byte ...Da wäre noch der Punkt
4. Atmega 32 duch den pinkompatiblen mega644 ersetzen.

Im Weihnachtsangebot hat der ATmega644 schon mal 4 kByte SRAM und 2 kByte EEPROM - doppelt so viel wie der m32. ABER: das EEPROM kannst Du nur 100 000 mal beschreiben, schau mal ins Datenblatt . . . .

[eule22]

Das klingt schon mal vernünftig, genau in diese Reichtung heben sich meine Gedanken auch bewegt. Das würde mir die direkte Kommunikation zwischen Controller und PC sparen.
Das mit den Schreibzyklen auf das EEPROM wäre sicher nicht das problem, da die ja irgendwo in nem bereich zwischen 100000 und 1000000 liegen. Und die kommunikation würde ich eben über RS232 oder USB mit dem PC herstellen.
Jedoch finde ich es per SD Karte wesentlich bequemer. Gibt es irgendwo fertige Funktionen wie ich in dem CSV Format vom MC abspeichern kann, und nen Schaltplan wie ich die SD Karte anschließen kann? Ich programmiere in C mitWin AVR. und der Controller läuft mit 5V

[hunni]

wie wäre es mit einen 24xx EEprom, ganz einfach anzusrechen und groß genug zum speichern.
ansonsten wäre der atmega644 das richtige.

[021aet04]

Hier habe ich etwas gefunden
https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=48696

MfG Hannes

[eule22]

Jetzt nochmal ne dumme Frage zum Mega644:
Der hat 4 KB SRAM und 2KB EEPROM = 6 KB Speicherkapazität.

Jedoch bentötige ich mit meinen 4 Kennlinien ca. 8Kb. Oder habe ich da einen Denkfehler in meiner Logik?
Zudem bin nicht an eine Pinkompatibiliät mit einem Mega32 gebunden, er sollte nur in einem Steckbrettfreundlichen Gehäuse sein. Der läuft bei mir so und so bis jetzt nur auf einem Steckbrett. Eine fertige Schaltung gibt es bis jetzt noch nicht. Ich probiere zunächst mal die ganzen Komponenten auf Steckbrett, und wenn dort alls zu meiner Zufriendenheit läuft, erst dann mache ich mich an die eigentliche Schaltung.

@ Hannes: Danke für den Link, das ist im Prinzip genau so etwas wie ich suche. Hat jemand von euch Erfahrungen welche Typen Speicherkarte sich so ansprechen lassen und wie groß die maximale Speicherkapazität sein darf? Hab gelesen, da soll es mit nachen Typen Probleme geben?

@ Hunni: Was ist das für ein Typ EEPROM? Wie wird er angesprochen? Hab von den Teilen noch nichts gehört.

Gruß und dank

[hunni]

also das EEprom wird über i2c angesprochen. Dieses zum beispiel ist ein 2k eeprom:
http://www.ak-modul-bus.de/stat/serielles_eeprom_24c02.html

es gibt aber auch noch welche mit 8 K und mehr.

Ach ja es gibt für speicherkarten avr-dos. Musst du mal nach suchen, dass speichert die sachen direkt in eine txt datei auf der sd karte.

[021aet04]

Hast du ein paar Speicherkarten z.B. von Digicams zum Testen? Die einzigen Probleme von denen ich gehört habe ist die max. Speicherkapazität, die man verwenden kann. Habe aber noch nichts mit Speicherkarten gemacht.

MfG Hannes

[PICture]

Hallo!

@ eule22

Ich würde auf deiner Stelle die Auflösung und Anzahl der Messwerte verringern. Brauchst du fürs Akkuladen wirklich solche Genauigkeit ?

MfG

[oberallgeier]

Eigentlich wollte ich mir so eine Argumentation sparen, ich denke die meisten Leute rechnen so etwas selber.

... NiMh Akkus ... 2 Byte pro Messwert x ca. 1000 Messwerte pro Ladkurve x 4 = ca. 8 Kb ...Rechnen wir mal mit einer Ladezeit von 10 Stunden <=> 36000 Sekunden <=> alle 36 s ein Messwert. Vermutlich würde ein Viertel reichen - ca. alle 2 min ein Messwert - und 10 % würden es wohl auch tun. Vermutlich reicht auch eine 8bittige Auflösung. Irgendwann würde vermutlich ein mega8 reichen. SMALL is beautiful!

[eule22]

halt stopp oberallgeier:
Schon mal was von einer -delta U abschaltung gehört?
Dafür lädst du den Akku mit C/2 bis C und erkennst an dem Verlauf der Ladekennlinie wann der Akku voll ist. Und so etwas mach ich, damit lade ich keine 10 stunden sondern nur etwa 1,5 - 3h (je nach Ladestrom). Zu dem -deltaU: Das erkennt, wann die maximale Akkuspannung erreicht ist = Akku voll. Wir dann weiter geladen, also überladen, so sinkt die Spannung wieder minimal ab. Und dieses minimale Absinken der Akkuspannung nennt man eben -deltaU und wird als abschaltkriterium für den Ladevorgang benutzt. Je weniger die Akkuspannung beim vollen Akku absinkt, desto schonender für den Akku. Und deshalb komme ich mit einer 8 Bit Messung nicht sehr weit. 10 Bit sind schon sehr grenzwertig.
Und selbst wenn ich die Messwerte nicht so häufig nehme werde ich wohl auch nicht um eine externe Speicherquelle herum kommen. Ich möchte schließlich auf der Kennlinie später was erkennen können.
Wo ich dir rechtgeben muss. Vorerst würde ein Mega 8 ausreichen. Jedoch habe ich an dem zu wenig frei programmierbare I/O Pins um 4 Akkus gleichzeitig zu laden und noch ein Display sowie ein paar Taster zu Steuerung anzuschließen.

[PICture]

Es gibt auch noch eine Möglichkeit nur die bedeutende Werte, die sich von vorherigen unterscheiden mit Zeitstempel zu speichern.

MfG

[eule22]

Hm, das eröffnet gerade ganz neue Möglichkeiten!
Daran hab ich ja noch gar nicht gedacht. Und es würde sogar das interne EEPROM Reichen, notfalls das des mega644.
Hätte aber einen Nachteil:
Man würde nur eine idealisierte Kennlinie bekommen. Und das ist eigentlich auch nicht Ziel meiner Messung, ich möchte gerne eine relaistische Kennlinie haben. Zum verdeutlichen des ganzen Mal eine Kennlinie im Anhang, wie ich sie momentan aufnehme (via USART direkt an den PC). Und man kann halt deutlich die Spannungseinbrüche am Akku sehen, und das hätte ich schon gern in den zukünftigen Kennlinien erhalten.

[PICture]

Was verstehts du unter "idealisierter Kennlinie" ?

Wenn du die mikrigen "Picks" meinst, dann muss ich dich fragen, was für eine Bedeutung für dich sie haben ? Möchtest du sie wirklich sehr deteiliert analisieren ? Was für Infomationen sie dir bringen ? Ehrlich gesagt, sie sehen für mich eher als Störungen.

MfG

[eule22]

Zu idealisierte Kennlinie: Wenn ich jetzt nur den Wert übernehme, der höher ist als der vorhergehende und dazu einen Timestap ablege, bekomme ich ja eine ideale Kennlinie.

Bislang waren diese "Peaks" sehr wichtig, dann ich musste mir ja einen entsprechenden Programmcode schreiben, der genau diese Peaks ignoriert und wirklich erst dann abschaltet, wenn der Akku voll ist.
Dies hätte ich eigentlich gerne weiterhin beibehalten, um einfach die richtige Funktion des Laders zu kontrollieren.

[PICture]

Ich denke, dass du etwas nicht richtig verstanden hast. Die bedeutende Werte, die sich von vorherigen unterscheiden, können doch auch kleiner sein. Somit wird die Kennlinie nur in der Zeitachse komprimiert und kein Wert wird verlorengehen, oder ?

MfG

[oberallgeier]

... Schon mal was von einer -delta U abschaltung gehört ...Hab ich schon - aber Du wohl noch nix von dynamischer Stützpunktverteilung.

[eule22]

@ Oberallgeier:
Nein habe ich noch nicht, klär mich bitte auf!

@ PICture: Je läger ich darüber nachdenke, desto stimmiger wird das ganze! Ich glaube das werde ich mal ausprobieren mit den nur die bedeutenden Werte mit Zeitstempel abzuspeichern. Das könnte dann sogar mit internem EEPROM eines 644 funktionieren.
Danke für den Denkanstoß!!

[hunni]

Also für alle die ein EEProm noch proggen möchten:
http://www.rn-wissen.de/index.php/Bascom_und_I2C_EEprom
Ließ dir einfach mal durch, ist nich besonders schwer. Letztens hab ich übrigens eins mit 4 MBIT gesehen, weiss aber nicht mehr wo.... Naja mit ein bisschen lück findest du das vielleicht wieder.
Gruß Hunni

[eule22]

@ Hunni: Dankeschön, das ist sehr hilfreich! Wenngleich es auch für Bascom ist.
Ich muss mich bei dem Type EEPROM mal richtig einlesen, weil von dem was ich in Bascom verstehe (und das ist nicht viel) sieht das recht überschaubar aus.

[oberallgeier]

Dynamische Stützpunktverteilung - anfangs bzw. da, wo wenig passiert auch wenige Messungen, hinterher, bzw. da, wo die Post abgeht, dann mehr. Das was Du vorhattest, ist eine äquidistante Verteilung - die Messabstände sind alle gleich. Aber der Anfangsverlauf ist doch nicht soooo interessant - sagt ja schon das deltaU-Kriterium *ggg*.

DAZU könntest Du Dir als Kriterium die Ladekennlinie nehmen. Ab einem Spannungswert, ab einer bestimmten Ladungsdauer (ist ja wohl nicht so gut) oder ab einer bestimmten Spannungsdifferenz pro Zeiteinheit schaltest Du von "langsam mitschreiben" auf "schnell mitschreiben" um. WENN Du jetzt noch die Zeitstempel mitführen willst (anders wärs ja eh nicht sooo das Wahre) hast Du mit der zeitlichen Zuordnung bei einer späteren graphischen Darstellung sowieso keine Probleme. Beispiel zu einer dynamischen Stützpunktverteilung siehe hier (http://www.diss.fu-berlin.de/diss/servlets/MCRFileNodeServlet/FUDISS_derivate_000000000971/07_kap5co.pdf;jsessionid=A780202A59B6C32B8CA9F61B0 AD25362?hosts=), Seite 65, Abbildung 5.7.

Stützpunkt bedeutet hier : Punkte auf Deiner Ladeverlaufskurve, bei denen Du die Messwerte erfasst hast. Dazwischen weißt Du ja nach Ablauf Deiner Laderei nix. Wer das besonders pfiffig mag, der macht noch ne Glitcherfassung (http://www.elektronikpraxis.vogel.de/themen/hardwareentwicklung/messtechnik/labormesstechnik/articles/35537/) - aber das wirst Du nicht brauchen. Hintergrund ist wie schon oben gesagt: wenn es keine schnellen Änderungen gibt, kann man ja nur hin und wieder messen - und Messaufwand sparen. Organisiert wird das vom Controller - dazu ist der ja da *ggg*.

[Besserwessi]

Um noch weiter Speicherplatz zu sparen könnte man die Daten noch etwa komplimieren: bei der Zeit nur den Abstand zum letzten Punkt speicher und bei der Spannung nur die Differenz zum letzten Wert. So kann man einiges an Bits sparen. Für die Zeit und Spannung könnten dann je 8 Bit reichen. Wenn dann außnahmsweise doch mal ein größerer Sprung kommen sollte gibt es halt einen Wert mit 0 als Differenz.

[hunni]

Ach sorry, ja ich mache eigentlich alles in Bascom, kann zwar ein bisschen C aber das is nich viel. Denke das ist aber einfach zu übersetzen.
Um weiteren Speicherplatz zu sparen, sagst du ihm einfach, dass er erst bei einer differenz von 0,2V den Wert speichern soll, ganz ehrlich, alles andere würde ich uninteressant finden.
glaub mir so viele Werte brauchst du nicht, betreibe nämlich flugmodellbau
und habe viel mit akkus zu tun. die ganzen peaks brauchst du nicht, oder speichere einfach den wert nach jeden peak, dann brauchst du längst nicht mehr so viele und das sind auch die eigentlich interessanten werte.

[eule22]

Ihr bringt mich langsam auf richtig gute Ideen!! Die Idee mit den 2x 8 Bit (für Timestamp und Spannung) ist richtig klasse. Damit lässt sich echt einiges an Speicherplatz sparen.
Woher nehmt ihr diese Ideen nur? Ich auf sowas nie gekommen, gescheige denn auf die Idee, nur die relevanten Messwerte mit Timestamp zu speichern.

[eule22]

Ihr bringt mich langsam auf richtig gute Ideen!! Die Idee mit den 2x 8 Bit (für Timestamp und Spannung) ist richtig klasse. Damit lässt sich echt einiges an Speicherplatz sparen.
Woher nehmt ihr diese Ideen nur? Ich auf sowas nie gekommen, gescheige denn auf die Idee, nur die relevanten Messwerte mit Timestamp zu speichern.

[oberallgeier]

... Woher nehmt ihr diese Ideen nur ...Kein Problem - alles bei den "anderen" Forumsmitglieder geklautabgekupfertgehörterklärtbekommen . . .


... speichere einfach den wert nach jeden peak ...Na ich weiß nicht - gibts dann nicht die Möglichkeit, dass relevante Daten rausfallen? Da wäre ich SEHR misstrauisch.

[Besserwessi]

Das Problem mit dem Speicherplatzsparen kommt öfter mal vor. Teils für den Speicherplatz und Teils wegen begrenzter Übertragungsrate.
So richtig ausgefallen sind die Vorschläge bisher noch nicht, das geht noch einiges effektiver, wird dann aber auch aufwendiger. Die Datenkomprimierung ist schon ganz schön weit entwickelt.

[PICture]

Ich nehme die Ideen aus meinem Kopf, weil ich mit überdurchsnittlicher Phantasie geboren bin und danach viel reales gelernt habe... :)

MfG

[hunni]

Habe hier noch mal einen informativen Artikel rausgesucht, guck zum beispiel bei siemens, der hat 8 kbyte speicher