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ß
Kannst du die Daten für die weitere Analyse möglicherweise im selben Array speichern? Damit sparst du schonmal 100 Byte.
> 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 . . .
Thomas Eckmann schrieb: > Kaffeesatzleserei Wobei 'Kaffeesatzleserei' immerhin noch etwa 17mal reinpassen würde in die verbliebenen 300 bytes;)
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.