www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR Ladekurvendisplay


Autor: Michael K. (mmike)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

ich hab mir vor kurzem nen Orbit Pocketloader (Ladegerät für den 
Modellbau) besorgt und das Ding hat eine SIO (Seriell - In - Out, also 
RS232) Schnittstelle. Am Oszi kamen brav 5V (TTL) raus und damit bin ich 
dann direkt auf meinen AVR. Daten kommen und ich kann sie auswerten und 
lesen. Jetzt würde ich gerne die die Ladekurve graphisch auf einem 
128x64px Display darstellen. Display ist auch vorhanden und läuft. Jetzt 
zu meinem "Problem".

Die Darstellung der Ladekurve soll über die Zeitachse dynamisch 
verlaufen (Skalierung: von 30min bis 2h). Jede Sekunde wird ein 
Datensatz vom Ladegerät ausgegeben mit Zeit, Spannung und Ladestrom. Die 
Daten werden natürlich im Display permanent angezeigt.
Für die Ladekurve stehen 120 Pixel in der Breite zur Verfügung. Also:

120px -> 30min -> Pixel jede 15s
120px -> 60min -> Pixel jede 30s
120px -> 90min -> Pixel jede 45s
120px -> 120min -> Pixel jede 60s

soweit so gut. Jetzt ist nur das Problem, wenn ich die Zeitachse 
umschalte von beispielsweise 30min auf 60min und das Display neu 
aufgebaut wird, dann müssen die bereits gemessenen Werte (Spannung und 
Strom) ja noch vorhanden sein. Die kleinste Zeitbasis ist ja 15s. Also 
lege ich alle 15 Sekunden einen Datensatz im Speicher ab. Und genau hier 
ist die Frage welcher Speicher.

2h (max Logzeit) = 120min = 7200s

7200s / 15s = 480 Datensätze

Speicherbedarf: 480 * 4 bytes = 1920 bytes.

Das ist leider schon zu viel für meinen ATMega32. Jetzt war der Ansatz 
entweder die Daten in einem EEProm (AT24C128 mit 128k) abzulegen, aber 
der macht "nur" 100.000 Schreibzyklen, dann ist er hin. Eine Alternative 
wäre der ATMega644 mit 4k SRAM. Wenn ich dann sparsam mit Variablen 
umgehe sollte es eigentlich reichen.

Gibts sonst noch "schicke" Alternativen, Ideen oder Anregungen ?

Grüße
Michael

PS: Externer SRAM wäre auch noch ne Variante, aber schon ganz schön 
"heftig" von der Software - Seite her ....

Autor: Ralf Schwarz (spacedog) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du brauchst ja nicht alle 480 Datensätze zu speichern, 120 genügen dir 
ja.
Und wozu brauchst du 4 Bytes pro Datensatz?

Autor: D. W. (dave) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieviel Bit bekommst du von deinem Lader?

Ich glaube auch, dass 16Bit zu viel sind. Wenn du jeweils 8Bit nehmen 
würdest, wärs ja nurnoch die Hälfte vom Speicher.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Jede Sekunde wird ein Datensatz vom Ladegerät ausgegeben mit Zeit,
> Spannung und Ladestrom.

Vermutlich bekommt er 2 byte Zeitstempel, und jeweils 8 Bit Spannung und 
Strom?

16 Bit Zeitstempel wären knapp 18h Ladezeit.

PS: Den Zeitstempel kannst du doch auch weglassen, wenn du weißt, dass 
du immer alle 15 Sekunden einen Messwert nimmst.

Autor: Michael K. (mmike)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ralf: Speicher muss ich leider schon, denn wenn ich die Zeitachse neu 
skaliere und das Display lösche um neu zu zeichnen, dann muss ich die 
Daten ja noch verfügbar haben um sie neu zeichnen zu können.
120 .... ja stimmt ! Mehr wird eh nie angezeit ! Cool ...danke ! Muss 
halt dann im Moment der Skalierung immer den 2. Wert "entsorgen" und das 
Array neu sortieren.


@D. W.:
Der Lader gibt ASCII aus und zwar Spannung in mV und Strom in mA
Ein Datensatz sieht folgendermassen aus:

#N00125,12455,+2500

#: Beginn der Übertragung
N: Ladeprogramm (in diesem Fall Normalladen)
00125: Zeit - 2min 5sec
12455: Spannung [mV] also 12,455V
+2500: Ladestrom [mA] also laden (+) mit 2,5A

Spannung und Strom werden als uint16 gespeichert. 8 bit sind mir da eher 
zu wenig. Zudem müsste ich intern die Werte noch skalieren.

Spannung geht maximal bis 30V, also könnte ich bei der uint16 ein Bit 
einsparen, wenn ich bis 32768 speichere oder wenn ich die Genauigkeit 
nur auf 10mV setzte bis 3276 (12 bit, 4096) dann könnte ich 4 Bit 
einsparen. Selbiges beim Strom. Aber dann wird wieder umständlicher beim 
speichern der Daten .... so nen schönes Array ist halt simple zu handeln 
...

Danke für Eure Beiträge,

Michael

Autor: Michael K. (mmike)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Simon K.: Zeit wird nicht gespeichert !

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael K. wrote:
> @Simon K.: Zeit wird nicht gespeichert !

Ich hab jetzt gedacht, dass die 4 Bytes aus dem Ladegerät kommen. Kann 
ich ja nicht ahnen, dass es gar nicht so ist.

Autor: Michael K. (mmike)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Simon K.: Stimmt das Protokoll hätte ich gleich im "Intertialbeitrag" 
beschreiben sollen.... sorry

Autor: S. Seegel (energizer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde in einem festen Byte-Array (sollte reichen, mehr brauchst du 
für die y-Achse nicht) das 128 Bytes Größ ist die Werte nacheinander 
speichern. Du fängst z.B. mit 30 s / Pixel an, und merkst Dir nur die 
"Pixelrate". Wenn Dein Array voll ist (beim ersten mal also nach 128 * 
30 s = 64 min) schaltest du um auf 60s / Pixel und "stauchst" das Array 
zusammen, indem du entweder jeden 2. Wert löschst, oder jeweils 
Mittelwert von 2 Werten nimmst:
[0] = AVG([0]/[1])
[1] = AVG([2]/[3])
...
Ab nun schreibst du nur noch alle 60 s einen Messwert, beginnend bei der 
Arraymitte. Während diesen 60 s kannst du einen Mittelwert aus den in 
dieser Zeit eingehenden Messwerten bilden. Ist das Display wieder voll 
(nach weiteren 64 min, das Display zeigt nun 128 min über die gesamte 
Breite), geht das Spiel von vorne los: Array stauchen, Pixelrate auf 240 
s / Pixel.

Gruß
Stefan

Autor: Oberlehrer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> "Intertialbeitrag"

LOLz

Wenn dann "Initialbeitrag".

Statt mit irgendwelchem Zeug rumzuspielen, solltest Du noch mal den 
Deutschkurs belegen.

Autor: Hannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Speicherbedarf: 480 * 4 bytes = 1920 bytes.

>Das ist leider schon zu viel für meinen ATMega32.

warum?

Autor: Michael K. (mmike)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan: Du hast wahrscheinlich Recht mit den 8 Bit für die y - Achse da 
die Displayauflösung sowieso nur max. 64px beträgt und hier sowieso 
skaliert werden muss. Somit ist es wahrscheinlich sinnvoller "vor" der 
Speicherung zu skalieren um SRAM zu sparen als "hinterher" bei der 
Anzeige. Die Organisation des Arrays hab ich mir genauso gedacht! Nur 
dass ich anfangs alle 15 Sekunden einen Messwert speicher (30min 
Zeitskalierung).

@Oberlehrer: Vielen Dank für Deinen wertvollen Beitrag. Schreiben wollte 
ich "Inertialbeitrag", aber so Korinthenkacker wie Du können wohl nur 
meckern, haben aber selbst nichts auf dem Kasten ...

@Hannes: Im Endeffekt reichts zum reinen speichern der Daten wohl schon, 
aber die Displayfunktionen brauchen ja auch noch ein wenig SRAM ... 
zudem soll noch nen Servotester, Empfängerausgangspulsmessung, 
Strommessung, opt. Drehzahlmesser,  schönes Menü, 4 Taster ... und und 
und in das Ding rein ...

Danke an alle bis auf Oberlehrer !

Grüße,

Michael

Autor: Sascha Focus (sascha_focus) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es damit ?

http://www.logview.info/cms/d_orbit-pocketlader.phtml

Gruß Sascha

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael K. wrote:
> @Oberlehrer: Vielen Dank für Deinen wertvollen Beitrag. Schreiben wollte
> ich "Inertialbeitrag", aber so Korinthenkacker wie Du können wohl nur
> meckern, haben aber selbst nichts auf dem Kasten ...

lateinisch iners „untätig, träge“

Autor: Michael K. (mmike)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sascha: Das Tool kenn ich schon ! Ist wirklich klasse fürs Logging zu 
Hause, aber am Flugfeld brauchts was kleines Portables.

@Simon K.: okok. Hatte nie Latein. Ist keine Entschuldigung, aber ich 
denke Ihr wisst, was gemeint war. Ich lese lieber Datenblätter als Duden 
und Lateinbücher ....

Grüße,
Michael

Autor: Oberlehrer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> @Oberlehrer: Vielen Dank für Deinen wertvollen Beitrag. Schreiben wollte
> ich "Inertialbeitrag", aber so Korinthenkacker wie Du können wohl nur
> meckern, haben aber selbst nichts auf dem Kasten ...

Inertialbeitrag wär auch falsch gewesen :-)

Autor: Oberlehrer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P.S.:

@Oberlehrer: Vielen Dank für Deinen wertvollen Beitrag. Schreiben wollte
ich "Inertialbeitrag", aber so Korinthenkacker wie Du können wohl nur
meckern, haben aber selbst nichts auf dem Kasten ...

Für das Logging von Zellenspannungen hab ich mir mal einen Logger
mit einem MSP430F2012 + 24C64 gebaut.
Grafische Auswertung geht unter anderem mit einem Palm.

Das mit Deutschkurs würde ich trotzdem aufrecht erhalten.

Autor: Michael K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Für das Logging von Zellenspannungen hab ich mir mal einen Logger
> mit einem MSP430F2012 + 24C64 gebaut.
> Grafische Auswertung geht unter anderem mit einem Palm.

Dann hast Du ja richtig viel zu meinem Beitrag beigetragen !

> Das mit Deutschkurs würde ich trotzdem aufrecht erhalten.

Ist schon recht. Mein Deutsch hat mich bis jetzt durchs Abi und das 
Studium gebracht. Also von daher bin ich gut versorgt. Warum suchst Du 
Dir nicht ein Germanistenforum, wo Du sicherlich besser aufgehoben bist 
! Und immer anonym schreiben ist feig.

Grüße,
Michael

Autor: Oberlehrer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ist schon recht. Mein Deutsch hat mich bis jetzt durchs Abi und das
> Studium gebracht. Also von daher bin ich gut versorgt. Warum suchst Du
> Dir nicht ein Germanistenforum, wo Du sicherlich besser aufgehoben bist
> ! Und immer anonym schreiben ist feig.

Naja, fürs Germanistenforum tauge ich als Ing nicht.
Der unbekümmerte Umgang mit Lehnworten, so wie bei Dir,
löst bei mir dann trotzdem schon mal Heiterkeit aus.

Wieso brauchst Du eigentlich Hilfe?
Du kannst Rechnen, siehe Originalpost, kannst Lesen, warum fragst Du
dann hier nach Kleinigkeiten? :-)

EEPROMs gehen so schnell nicht kaputt und ob der EEPROM nun 1 Euro
oder wegen besonderer Größe nun 3 Euro kostet, ist für ein 
Einzelexemplar
nicht besonders relevant.

In dem Sinne,
Gutes Gelingen...

Autor: Michael K. (mmike)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Naja, fürs Germanistenforum tauge ich als Ing nicht.
> Der unbekümmerte Umgang mit Lehnworten, so wie bei Dir,
> löst bei mir dann trotzdem schon mal Heiterkeit aus.

Ah ein Kollege ;-). Momentan schreib ich grad an meiner Diss über die
Flugführung eines unbemannten Hubschraubers. Da die Kern - Avionik aus
der IMU (Inertial measurement unit) besteht war ich hier vllt. ein wenig
vorbelastet. Ich entschuldige mich hiermit nochmals in aller Form für
diesen Ausrutscher!

> Wieso brauchst Du eigentlich Hilfe?
> Du kannst Rechnen, siehe Originalpost, kannst Lesen, warum fragst Du
> dann hier nach Kleinigkeiten? :-)

Nun ja, immer alleine im Keller basteln und programmieren führt manchmal
eben in eine gedanklichen Sackgasse. Mit dem Thread, wollte ich einfach
mal anderen Meinungen zu dem Thema zu hören, die neue Wege und
Möglichkeiten aufzeigen bzw. neue Denkanstösse liefern.

> EEPROMs gehen so schnell nicht kaputt und ob der EEPROM nun 1 Euro
> oder wegen besonderer Größe nun 3 Euro kostet, ist für ein
> Einzelexemplar
> nicht besonders relevant.

Da geb ich Dir recht.

>
> In dem Sinne,
> Gutes Gelingen...

Besten Dank !

Grüße,
Michael

Autor: Oberlehrer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Da die Kern - Avionik aus der IMU (Inertial measurement unit) besteht
Dann kann das natürlich schon mal passieren. :-)

> Nun ja, immer alleine im Keller basteln und programmieren führt manchmal
> eben in eine gedanklichen Sackgasse.
Das angenehme wenn man alleine werkelt ist, das da keiner drängelt.
Man hat also alle Zeit der Welt um die sich die Varianten durchs
Gehirn gehen zu lassen.

Was mir noch aufgefallen ist:
> EEProm (AT24C128 mit 128k)
Der hat 16 KByte.

Wie man Verläufe effizient wegspeichert, kann man sich sehr gut
beim MRTG-Paket angucken.

Autor: Michael K. (mmike)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Nun ja, immer alleine im Keller basteln und programmieren führt manchmal
>> eben in eine gedanklichen Sackgasse.
> Das angenehme wenn man alleine werkelt ist, das da keiner drängelt.
> Man hat also alle Zeit der Welt um die sich die Varianten durchs
> Gehirn gehen zu lassen.

Das stimmt.

> Was mir noch aufgefallen ist:
>> EEProm (AT24C128 mit 128k)
> Der hat 16 KByte.

stimmt auch, oder eben 128kBit

>
> Wie man Verläufe effizient wegspeichert, kann man sich sehr gut
> beim MRTG-Paket angucken.

Das kannte ich noch nicht. Vielen Dank. Hab grad mal die sourcen gezogen 
und schau's mir mal an !

Besten Dank !

Grüße,
Michael

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.