Oldie70 hat geschrieben: Mo Aug 18, 2025 19:36
Leider ist es mir jedoch noch nicht gelungen, auch einzelne Pixel an bestimmten Stellen zu zeichnen, welches aber zwingend notwendig ist, um die Schattenflächen richtig darzustellen. Habe bereits sämtliche Datenblätter kompatibler Displaycontroller (GC9A01,GC9D01,ST7789..) studiert und nach diesen Befehlssätzen gearbeitet, das Display schreibt jedoch nur teilweise, an falschen Stellen usw., es macht gefühlsmäßig was es will....
Hallo, dass kann hier ja keiner überprüfen ob dein Code sich wirklich am Datenblatt orientiert!
Oldie70 hat geschrieben: Mo Aug 18, 2025 19:36
soweit, daß ich das Display richtig initialisiert habe und das Grundbild darstellen kann.
Wenn du grundsätzlich komplette Framebuffer/Displayspeicherabbilder auf das Display fehlerfrei bringen kannst, also Vollbilder, es jedoch Probleme gibt bei grafischen Operationen die nur einen Teil des Framebuffer ändern, dann würde ich schauen ob du dort mit deinen selbst implementierten Zeichenroutinen eine richtige Adressierung vornimmst. Im Datenblatt steht die Organisation des Speichers drin. Beim nächsten Refresh wird dann der fehlerhaft geänderte Speicherinhalt zur Anzeige gebracht.
Du kannst ja auch eine Beispiellib zum Display anschauen, die diese Funktion anbietet und wie die das machen und dann in dein ASM Code portieren. Oder du übersetzt die Lib und nimmst dann den ASM-Teil der die Funktion realisiert raus und passt ihn an deinen Code an.
Dabei ein paar Fragen zusätzlich? Warum ASM? Eigentlich ist das doch nur ein legitimes Ziel wenn man daran Spaß hat Asm-Code selbst zu schreiben und für die gleiche Funktionalität nichts ausmacht mehr Lines of code (LOC) eintippen zu müssen, als bei Compilersprachen. Die Vorstellung besseren und schnelleren ASM Code zu schreiben, als es der Compiler mit aktiven Übersetzungsoptionen (smallest, fastest Code) kann, kann man bei heutigen Übersetzern doch eigentlich vergessen. Da gibt es in den wenigsten Fällen noch die Notwendigkeit/Möglichkeit händisch was zu optimieren.
Oldie70 hat geschrieben: Mo Aug 18, 2025 19:36
Leider basieren alle bisherigen Vorschläge auf Arduinos, mit dem Nachteil daß sie
1. zu viel Platz einnehmen
2. mit den Bibliotheken enorm viel Speicherplatz verschwenden
3. daher damit praktisch mit Kanonen auf Spatzen geschossen wird
Da die Arduinos ja auch nur minimale Fertigplatinen mit ATmega drauf sind, denke ich zu 1. das du im Vergleich zu deinem gezeigten Aufbau mit DIP-ICs baulich absolut keinen Größenvorteil hast! Im Vergleich zu Arduino Nano / Micro . Du wirst schwerlich auf gleiches oder kleineres Format kommen.
_14_600x600.jpg
Noch extremer wird dein Nachbau einen Größennachteil haben, wenn man sich eine Kaufoption eines runden Displays anschaut, welches auf der eigenen PCB einen Microcontroller für die Anwendungsfirmware drauf hat.
22023_4.jpg
Im gezeigten Beispiel sogar ein Rp2040 Dualcore mit 133 MHz und viel "Grafik"speicher für andere fotorealistische Schirmbilder mehrerer Röhrentypen.
Zu 2. Wenn eine Beispiellib für dein Display + sämtliche Daten zum Schirmbild in den Speicher des Controllers passt, wo ist dann was verschwendet? Was soll das Gesamtsystem mit mühevoll gesparten Speicherplatz anfangen, der im laufenden Betrieb nie allokiert wird aber im Chip vorhanden ist?
Für den Fall, wenn die funktionierende Lib + Daten nicht in den Speicher geht, ist es im Gegensatz zur vollständigen Neuimplementierung eine Kleinigkeit ungenutzten Code aus einer Header und Implementierungsdatei der Lib zu entfernen. Wenn ich nur Vollbilder und Pixel zeichnen will, kann ich doch im Handumdrehen Methoden/Funktionen zum Zeichnen von Zeichenketten (drawString..... o.ä.) markieren und entfernen. Ich habe so schon Herstellerlibs auf 5-10% der Ursprungsgröße gebracht, was aber nur Sinn macht, wenn man eben den dadurch eingesparten Speicher auch für andere Sachen nutzt!
zu 3. Du ersetzt auch in deiner Lösung das Kaliber der Kanone nicht ( ATmega 328 SMD auf kleinerem Board durch ATmega328 DIP ), im Moment lebt der Spatz nur weiter, weil deine Kanone (noch nicht) schießt, was sie im Vergleich zum Democode/Lib des Herstellers aber schon machen würde?!
Daher denke ich das dein Weg über ASM Code direkt und vollständige Neuimplementierung des Treibers und der Zeichenlib nur Sinn macht, wenn genau das das Ziel des Projektes sein soll und nicht die schnellst möglich funktionelle Umsetzung einer funktionierende MagicEye Sim. Was aber legitim ist!
Nur um nochmal auf
Oldie70 hat geschrieben: Mo Aug 18, 2025 19:36
mir evtl. Tipps geben kann?
zurückzukommen.
Mit den vorliegenden Infos aus dem Eingangspost kann das keiner, selbst wenn er Lust dazu hat. Denn wie soll die Funktionalität deines Codes gegen das vom Hersteller im DB vorgesehene Vorgehen geprüft werden können? Irgendetwas was ein Hilfe- oder Tippgeber in einen Simulator laden kann, würde helfen. Mit Wokwi könnte man den ASM Code auf einem simulierten GC9A01 (gibt es als Erweiterung, siehe google) laden und , zwar nicht in Echtzeit, schauen wo ein fehlerhafter Grafikspeicherinhalt entsteht.
Sie haben keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
) soweit, daß ich das Display richtig initialisiert habe und das Grundbild darstellen kann. Leider ist es mir jedoch noch nicht gelungen, auch einzelne Pixel an bestimmten Stellen zu zeichnen, welches aber zwingend notwendig ist, um die Schattenflächen richtig darzustellen. Habe bereits sämtliche Datenblätter kompatibler Displaycontroller (GC9A01,GC9D01,ST7789..) studiert und nach diesen Befehlssätzen gearbeitet, das Display schreibt jedoch nur teilweise, an falschen Stellen usw., es macht gefühlsmäßig was es will....