Hallo zusammen,
ich bekomme von einen Sensor Messdaten, 2x 300ter-BYTE-Array, diese will
ich verarbeiten. Habe einen 1KB - RAM µC. Die Arrays müssen leider so
groß sein. Ich speichere die Messdaten, verarbeite sie (aus diesen
Messdaten 2 x 50-BYTE-Array) und verwerfe sie.
Kann ich irgendwie mit malloc, free arbeiten?
Habe ja eigentlich schon 700 Byte verbraten durch
BYTE Messdaten[300]
BYTE Timer[300]
BYTE Messdaten_weitere_Analyse[50]
BYTE Timer_weitere_Analyse[50]
Vielen Dank im voraus!!
Gruß
> Kann ich irgendwie mit malloc, free arbeiten?
Ungünstig, da kann es klemmen obwohl noch genug Speicher da ist.
Da deine Maximalgrössen bekannt sind, kannst du statisch allokieren
(Variablenarrays static definieren).
Da ein einzelner Datensatz nicht zu gross ist, es passen sogar 2 rein,
geht es nur um den passenden Algorithmus, die Reihenfolge der
Verarbeitung.
Da lernt man verschiedene Lösungsmöglichkeiten im Informatikstudium. Du
kannst jetzt nicht erwarten, daß andere dir in einem Satz sagen, was sie
in jahren lernen.
Reichlich konfus und unvollständig, was Du da schreibst. Mit solchen
Angaben kann man nicht viel anfangen. Aber eine Frage sei erlaubt: wie
kann man mit den Timerwerten, die ja 300 Stück sind, etwas anfangen,
wenn sie nur 1 Byte groß sind, d.h. Wertebereich 0-255? Andere Frage:
warum ordnest Du nicht einfach die 50 Werte, die Du brauchst, im 300er
Array um? Dann brauchst Du die 50er Arrays nicht anlegen.
Wie werden die Messdaten denn Verarbeitet ? Vieleicht sind dort
Optimierungen möglich. Ich nehme z.B. mal an das NICHT der 1. und letzte
Messwert verrechnet werden müssen ? oder doch ? vile sachen kann mann
wärend der Messwertaufnahme machen bzw. zwischen den einzelnen
Messpunkten wenn man dvon ausgeht das du auch später das Array Punkt für
Punkt Sequentiel verarbeitest. doof wirds nur wenn du tatsächlich den
z.B. den ersten und den Letzten aufgenommen Wert verrechnen mußt.
Mehr infos wären hilfreich.
Wenn es einen "Programmiertrick" gibt, hängt er sehr stark von dem
Verarbeitungsalgorithmus und der Art und Weise wie die Daten
hereinkommen und wie sie ausgegeben werden ab.
Ein Ansatzpunkt wäre sich den Verarbeitungsweg mal Schritt für Schritt
anzuschauen und den frühesten Zeitpunkt festzustellen, an dem ein
Ausgabewert fertig ist und verworfen werden kann. Dabei auch
durchdenken, ob Eingabe und Verarbeitung miteinander verwoben werden
können.
Falls Du das selbst nicht hinbekommst, musst Du hier wohl den Ein-, und
Ausgabeprozoess und die Verarbeitung dazwischen im Detail beschreiben.
@Hannes
Wenn alles so wie in deinem Start-Post beschrieben festliegt, hilft nur
ein größerer uC. Wenn du verrätst, was du für Daten hast, wie schnell
die eingelesen werden und was am Ende herauskommen soll, ließe sich über
eine alternative Lösung Nachdenken.
Hannes schrieb:> Habe ja eigentlich schon 700 Byte verbraten durch> BYTE Messdaten[300]> BYTE Timer[300]> BYTE Messdaten_weitere_Analyse[50]> BYTE Timer_weitere_Analyse[50]
Entweder mach die Felder kürzer oder nimm mehr RAM (z.B. ATmega328: 2kB,
ATmega1284: 16kB).
Hannes schrieb:> Kann ich irgendwie mit malloc, free arbeiten?
Nö, das braucht sogar noch mehr Speicher für seine Verwaltung.
Peter
brauchst du die Timerwerte wirklich?
Meist ist die Auslesefrequenz doch fix
Je nach Entropie der Messwerte könnte man diese auch live komprimieren.
Huffman mit dynamischen Baum.
Wobei die Frage ist, ob sich dass für die paar Byte lohnt.
Halt der übliche Trade-Off: Rechenzeit <-> Speicher
Hannes schrieb:> Habe ja eigentlich schon 700 Byte verbraten durch
Wo ist denn jetzt bei 1K das Problem? Sind doch immer noch 324 Byte
frei.
Das ist mehr als mancher Controller insgesamt hat.
Bei 980 Byte würde ich langsam einen Kopf machen, aber...
Aber beschreib' mal genau, was du vorhast. Meistens lässt sich da schon
was optimieren oder mit geringen, nicht relevanten, Verlusten
verringern.
mfg.
Vlad Tepesch schrieb:> Wobei die Frage ist, ob sich dass für die paar Byte lohnt.
Hab nochmal nachgedacht:
bei 300 eher nicht, dass ist ja nur geringfüg mehr, als du mögliche
Eingabewörter hast. das lohnt sich dann nur, wenn die Zahl der
tatsächlichen verschiedenen Werte sehr gering ist und die auch nicht
gleichverteilt sind
Aus dem Bauch geschätzt max 64
Thomas Eckmann schrieb:> Wo ist denn jetzt bei 1K das Problem? Sind doch immer noch 324 Byte> frei.
vielleicht braucht die Berechnung ja auch noch etliches an Platz auf dem
Stack.
Wobei 300 freie Byte schon recht viel sind. Aber spätestens bei 150Byte
würde ich mir Sorgen machen und die Programmpfade mit dem größten Stack
ermitteln
Vlad Tepesch schrieb:> vielleicht braucht die Berechnung ja auch noch etliches an Platz auf dem>> Stack.
Bringt nichts, hier zu theoretisieren oder die RAM-Alarmschwelle zu
verschieben. Ohne konkrete Aufgabenstellung bleibt das
Kaffeesatzleserei.
mfg.
@ Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
>verschieben. Ohne konkrete Aufgabenstellung bleibt das>Kaffeesatzleserei.
Das ist doch die Lieblingsbeschäftigung des Forums . . .
