In meinem aktuellen Projekt möchte ich gerne Updates über den (vorhandenen, funktionierenden) Bus machen können. Dazu habe ich mir folgenden Algorithmus überlegt: -uC mit genügend Flash nehmen -Neues Image via Bus in reservierten Flash-Bereich schreiben -Neustart auslösen -Nach jedem Neustart wird auf Vorhandensein eines gültigen Image geprüft -Ist ein Image vorhanden, wird der bestehende Code damit überschrieben und das Image danach ungültig gemacht -Nochmal Neustart, damit wird dann das neue Image geladen Dafür brauche ich aber doppelt so viel Flash wie im Normalbetrieb. Nun habe ich das Problem, dass die verwendete uC-Familie (MSP430F530x) maximal 32k Flash hat, mein Image aber inzwischen 18k. uC-Familie wechseln wäre nur die allerletzte Option, auch externes EEPROM würde ich ungern einsetzen. Fragen: -Hat jemand Erfahrung damit, binären Programmcode zu komprimieren? Welche Kompressionsraten sind realistisch? -Welche Verfahren sind uC-tauglich? zlib ist keine Option, da viel zu RAM-intensiv (ich habe nur 6k) Gruß und guten Rutsch, Max
das wird nix. Verschlanke dein Programm, daß die notwendige Größe rauskommt, oder bau dir externen zusätzlichen Speicher dran.
Hallo, was spricht denn gegen einen klassischen Bootloader, der die Daten über den Bus empfängt und direkt den Programmspeicher überschreibt? Gruß Kai
Kai S. schrieb: > was spricht denn gegen einen klassischen Bootloader, der die Daten über > den Bus empfängt und direkt den Programmspeicher überschreibt? Er möchte überleben, auch wenn der Bootlader im letzten Rekord die Grätsche macht.
Hallo, schau dir mal LZO an. > https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Oberhumer Interessant daran ist besonders das hier: > Requires no additional memory for decompression other than the source and > destination buffers. Für die Kompression werden zwar ab 8 kB RAM benötigt, aber so wie ich das verstehe würdest du auf dem MSP430 ja nur dekomprimieren. Allerdings sehe ich es ähnlich wie meine Vorposter, ich würde versuchen den Code zu verkleinern und/oder mehr (externen) Speicher einsetzen. Würdest du die Daten aus einem externen EEPROM laden so hättest du ja dann noch mehr als genug Platz übrig für eventuelle zukünftige Erweiterungen. Viele Grüße Daniel
:
Bearbeitet durch User
Georg G. schrieb: > Kai S. schrieb: >> was spricht denn gegen einen klassischen Bootloader, der die Daten über >> den Bus empfängt und direkt den Programmspeicher überschreibt? > > Er möchte überleben, auch wenn der Bootlader im letzten Rekord die > Grätsche macht. Kann ich zwar verstehen, aber der Preis wär mir dafür zu hoch. Die Hälfte des Flash dafür zu opfern, das bin ich nicht bereit 'zu bezahlen'. Dann schon lieber ein Neustart und ein neuer Versuch mit dem Bootloader. Ob und wieviel eine Kompression an Platzgewinn bringt, das wird er ausprobieren müssen. Ich würde mir aber nicht allzuviel erwarten.
:
Bearbeitet durch User
Daniel H. schrieb: > schau dir mal LZO an. oder den LZ77 http://de.wikipedia.org/wiki/LZ77#Verwendung
Karl Heinz schrieb: > Georg G. schrieb: >> Er möchte überleben, auch wenn der Bootlader im letzten Rekord die >> Grätsche macht. Richtig. Außerdem ist die Kommunikation des Bootloaders ziemlich komplex und erfordert einen funktionierenden Stack. Wenn ich den Stack updaten will, habe ich ansonsten ein Henne-Ei-Problem. > > Kann ich zwar verstehen, aber der Preis wär mir dafür zu hoch. Die > Hälfte des Flash dafür zu opfern, das bin ich nicht bereit 'zu > bezahlen'. Dann schon lieber ein Neustart und ein neuer Versuch mit dem > Bootloader. Der Preisunterschied zwischen der 16k-Version und der 32k-Version sind 20 Cent (100er-Stückzahlen). So what? Ich muss mal ausprobieren gehen. Schade, hatte auf konkrete Erfahrungen (auch negative) gehofft. Max
Max G. schrieb: > hatte auf konkrete Erfahrungen > (auch negative) gehofft. Wir benutzen AVRs, die haben eine Bootsektion. Da steht dann unser CAN-Bootloader. Der Bootloader ist somit nach jedem Reset eine Zeit lang aktiv. Damit ist auch bei einer korrupten Applikation immer eine Neuprogrammierung möglich. Findet er eine gültige Applikation, startet er diese. Ansonsten bleibt er im Bootloader und wartet auf Daten. Ist die Applikation aktiv, kann sie jederzeit mit einem Watchdogreset den Bootloader starten.
Ich wuerd mir ein externes flash goennen. die gibt's auch im SO8 Gehaeuse, sollte also nicht so platzintensiv sein.
Grundsätzlich sieht bei reinem Programmcode ja ziemlich mau aus was die Kompressionsraten angeht, aber rechne doch mal die Entrophie[1] deines Codes aus. Dann hätte man zumindest einen Anhaltspunkt wie gut sich das komprimieren lassen könnte. Ansonsten könntest du spaßeshalber mal einige Packer vom C64 damals testen - die dürften ja von den constraints her in etwa passen (z.B. Pucrunch[2]). [1] http://de.wikipedia.org/wiki/Entropie_(Informationstheorie)#Entropietests [2] http://www.cs.tut.fi/~albert/Dev/pucrunch/
Max G. schrieb: > Außerdem ist die Kommunikation des Bootloaders ziemlich komplex > und erfordert einen funktionierenden Stack. Naja... ein Bootlader, der per TFTP auf einem vorgegebenem Server bei jedem Start nach sieht, ob ein Update vorhanden ist, passt locker in den Bootbereich eines 644 (8kBytes). Und das dürfte das bequemste überhaupt sein.
Hallo. Nehm einen Bootloader, der vor eigentlichem Firmwarestart irgend einen Redundanzcheck durchfuehrt (CRC, SHA* ...etc...). Wenn aber dieser Check fehlschlaegt, oder explizit "Updatemodus" gestartet wurde (das kann ein bestimmer Wert im RAM nach reboot sein) - dann lauscht er auf dem BUS nach expliziten Updatebefehlen, um Seite fuer Seite zu "updaten" und auf einen "Restart" Befehl zu warteten. Dadurch sparst du dir ein zusaetzliches Zwischenspeichern der Firmware und unnoetiges umkopieren. Wenn du Lust hast kannst du zusaetzlich Kompression verwenden - wieviel RAM steht dir denn zur Verfuegung? GGf. kann man eine BWT (aehnlich wie in bzip verwendet) fuer jede Seite zur Kompression(svorbreitung) einbauen. LZ (gzip oder lzma) scheint unpraktikabel, da du vermutlich nicht genug RAM fuer brauchbare Woerterbuchgroessen hast. Reine Eintropiekodierung dagen laesst sich in der Kompressionsstaerke uebertreffen. Das decodieren einer BWT(S) ginge in O(n) Speicher mittels Rosettavektoren - zwar sehr langsam (O(n^2)), aber ginge... Gerne kann ich bzgl. Kompression aushelfen - bzgl. Update kannst du ja mal in den (AVR) Code des USBaspLoader testing branch sehen: https://github.com/baerwolf/USBaspLoader/tree/testing An einem komprimieren Updater-Image hatte ich auch schon mehrmals gedacht, bisher aber aus Zeitmangel immer wieder hinausgeschoben... MfG
> GGf. kann man eine BWT (aehnlich wie in bzip verwendet) fuer jede Seite > zur Kompression(svorbreitung) einbauen. Für eine handvoll Kilobyte dürfte eine BWT aber vergebliche Liebesmühe sein. :( Dann doch lieber ein LZ77 oder sowas.
dj/+h schrieb: > Für eine handvoll Kilobyte dürfte eine BWT aber vergebliche Liebesmühe > sein. :( > Dann doch lieber ein LZ77 oder sowas. Gerade deshlab BWT - LZ77 ist quatsch, da sich gar kein brauchbares Woerterbuch aufbaut. Und BWT auf nur ein paar Kilobyte wird nicht schlechter sein, als pure Entropiekompression allein. LZ77 laesst sich ggf. leicher decodieren. MfG
:
Bearbeitet durch User
Hum? Wenn ein LZ (77 oder SS oder wie die Varianten alle heissen) kein vernünftiges Wörterbuch aufbauen kann - wieso sollte dann die BWT groß was reissen können? Die basiert ja auch nur darauf das sich Sequenzen wiederholen. Hast du das mal konkret getestet? Erfahrungsgemäß kann man ja bei kleinen Blockgrößen nicht so viel reissen, als das es sich (meiner Ansicht nach) lohnen würde es zu implementieren.
Grossartig lohnen wird es sich nicht. LZ77 wuerde vermutlich aehnlich gut abscheiden, wenn man die Suche perfekt macht. (Also alle moeglichen Laengen fuer alle moeglichen Matches probieren. Das waere aber reduzierbar auf SetCover und somit sehr langsam.) Ueblicherweise "schludert" man bei der Suche (Hashing, lazy coding ...), was gerade bei kleinen dictinaries boese auf die Kompressionsleistung geht. Konkret muesste man testen. MfG
> Konkret muesste man testen. Das habe ich mir auch gerade gedacht. :) Als Testfile diente mir die Firmware des C64 (Basic+Kernal; Maschinencode mit wenigen Strings, 8 KiB), die hatte ich gerade bei der Hand. Die Kompressoren für die BWT stammen von Marc Nelson[1]. Es wurden für verschiedene Blockgrößen jeweils zwei Tests ausgeführt: rle+bwt+ari und bwt+ari. Die Resultate (in Bytes): Blockgröße 1 KiB: 15.051 und 15.057 Blockgröße 2 KiB: 14.973 und 14.977 Blockgröße 4 kiB: 14.929 und 14.934 Blockgröße 8 kiB: 14.908 und 14.912 Zum Vergleich: Die arithmetische Kompression alleine packte das File auf 14.891 Bytes, der oben angesprochene Pucrunch auf 14.101. Es wurden bei keinem der Programme irgendwelche Switches zur Optimierung verwendet (allerdings ist der Pucrunch von Haus aus ja bereits auf solche Szenarien optimiert). Bei diesen Zahlen scheint das Vorhaben des TEs (18kB Firmware auf 14kB zu packen) recht ambitioniert. Mit fertigen Pauschallösungen wird's schwierig, aber vielleicht könnte man einen Packer maßanfertigen. Wobei ich deinen Alternativvorschlag zum Update jedoch angebrachter finde... [1] http://marknelson.us/1996/09/01/bwt/
dj/+h schrieb: > Basic+Kernal; Maschinencode mit wenigen Strings, 8 KiB Mist. Sind zusammen natürlich 16 KiB.
dj/+h schrieb: > Basic+Kernal; Maschinencode mit wenigen Strings, Kanst du das File bitte als Referenz hochladen. Vielleicht teste ich nachher auch bissel rum (ich will es aber nicht versprechen), und so haben wir dann zumindest vergleichebare Ergebnisse. MfG
Und da ist es schon. Ist aber halt bloß ein willkürlich gewähltes File, besser wäre es freilich wenn der TE uns was zur Verfügung stellen könnte. Hoffentlich liest er uns noch zu...
Ich muss mich noch schnell korrigieren: Bei der BWT habe ich Döskopp den move to front vergessen, und beim PU habe ich übersehen, das der einen Entpacker gleich dazu linkt. Hier die korrigierten Werte. rle+bwt+mtf+ari und bwt+mtf+ari (in Bytes) Blockgröße 1 KiB: 13.973 und 13.906 Blockgröße 2 KiB: 13.848 und 13.784 Blockgröße 4 KiB: 13.778 und 13.719 Blockgröße 8 KiB: 13.716 und 13.661 Pucrunch, ohne Entpacker: 13.792 Sieht doch schon viel besser aus. :)
Zwischenstand: Optimierung hat Reduktion auf 15kB gebracht. 7Zip dampft das auf 10kB ein, ist aber natürlich nicht uC-tauglich. Mit einem angepassten Algorithmus könnten also so 12kB drin sein - das lässt auch noch etwas Raum für künftige Funktionalität. Den LZO schaue ich mir an - aber erst nächstes Jahr :-), jetzt gibt's Raclette. Max
Völliger Schwachsinn. Das was du dir durch die Kompression am Update-Image sparst gibst du für den Code zur Dekompression gleich doppelt wieder aus. Zumal die Einsparung minimal sein wird. Und wenn das Update jetzt ein bisschen größer wird? Kannst du es nicht ausliefern. Großartig. Speicher dein Image doch in einen externen SPI Flash oder so, der ist billig, klein, und du hast die ganzen 32kByte Flash im MSP430 voll zur Verfügung.
Wenn schon Komprimierung, dann wäre es vielleicht ganz interessant, sich statt diverser LZ Verfahren erst einmal den Huffman anzuschauen. Da die MSP430 eine 16-Bit Codierung verwenden, könnte es sinnvoll sein, dabei nicht Bytes sondern die statistische Verteilung von Worten zu betrachten.
Guest schrieb: > Völliger Schwachsinn. Das was du dir durch die Kompression am > Update-Image sparst gibst du für den Code zur Dekompression gleich > doppelt wieder aus. Der Code macht keine Probleme. Verfahren wie LZRW sind sehr kompakt. Das Problem tabellengestützter Vefahren ist eher der RAM-Verbrauch. Denn die dynamischen Daten des Dekomprimierers müssen da rein. Da könnte der von Läubi und mir erwähnte Huffman interessanter sein.
:
Bearbeitet durch User
Der Code zur Decomprimierung muss nicht besonders groß sein - auch muss man den nicht unbedingt in dem Teil haben der Aktualisiert wird. Es kann ggf. auch ein kleiner Teil fest bleiben. Der Huffman Code (ASM) aus dem Link oben sollte so etwa 150-200 Worte lang sein, die Umsetzung auf den MSP430 ist ggf. etwas länger. Das ist nicht wirklich viel. Wie viel die Komprimierung bringt kann man vorher am PC probieren. Auch wenn es nur 10 % sind würde es da schon lohnen. Eine Alternative wäre es ggf. noch als Zwischenlösung eine Eingeschränkte Version der SW zu laden, und so Speicher zu sparen: also vom alten Code auf einen Minimalversion und erst dann auf die neue volle Version. Die Minimalversion muss man in der Regel ja nicht aktualisieren, wenn man sie einmal hat - im Extremfall kann sie zu einem Bootloader werden, der nur das Update unterstützt. Die Möglichkeit hat man auch später noch - falls es wirklich nicht mehr reicht.
Ulrich schrieb: > Der Code zur Decomprimierung muss nicht besonders groß sein - auch muss > man den nicht unbedingt in dem Teil haben der Aktualisiert wird. Es kann > ggf. auch ein kleiner Teil fest bleiben. Der Huffman Code (ASM) aus dem > Link oben sollte so etwa 150-200 Worte lang sein, die Umsetzung auf den > MSP430 ist ggf. etwas länger. Das ist nicht wirklich viel. > > Wie viel die Komprimierung bringt kann man vorher am PC probieren. Auch > wenn es nur 10 % sind würde es da schon lohnen. > > Eine Alternative wäre es ggf. noch als Zwischenlösung eine > Eingeschränkte Version der SW zu laden, und so Speicher zu sparen: also > vom alten Code auf einen Minimalversion und erst dann auf die neue volle > Version. Die Minimalversion muss man in der Regel ja nicht > aktualisieren, wenn man sie einmal hat - im Extremfall kann sie zu einem > Bootloader werden, der nur das Update unterstützt. Die Möglichkeit hat > man auch später noch - falls es wirklich nicht mehr reicht. Viel mehr als 10% wird man aber vermutlich auch nicht rausholen können. Wenn 7z schon nur 30% bringt... Auch die Geschichte mit dem Minimal-Loader, klar funktioniert das, aber das ist doch lächerlich... Was für eine Anwendung braucht denn bitte einen so komplexen Protokollstack, dass er nicht in den Bootloader passt, bzw dass der Bootloader zu unflexibel dazu ist, andererseits aber kein Platz/Geld für einen externen Flash da ist?
Guest schrieb: > Bootloader zu unflexibel dazu ist, andererseits aber kein Platz/Geld für > einen externen Flash da ist? Wobei ich dafür kein Flash, sondern ein SRAM wie zB 23K256 (32k SPI) nehmen würde. fchk
A. K. schrieb: > Der Code macht keine Probleme. Verfahren wie LZRW sind sehr kompakt. Das > Problem tabellengestützter Vefahren ist eher der RAM-Verbrauch. Denn die > dynamischen Daten des Dekomprimierers müssen da rein. Da könnte der von > Läubi und mir erwähnte Huffman interessanter sein. Der Huffmancode kommt prinzipiell mit nur einem Wort Speicher aus, so wahnsinnig viel Flash wurde auch nicht verbraucht wenn ich mich recht erinnere. Da der Huffmancode zudem noch ein "optimaler" ist... A. K. schrieb: > Da die MSP430 eine 16-Bit Codierung verwenden, könnte es sinnvoll sein, > dabei nicht Bytes sondern die statistische Verteilung von Worten zu > betrachten Das kommt auf die Daten an, ich habe bei meinem Versuch auch einen 4bit-Modus eingebaut, da dieser bei einigen Daten noch bessere Ergebnisse gebracht hat. Bei 16bit ist noch das Problem, dass die Mappingtabelle nämlich ggf. größer als die tatsächlichen Daten werden könnte... Man könnte sich sogar theoretisch die Tabelle in den Daten sparen wenn man von einem festem Baum ausgeht, aber das bringt dann wirklich nur noch wenig. Ulrich schrieb: > er Huffman Code (ASM) aus dem Link oben sollte so etwa 150-200 Worte > lang sein, die Umsetzung auf den MSP430 ist ggf. etwas länger. Das kommt drauf an, der AVR hat nicht so viele tolle Bitschiebebefehle die man aber für Huffman benötigt (Bitstrom zu Symbolstrom), da könnte der MSP im Vorteil sein auch mit seiner 16bit Architektur ist eventuell noch etwas rauszuholen.
:
Bearbeitet durch User
Frohes neues Jahr an alle! Ich habe mal ein bisschen rumgespielt. Binäre Referenzdatei (bis auf ein paar Bytes identisch zum späteren Speicherinhalt): 14.866 Bytes Huffmann-Encoding (von http://folk.uio.no/thomanyg/inf1040/huffman/index_en.html ): Codebook 3.070 Bytes, Output 103.440 Bytes - allerdings ASCII, nicht binär. Binär kämen wohl rund 13.500 Bytes raus - keine Sensation. LZO2A-999 (Oberhumer): 11.031 Bytes. Ich werde aber noch nicht mal aus der Programmstruktur, geschweige denn dem Code schlau. PUC: 10.708 Bytes - allerdings werde ich auch hier nicht schlau. GZIP (LZ77) mit Option -1: 10.609 Bytes Aus der Basic Compression Library ( http://bcl.comli.eu/download-en.html ): RLE: keine Kompression Shannon-Fano: 13.485 Bytes Huffmann: 13.287 Bytes (müsste theoretisch identisch sein zu der norwegischen Implementierung - naja, sei´s drum). Lempel-Ziv: 12.770 Bytes Sequentiell (erst LZ77, dann Huffman): 11.518 Bytes Ich muss mal einen näheren Blick auf LZ werfen. Die Referenzimplementierung für die Dekompression hat rund 25 Codezeilen...das klingt vertretbar :-) Wenn das läuft, kann noch der Huffman dazu. Das nähert sich dann schon langsam der Redundanzfreiheit. So weit zum Thema "völliger Unfug"... Max
:
Bearbeitet durch User
Läubi .. schrieb: > Man könnte sich sogar theoretisch die Tabelle in den Daten sparen wenn > man von einem festem Baum ausgeht, aber das bringt dann wirklich nur > noch wenig. Nein, ganz im Gegenteil. Das ist der zielführendste Ansatz, jedenfalls unter der Prämisse, daß die Idee mit dem Entropieencoder an sich überhaupt sinnvoll ist. Ein fester Baum spart doppelt Platz, zum einen brauchen keine Informationen zur dynamischen Anpassung des Baums übertragen und im Ziel gespeichert zu werden, zum anderen braucht's keinen Code, der diese Anpassungen dann beim Auspacken erledigt. Und das Erstellen des optimalen Baums ist ja unkritisch, denn das passiert auf dem PC, wo genug Rechenleistung und RAM verfügbar ist, um für die relativ geringe Datenmenge so einer Firmware auch noch die optimale Codewortgröße zu suchen, zumal viele Eigenschaften der Daten zuvor bereits bestens bekannt sind. Man weiß ja, wie Instruktionen aufgebaut sind, man weiß, wo im Code Strings und Sprungtabellen liegen usw. usf. > Das kommt drauf an, der AVR hat nicht so viele tolle Bitschiebebefehle > die man aber für Huffman benötigt (Bitstrom zu Symbolstrom) da könnte > der MSP im Vorteil sein auch mit seiner 16bit Architektur ist eventuell > noch etwas rauszuholen. Die Megas haben einen Hardware-Multiplizierer. Der eignet sich auch ganz hervorragend zum Bitschieben. In zwei Takten ist jede beliebige Verschiebung von 8 Bits erledigt und die werden dabei auch gleich noch in zwei mundgerechte Häppchen zerlegt. Ich sehe nicht, wo da beim MSP eine höhere Effizienz herkommen sollte. Die größere Verarbeitungsbreite nützt bei einem Bitstreamdecoder (wie auch sonst sehr oft) leider rein garnichts.
Max G. schrieb: > Sequentiell (erst LZ77, dann Huffman) Das mag (manchmal) was bringen, idr ist es aber Unsinn zweimal zu komprimieren. Wenn sich die Daten schlecht komprimieren lassen kann das auch einfach bedeuten, dass wenig Redundanz vorhanden ist, oder du nahe an der Gleichverteilung für die Symbole bist. Das wiederum hängt von deinem Code ab, probiere es doch mal mit meinem Kompressor im 4 bit Modus oder stell das Binärfile mal Online. Max G. schrieb: > RLE: keine Kompression RLE eigent sich nur für einen Datenstrom welcher viele gleich aufeinanderfolgende Daten enthält (z.B. Bilder, Messwerte) für ein Programm sollte das (hoffentlich) kaum zutreffen. c-hater schrieb: > Das ist der zielführendste Ansatz Unter der Annahme das seine Quellcodes immer ähnlich sind... c-hater schrieb: > Ein fester Baum spart doppelt Platz, zum einen brauchen keine > Informationen zur dynamischen Anpassung des Baums übertragen und im Ziel > gespeichert zu werden, zum anderen braucht's keinen Code, der diese > Anpassungen dann beim Auspacken erledigt. Äh... der Baum muss doch immer vorhanden und abgearbeitet werden, ob der nun "statisch" vorliegt oder in den Daten eingebettet bringt nur was bei wiederholter Übertragung, bedingt aber auch einen nicht ganz so optimalen Code. c-hater schrieb: > Ich sehe nicht, wo da beim MSP eine höhere Effizienz herkommen sollte. > Die größere Verarbeitungsbreite nützt bei einem Bitstreamdecoder (wie > auch sonst sehr oft) leider rein garnichts. Ich habe nur anmerken wollen das das sicher nicht langsamer ist, z.B. kannst du auf einem MSP 16bit in ein Arbeitsregister laden und "durchschieben", beim 8bit musst du für die gleiche Menge zwei Datenworte laden.
:
Bearbeitet durch User
Läubi .. schrieb: > Max G. schrieb: >> Sequentiell (erst LZ77, dann Huffman) > > Das mag (manchmal) was bringen, idr ist es aber Unsinn zweimal zu > komprimieren. gzip verwendet LZ77 und Huffman.
Läubi .. schrieb: > Das mag (manchmal) was bringen, idr ist es aber Unsinn zweimal zu > komprimieren. Erst LZ und dann H ist ziemlich verbreitet, wenn es eher um Rate als Zeit geht.
:
Bearbeitet durch User
Läubi .. schrieb: > Max G. schrieb: >> Sequentiell (erst LZ77, dann Huffman) > > Das mag (manchmal) was bringen, idr ist es aber Unsinn zweimal zu > komprimieren. Das ist nun in dieser Allgemeinheit wiederum Unsinn. Die meisten Kompressionsprogramme kombinieren mehrere Kompressions- verfahren und erreichen erst so eine gute Kompressionsrate. In der Experimentierphase, wo man das beste Verfahren für sein Quellmaterial sucht, ist es hingegen höchst sinnvoll, Programme zu verwenden die jeweils nur ein Verfahren implementieren und diese dann zu kombinieren. Die letzte Stufe ist dabei meist eine generische Entropieminimierung (Huffman, arithmetische Codierung etc) während die vorgeschalteten Stufen an die Eigenheites des Quellmaterials angepaßt werden. Z.B. ist BWT + MTF (bzip2) typisch gut für Text und weniger gut für Binärcode. RLE bringt nur bei entsprechend ineffizient codierten Daten was (z.B. Bitmaps für GUI-Elemente). LZ wiederum ist ein guter Allzweckalgorithmus. Wavelets, DCT usw. spielen ihre Stärken dann bei bandbreitenbegrenzten Daten aus. Oder in Kombination mit einer bewußt verlustbehafteten Bandbreitenminderung. Für Binärcode würde ich darauf tippen, daß LZ + Entropie die besten Ergebnisse bringt. Mit geringen Abhängigkeiten von der Parametrierung. Allerdings glaube ich auch, daß bei diesen geringen Datenmengen der mögliche Gewinn durch die Komprimierung fast sicher wieder durch den Code für den Decompressor aufgefressen wird. XL
Aktueller Stand: Einfachimplementierung mit LZ77 komprimiert schon, Dekomprimierung muss ich noch auf die Applikation anpassen. Ergebnis: Größenreduktion von 19.456 Bytes (Vergrößerung wegen Anpassung auf Flash-Segmentgrenzen) auf 14.336 Bytes. Macht eingesparte 5 kB. Der Dekompressionscode braucht aktuell 178 Bytes. Wird durch die Anpassung noch ein bisschen mehr werden, vielleicht 500 Byte. Ich bin schon ganz zufrieden :-) Max
:
Bearbeitet durch User
Warum kommt mir bei diesem Ansatz nur der Spruch: "Warum bequem, wenn's auch umständlich geht", durch den Kopf? Wurde das Bootloader-Konzept nicht aufgestellt, um genau diesen Doppelwopper zu vermeiden? Normalerweise wird beim Rechnerstart, mit ein paar Tricks, ein neues Programm geladen. Modifiziere doch einfach den Bootloader so, dass er von sich aus aktiv werden kann, nachschaut ob was anliegt und von sich aus eine Umprogrammierung vornimmt. Das kostet zwar auch ein paar Bytes, aber nicht das volle Programm. Freie Bootloader gibt's mittlerweile wie Sand am Meer. Auch gut dokumentierte. Modifiziere doch einfach einen von diesen. Und frage den Verfasser ob es ihn stört.
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.