Hallo Leute, ich suche eine Assembler-Routine mit der ich auf dem 240x128Display einen belieben Ausschnitt löschen kann. Also x1,y1-x2,y2. Es sollen vorhande Bildpunkte einfach gelöscht werden. Wer kann mir dabei helfen bzw. was würde eine solche Routine kosten? Vielen Dank.
Ist es denn soooo kompli(fi)ziert, zwei Schleifen (y,Y) zu verschachteln und darin den ClearPixel-Befehl abzusetzen? Oder anhand der Position den belegten Speicherbereich (je Pixel-Zeile ein Bereich) zu ermitteln und mit Nullen zu füllen?
Beim T6963C ist das Ansteuern von Grafikprimitiven eine Qual. Jedenfalls wenn der Prozessor schwachbrüstig ist und somit alles zeitlich auffällt. Ich hatte mal eine Bibliothek geschrieben, die hatte zuerst die Pixelkoordinaten einzeln berechnet (z.B. für einen Kreis), dann diese gesammelt um auf die Änderungen innerhalb eines bestimmten Bytes zu kommen, dann dieses Byte ALLEIN über den T6963C geschleust. Das Ganze wurde noch komplizierter, weil bei diesen speziellen Displays der Controller auf aktive 6 Bit pro Byte stand und ich es nicht ändern durfte. Letztendlich lief es, aber ich hatte die ersten grauen Haare. OK, ich hatte auch noch Maskenfunktionen wie XOR und Clipping Region eingebaut... Für was für einen Controller und in welcher Sprache soll der Code sein? Gruß - Abdul
achso, also Atmega64 wäre der Prozessor..und normales Assembler @Diensthabender Troll Ich sehe nirgends Code von dir...behaupten kann jeder, kannst du auch beweisen? :-D
muss es unbedingt assembler sein??
> Ich sehe nirgends Code von dir...behaupten kann jeder, kannst du auch > beweisen? :-D Ich vermute mal, dass Du Dir durch diesem plumpen Versuch mehr geschadet als genützt hast. ;-) ...
Vermuten kann jeder alles, beweisen aber nicht :-D Ja, es muß leider Assembler sein, da der Code eingebunden werden soll. 50€ werden geboten :-)
Eieieieiei... 50 Taler dafür, dass Jemand die Hausaufgaben macht... (Vermute ich mal, ich muss es aber nicht beweisen.) ;-) ...
>50€ werden geboten :-)
Also dafür schreib ich meinen C-Code jetzt nicht in
Assembler um ;)
Tom schrieb: > Vermuten kann jeder alles, beweisen aber nicht :-D > > Ja, es muß leider Assembler sein, da der Code eingebunden werden soll. > > 50€ werden geboten :-) Was Tom meint: Hast du eine clearPixel Funktion? Wenn ja, dann ist eine einfache ClearBlock Funktion (in C-Pseudocode)
1 | void ClearBlock( uint8_t x, uint8_t y, uint8_t dx, uint8_t dy ) |
2 | {
|
3 | for( uint8_t py = y; py < y + dy; py++ ) |
4 | for( uint8_t px = x; px < x + dx; px++ ) |
5 | ClearPixel( px, py ); |
6 | }
|
Jage es durch einen C Compiler und du hast deinen Assembler Code. Aber wie gesagt: das kann man auch besser machen, indem nicht jedes Pixel einzeln gelöscht wird. Aber es ist mal ein Anfang.
>Aber wie gesagt: das kann man auch besser machen, indem nicht jedes >Pixel einzeln gelöscht wird. Aber es ist mal ein Anfang. Je nach X-Position kann das schon recht kompliziert werden. Selbst mit Optimierung. Man nehme eine Position die nicht an einer Byte Grenze liegt, und nicht an einer Byte Grenze endet ;)
Wie ich schon schrieb... Also mußt du es nur noch umsetzen. Wenn du einiges drauflegst, schreibe ich es dir. Gruß - Abdul
> Ja, es muß leider Assembler sein, da der Code eingebunden werden soll. Tom, Du unterschätzt vermutlich den Aufwand, fremden ASM-Code in ein vorhandenes ASM-Programm einzubinden. Jeder Programmierer hat seinen eigenen Stil, Fragmente verschiedener Herkunft passen meist nicht zusammen. Um die Bruchstücke passend zu machen, muss man ASM schon verdammt gut beherrschen, es ist meist leichter, den Code anhand eines gegebenen Algorithmus neu zu schreiben und dabei den Stil des bestehenden Programms beizubehalten. > 50€ werden geboten :-) Dafür bekommst Du dann vermutlich etwas, das zwar richtig ist, das Du abrer nicht gebrauchen kannst, weil es nicht zu den Vereinbarungen passt. Ich hänge Dir mal ein paar Low-Level-Routinen für ein GLCD 240x128 Pixel (mit geteiltem Adressraum) an. Eine Bildschirm-Lösch-Routine ist zwar dabei, aber keine Löschroutine für Bildschirm-Bereiche, denn die hatte ich bisher noch nicht gebraucht. Ein Blick ins Datenblatt des T6963C wird Dir zeigen, mit welchem Kommando einzelne Pixel gelöscht werden. Damit sollte es kein Problem sein, zwei Schleifen für X- und Y-Position zu bauen und darin die Pixel-Adresse zu setzen und das Clerpixel-Kommando zu senden. ...
Tom schrieb:
> Ja, es muß leider Assembler sein, da der Code eingebunden werden soll.
Genau umgekehrt wird ein Schuh draus, C läßt sich bedeutend besser
einbinden als Assembler.
Um fremden Assembler einzubinden, mußt Du ihn erstmal bis ins kleinste
I-Tüpfelchen verstehen.
Und sicher noch nen Haufen Anpassungen vornehmen, an Deine
Registerverwendung und Deine Parameterübergabe.
C-Funktionen kann man dagegen oftmals als Black-Box betrachten, d.h. man
muß nur verstehen, was geht rein und was kommt raus.
Peter
Und damit Dir nicht langweilig wird, gebe ich Dir noch eine Datei, in der Routinen zum Setzen und Löschen einzelner Pixel enthalten sind. Mit etwas Arbeit und Verständnis wirst Du sie an Deine Bedürfnisse anpassen können. Sollte die Anpassung ein Dritter vornehmen und dafür Honorar fließen, dann will ich meinen Anteil. Solltest Du es selbst schaffen, dann will ich nix. ...
ohjemine...nur mal so als Frage: warum tut man sich das an, sowas in Assembler zu schreiben? Geschwindigkeit ist doch sicherlich kein Grund, oder? Denn Geschwindigkeitsmäßig ist doch eh das Display der limitierende Faktor. Nicht das ich nicht neidisch bin auf Leute die so gut Asm können, aber solchen Code zu warten usw. ist doch übelste Sisyphosarbeit
Der Grund ist einfach der, daß der T6963C erstens absolut doof ist, also eigentlich nichts kann, und zweitens auch die Grafikdaten durch ein Nadelöhr durch müssen. Mit einem schnellen Prozessor und genug RAM, ist es am besten die Pixel lokal im RAM zu bearbeiten und dann den ganzen Block in kompletten Bytes über den LCD-Controller in sein lokales RAM zu schubsen. (Ich hatte damals vor fast 20 Jahren einfach kaum RAM) Gruß - Abdul
> ohjemine...nur mal so als Frage: warum tut man sich das an, sowas in > Assembler zu schreiben? Weil's schön einfach und eindeutig ist... ;-) Falls Du mich fragst, die Gründe dafür dürften individuell verschieden sein. Bei mir ist es die Tatsache, dass ich C nicht kann (und mit 6 Jahrzehnten auf dem Buckel auch nicht mehr lerne) und Bascom zu verschwenderisch mit den knappen Reccourcen des AVRs umgeht. Da bleibt eigentlich nur ASM, denn das ist die Sprache, die auch der AVR (in Form von MC) versteht. Es ist für mich der Weg des geringsten Widerstandes, in ASM macht der AVR exakt das, was ich ihm sage, in einer Hochsprache wäre das für mich absolutes Rätselraten. AVRs in C programmieren können zwar Viele, wenn's effizient sein soll, dann werden es aber schon bedeutend Weniger, und die Leute beherrschen dann auch ASM. ...
ASM betrachte ich auch als die reine Lehre. Es hat was von (fast) absoluter Kontrolle. Ein Art Religion. Fängt man allerdings mit Assembler als erste Programmiersprache an, dann ist man ein Leben lang versaut. Ich beobachte das immerwieder bei mir und anderen. Es ist genauso, wie wenn man mit dem Einfingersuchsystem auf der Schreibmaschine began. Wer Tippse werden, sollte SOFORT mit dem Zehnfingersystem anfangen. Sonst wird das nix mehr richtiges. Wobei ich schon recht schnell tippe und Entwickler müssen während des Tippens ja auch noch weiterdenken... Ich denke mal, ein Profi kann in ASM den Code durchaus Faktor 2 gegenüber einem wirklich guten C-Compiler verschnellern. Je nach Spezialbefehlen der CPU manchmal sogar erheblich schneller. Ein wirklich guter C-Compiler ist z.B. der von Keil. Da ist wenn man es im generierten Code ansieht, wirklich nicht mehr viel zu machen. Sogar die einzelnen Flag-Bits sammelt dieser Compiler in Bytes ein. Nur der Preis würg Gruß - Abdul
> Ein Art Religion.
Naja, eher eine Art Alphabet... Und die Hochsprache enthält dann die
(vorgefertigten) Textbausteine.
... die leider allzuoft benutzt werden, ohne verstanden zu haben, was
sie eigentlich aussagen. Siehe Briefe von Ämtern, Behörden und anderen
Büros. ;-)
...
ey, wer mißbraucht da meinen Namen? Der Grund ist, daß herrausgefunden werden soll, ob das Display wirklich so langsam ist, oder der Code. Nur wenn ich mir die ganzen Videos bei youtube ansehe, kann es nur der Code sein. Jedes 5€ Seriell-USB-Mp3-Display hat astreine Scroll- und Grafikoptik
>Der Grund ist, daß herrausgefunden werden soll, ob das Display wirklich >so langsam ist, oder der Code. Also mit T6963 240x64 Pixel hab ich schon 100 FPS geschafft. In C natürlich. Dabei wurde aber nicht jeder Pixel einzeln gesetzt oder gelöscht. Immer schön byteweise rein mit den Daten. Wobei die 100 FPS Quatsch sind. Ab 10 FPS leidet der Kontrast schon ganz schön. Fazit: Das Display ist schnell genug.
Hi >Der Grund ist, daß herrausgefunden werden soll, ob das Display wirklich >so langsam ist, oder der Code. Da reicht ein Blick ins Datenblatt des Displays. MfG Spess
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.