Das Speicherproblem Teil 2

IMG_0400Nachdem es mir gestern gelungen ist, mit einer extrem eingeschränkten Zeichentabelle 6 Zeilen des Bildschirms zu füllen, hab ich heute am Code weitergearbeitet und es geschafft, den ganzen Bildschirm zu nutzen und alle druckbaren Zeichen auch wirklich anzeigen zu können.

Bildschirmfoto 2013-06-26 um 00.28.42Ich kann jetzt also bei der momentanen Schriftgröße (8×8) insgesamt 726 Zeichen anzeigen. Schon allein diese Anzahl ist größer, als der mir zur Verfügung stehende Arbeitsspeicher. Nicht zu vergessen die insgesamt 222 Zeichen in der Schrifttabelle, die theoretisch noch mal 1776 Byte Platz belegen würden.

Um das Unmögliche möglich zu machen habe ich das Text-Rendering und die Schrifttabelle komplett überarbeitet. Ich habe nichts komprimiert, weil das Dekomprimieren auf 16 Mhz nicht schnell genug machbar gewesen wäre, aber habe mir die immerhin noch 10KB freien Speicherplatz im Flash zunutze gemacht. So wird der Font-Buffer von bislang 208 Byte auf 8 Byte reduziert – dafür gibt es eine Funktion, die diesen bei Bedarf aus Font-Daten des Flash-Speichers konstruiert. Das dauert zwar, aber in diesem Fall ist der ePaper-Bildschirm noch klar der Flaschenhals, sodass das nicht wirklich auffällt.

Für den Textpuffer habe ich mir den Speicher der Ansteuerungseinheit des Displays zunutze gemacht, welche immerhin einen Framebuffer hat, den ich zwar nicht direkt ansteuern, aber, wie letztes Mal schon gesagt, zeilenweise füttern kann. Mein Programm speichert sich also jetzt nur noch die letzte Zeile des angezeigten Textes und rendert diese, wenn sie voll ist, direkt in das Display. So kann ich eine Funktion ähnlich wie printf realisieren, welche auch mehrfach in die gleiche Zeile schreiben kann.

Wenn die letzte Zeile voll ist, bin ich leider nicht dazu in der Lage, den ganzen Text nach oben zu schieben, da das Programm schon längst vergessen hat, was in den oberen Zeilen steht. Mal sehen ob ich irgendwie den Inhalt des Framebuffers auslesen und ihn dann versetzt wieder schreiben kann.

Bildschirmfoto 2013-06-26 um 00.26.29Fazit Speicherverbrauch: Der Flash-Speicher ist bis zum Rand voll (15,5 von 16 KB). Allerdings ist dafür der RAM noch schön leer, und theoretisch müsste ich das Programm sogar, wie gestern scherzhaft angedeutet, mit einer kleineren Schrifttabelle auf den schwächeren Chip mit 256 Byte übertragen können. Dieser hat allerdings anscheinend einen Unterschied in der Übertragung und schreibt nur wirres Zeug auf das Display. Ich hab trotzdem aus Spaß auf dem größeren Chip parallel zum Text-Schreiben ein malloc(256) laufen lassen und er hatte keine Probleme, mir den Speicher zu reservieren – also sagen wir mal, ich habe theoretisch die Speicher-Hürde geschafft.

Und nur mal ganz nebenbei gesagt – Sublime Text ist episch geil. Ich wäre sonst beim Konvertieren der Schrifttabelle durchgedreht.

Advertisements

Das Speicherproblem

IMG_0397Ich hab mir für die lernfreie Zeit mal ein neues Gadget gegönnt, nämlich ein TI LaunchPad (das ist ein Programmierboard für Embedded-Chips) und dazu ein richtig cooles ePaper-Display. Warum? Weil ePaper geil ist. Ich mag diese Technik und ich denke mal dass da noch was richtig großes draus werden kann.

Mit so einem Ding bewegt man sich programmiertechnisch so weit Low Level, noch einen Schritt weiter runter und man hängt am Assembler-Code. Das heißt abgespeckte C Library, wenig Speicher, Interrupts, Vektoren und vieles mehr. Man muss dem Compiler sogar sagen, wo er einzelne Funktionen hinkompilieren soll, denn der Chip führt bei einem Interrupt einfach eine feste Speicheradresse aus.

Und das macht tatsächlich Spaß und man lernt, wie man beim Programmieren richtig den Speicher und die CPU schont, schließlich arbeitet der Chip mit 16 MHz. Einen gnädigen Flash-Speicher von 16KB gibt’s auch noch – es passiert also gerne mal dass das fertige Programm gar nicht mehr auf den Chip passt. Noch härter hat’s den RAM erwischt – ich hab 512 Byte zur Verfügung. Das heißt ein malloc(512) und der Speicher ist voll.

Und hier liegt die Herausforderung, vor die ich mich hartnäckigerweise gestellt habe. Das 2,7″ ePaper-Display ist monochrom und hat eine Auflösung von 264×176 Pixeln. Wenn ich pro Bit eine Information speichere, liegt mein Speicherverbrauch bei ca. 5,8 KB. Tja, zu groß.

Also ist nix mit Bildschirmpuffer, und es wird noch böser, denn der Bildschirm will sein Futter zeilenweise haben, also ist auch nix mit einer setPixel()-Funktion. printf gibt’s natürlich auch nicht – noch nicht einmal eine Schriftart. Für das Display wird eine GFX-Library angeboten, mit welcher man Kreise und Text zeichnen kann – diese sprengt auf meinem Chip (MSP430G2553) sowohl bei RAM als auch Flash jeden Rahmen. Für diese Bildschirmgröße soll die nicht einmal auf einem Arduino Mega laufen.

Bildschirmfoto 2013-06-25 um 02.02.21Also macht man’s eben selbst. Mein Programm benutzt einen Textpuffer für insgesamt 198 Zeichen, einen Zeilenpuffer für die momentan bearbeitete Zeile und eine 6×8 Bitmap-Schrift-Tabelle mit 26 Zeichen. Damit ist der Speicher dann auch voll. Nach viel Verzweiflung und Herumgefrickel kann ich jetzt tatsächlich Buchstaben wie oben im Bild anzeigen.

Ich muss das bei Zeit noch mal ausbauen, denn wie man sieht ist es noch nicht wirklich gut. Ich bin in der Lage ca. 30% des Bildschirms auszunutzen und habe gerade mal alle Großbuchstaben und ein Leerzeichen zur Auswahl. Bill Gates hat mal gesagt dass 640 KB RAM für immer ausreichen sollten, und ich bin mir sicher dass ich diese 512 Byte RAM noch zu Höchstleistungen überreden kann. Und dann portiere ich das auf den anderen Chip mit 256 Byte RAM, der hier auch noch irgendwo rumfliegt (auf den passt die Schrifttabelle nur knapp drauf…) 😉

Ich werde da noch mal drüber berichten, wenn ich den Code „optimiert“ hab. Wenn ich bedenke wie viele unserer Haushaltsgeräte solche Embedded-Chips beinhalten, ist es wahrscheinlich gar keine schlechte Idee, sich damit auseinanderzusetzen. Es gibt auch weder frustrierte User noch schlechte App Store Bewertungen oder sinnlose Feature-Wünsche! 🙂

Ene, mene, miste, es rappelt in der Kiste

Schon vor einiger Zeit ist mir etwas beunruhigendes aufgefallen. Ich hatte damals vor, meinen Mac Mini etwas innerlich zu reinigen, wegen Staub und so, und beim Neigen und leichtem Schütteln (was bekanntermaßen eine beliebte Methode ist, Nicht-SSD-Festplatten zu defragmentieren) hörte ich ein Geräusch aus dem Inneren. Es war etwa so als ob irgendetwas innerlich abgebrochen war und im Gehäuse herumwuselte, was ohne Frage nicht der Fall sein sollte.

Jedenfalls sollte heute der glorreiche Tag werden, an dem ich garantieinvalidierend nach dem entsprechenden Teilchen suche.

IMG_0123

Dabei habe ich unter anderem gemerkt, dass es gar nicht so eine große Katastrophe sein würde, die Festplatte auszuwechseln, was ich ja bestimmt auch irgendwann mal für eine nette SSD machen werde. Sonst ist alles ziemlich fummelig, aber die Stecker am Logic Board sind ganz nett, weil man sie nach oben rauszieht. Das ist wesentlich einfacher auch zum Verbinden, außerdem kann ich sie so nicht falsch herum reinfummeln, was ich sonst garantiert gemacht hätte.

IMG_0125

Jedenfalls war weiterhin keine Spur von dem Verursacher und es rappelte immer noch. Was ich bislang nicht wusste: Unter dem Logic Board ist reichlich Platz. Wer mal ein schwer zu erreichendes Versteck braucht – da ist eins. Nach dem mühsamen Entfernen des gesamten Logic Boards kam neben dem lächerlichsten Lautsprecher der Geschichte auch eine Metallklammer zum Vorschein. Und die lag einfach so rum.

IMG_0127

Das ist doch schon etwas beeindruckend. Die Klammer ist wirklich groß und auch noch sehr gut leitfähig:

Und wenn der Mac richtig herum auf dem Tisch steht, liegt dieses Teil genau auf dem Logic Board. Ich kann froh sein, dass dadurch nichts kaputt gegangen ist. Wo allerdings die Klammer herkommt, konnte ich nicht herausfinden, und da ich diesen Artikel gerade mit dem Patienten schreibe ist diese anscheinend auch nicht besonders wichtig. Wie die Klammer überhaupt von ihrem rechtmäßigen Platz gelöst wurde? Vielleicht haue ich zu oft auf meinen Tisch. Vielleicht wurde sie beim Auswechseln des Super Drives dort vergessen – soll es ja geben.

Jetzt rappelt nix mehr – Mission accomplished.