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 ....
Du brauchst ja nicht alle 480 Datensätze zu speichern, 120 genügen dir ja. Und wozu brauchst du 4 Bytes pro Datensatz?
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.
> 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.
@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
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.
@ Simon K.: Stimmt das Protokoll hätte ich gleich im "Intertialbeitrag" beschreiben sollen.... sorry
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
> "Intertialbeitrag"
LOLz
Wenn dann "Initialbeitrag".
Statt mit irgendwelchem Zeug rumzuspielen, solltest Du noch mal den
Deutschkurs belegen.
>Speicherbedarf: 480 * 4 bytes = 1920 bytes. >Das ist leider schon zu viel für meinen ATMega32. warum?
@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
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“
@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
> @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 :-)
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.
> 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
> 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...
> 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
> 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.
>> 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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.