Hallo Leute, kann man bei einem seriell (SPI) angesteuerten GLCD ein einzelnes Pixel setzen ohne die jeweils anderen Pixel aus dem Segment zu überschreiben. Das Lesen ist ebendfalls leider über die serielle Schnittstelle nicht möglich... Ich möchte auch keinen Framebuffer einsetzen! Ich benutze ein GLCD mit ST7565R Controller.
Angehängte Dateien:
-
GLCD_segments.png
25 KB
Hallo, gibts denn in Datenblatt einen Befehl zum setzen von einzelnen Pixeln? Wenn nicht, dann hast du unter den von Dir gestellten Randbedingungen keine Möglichkeit. Sascha
Patrick L. schrieb: > kann man bei einem seriell (SPI) angesteuerten GLCD ein einzelnes Pixel > setzen ohne die jeweils anderen Pixel aus dem Segment zu überschreiben. Nein. Patrick L. schrieb: > Das Lesen ist ebendfalls leider über die serielle Schnittstelle nicht > möglich... Hmm, das ist ein verbreitetes Problem. Bietet das GLCD einen I2C-Modus? in diesem kann nämlich auch gelesen werden. Patrick L. schrieb: > Ich möchte auch keinen Framebuffer einsetzen! Tja - das ist natürlich Pech. Wirst Du aber im Worst Case nicht drumherum kommen.
Angehängte Dateien:
-
GLCD_readData.png
34 KB -
GLCD_commands.png
98 KB
Stefan S. schrieb: > Wie hast du das GLCD angeschlossen? MISO vorhanden und genutzt? MISO ist am GLCD nicht vorhanden. Scheint auch keine möglichkeit zu geben seriell Daten zu lesen... Siehe Bild. Sascha W. schrieb: > Hallo, > > gibts denn in Datenblatt einen Befehl zum setzen von einzelnen Pixeln? > Wenn nicht, dann hast du unter den von Dir gestellten Randbedingungen > keine Möglichkeit. > > Sascha So wie ich das sehe gibt es keinen Befehl (siehe Bild). Man kann wohl immer nur ganze Segment (mit je 8-Bit) schreiben. Dann überschreibe ich mir natürlich meine alten Pixel die ich in dem Segment schonmal geschrieben habe. Knut B. schrieb: > Hmm, das ist ein verbreitetes Problem. Bietet das GLCD einen I2C-Modus? > in diesem kann nämlich auch gelesen werden. Leider nicht... > Tja - das ist natürlich Pech. Wirst Du aber im Worst Case nicht > drumherum kommen. Sieht wohl ganz so aus...
hast wohl auch nicht genug Pins für eine parallele Ansteuerung? Sascha
Sascha W. schrieb: > hast wohl auch nicht genug Pins für eine parallele Ansteuerung? Im Moment auf dem Entwicklungsboard schon. Später in der Anwendung würde ich gerne mit so wenig Pins wie möglich auskommen.
Patrick L. schrieb: > kann man bei einem seriell (SPI) angesteuerten GLCD ein einzelnes Pixel Schau dir mal die lib für das Schreiben von z.B. Fonts an. Da wird jeder Buchstabe aus einzelnen Pixeln gemalt. Natürlich kannst du ein einzelnes Pixel setzen. Zumindest bei den ili-spi-glcds ist das so.
grundschüler schrieb: > Schau dir mal die lib für das Schreiben von z.B. Fonts an. Da wird jeder > Buchstabe aus einzelnen Pixeln gemalt. Grundsätzlich richtig, du musst allerdings beachten das viele GLCDs nur ganze Segmente schreiben können. Bei meinem eingesetzten ist das so. Ich kann immer nur ganze 8-Bit schreiben. Möchte ich jetzt nur ein Bit davon setzen überschreibe ich zwangsläufig die alten Bits mit Nullen.
Patrick L. schrieb: > kann man bei einem seriell (SPI) angesteuerten GLCD ein einzelnes Pixel > setzen ohne die jeweils anderen Pixel aus dem Segment zu überschreiben Das kommt auf das GLCD an. Wenn es eines der "dummen" Sorte ist, wo du im wesentlichen nur wortweisen Zugriff auf den Framebuffer hast, dann mußt du entweder den aktuellen Displayinhalt auslesen oder schon kennen (zweiter Framebuffer außerhalb des Displays) > Das Lesen ist ebendfalls leider über die serielle Schnittstelle nicht > möglich... Ich möchte auch keinen Framebuffer einsetzen! Tja. Keine Arme, keine Kekse!
Patrick L. schrieb: > Grundsätzlich richtig, du musst allerdings beachten das viele GLCDs nur > ganze Segmente schreiben können. Bei meinem eingesetzten ist das so. Ich > kann immer nur ganze 8-Bit schreiben. > > Möchte ich jetzt nur ein Bit davon setzen überschreibe ich zwangsläufig > die alten Bits mit Nullen. Ich habe das mal schon mal selber implementiert und hab das so gelöst: Im Controller gibts ein RAM, das genau gleich groß ist wie das im Display. Da drin kann man bequem und schmell einzelne Pixel setzen. Das RAM ist genau gleich strukturiert wie das im Display, so dass das der Inhalt mit einem einzigen Schreibvorgang in das GLCD geladen werden kann. Ich mach das mit DMA. Das war bei meinem Display die einzige Möglichkeit für halbwegs schnelle "read-modify-write" Operationen.
WehOhWeh schrieb: > Patrick L. schrieb: >> Grundsätzlich richtig, du musst allerdings beachten das viele GLCDs nur >> ganze Segmente schreiben können. Bei meinem eingesetzten ist das so. Ich >> kann immer nur ganze 8-Bit schreiben. >> >> Möchte ich jetzt nur ein Bit davon setzen überschreibe ich zwangsläufig >> die alten Bits mit Nullen. > > Ich habe das mal schon mal selber implementiert und hab das so gelöst: > Im Controller gibts ein RAM, das genau gleich groß ist wie das im > Display. Genau das nennt man einen 'Framebuffer' und genau so einen möchte er nicht benutzen (laut Eingangsposting). Axel hat es schon auf den Punkt gebracht: Keine Arme, keine Kekse. Dumm gelaufen.
Patrick L. schrieb: > Ich möchte auch keinen Framebuffer einsetzen! Wie bereits erwähnt, hast Du damit verloren. Selbst, wenn man die Daten aus dem Display auslesen könnte, würde ich einen Bildpuffer verwenden.
Hi >Genau das nennt man einen 'Framebuffer' und genau so einen möchte er >nicht benutzen (laut Eingangsposting). Dann muss er sich in seinem Fall halt etwas an die Höhe einer Page orientieren. Ich mache das schon seit über 15 Jahren für Displays (240x64) mit Touchscreen ohne Rücklesen und ohne Framepuffer. MfG Spess
spess53 schrieb: > Ich mache das schon seit über 15 Jahren für Displays (240x64) mit > Touchscreen ohne Rücklesen und ohne Framepuffer. Das wollen wir aber jetzt sehen! Oder kann Dein Kontroller einzelne Bits setzen/rücksetzen? Der genannte ST7565R kann das nicht.
spess53 schrieb: > Hi > >>Genau das nennt man einen 'Framebuffer' und genau so einen möchte er >>nicht benutzen (laut Eingangsposting). > > Dann muss er sich in seinem Fall halt etwas an die Höhe einer Page > orientieren. Ja. Wenn er keinen Framebuffer will und nicht zurücklesen kann, dann ist es nicht möglich jedes einzelne Pixel völlig wahlfrei zu setzen oder zu löschen. In dem Fall muss man dann eben die Anzeige so gestalten, dass dies nicht notwendig ist oder eben irgendwie anders berücksichtigen, was an dieser Stelle sonst noch so angezeigt wird. Aber irgendeinen Tod muss er sterben.
Patrick L. schrieb: > Möchte ich jetzt nur ein Bit davon setzen überschreibe ich zwangsläufig > die alten Bits mit Nullen. Na dann merk dir doch, welche Bits in dem Byte schon gesetzt sind und übertrage alles auf einmal. Kann dir doch wurscht sein wenn ein schon gesetztes bit noch mal gesetzt wird. Irgendeinen Kuhhandel musst du schon eingehen, man bekommt halt nix geschenkt. Warum willst du eigentlich keinen Framebuffer verwenden?
Michael K. schrieb: > Na dann merk dir doch, welche Bits in dem Byte schon gesetzt sind und > übertrage alles auf einmal. Das ist ja eine grandiose Idee.
Michael K. schrieb: > Warum willst du eigentlich keinen Framebuffer verwenden? Ich schätze mal, er wird den Speicher nicht haben. Es kommt immer auf die Anwendung an. Aber solange man nicht mit Bildern hantieren muss, ist es oft so, dass man nicht in allen Anzeigebereichen völlig wahlfrei lesen/schreiben können muss. Oft reduziert sich das auf ein paar Bereiche. Dann kann man eventuell nur für diese Bereiche einen kleineren Framebuffer einrichten. Aufwändig? Ja klar. Aber von nix kommt nix. Zauberei geht halt nur in Hogwards. Alternativ bleibt natürlich immer noch, ein anderes GLCD zu benutzen oder auf paralleles Interface umzustellen.
m.n. schrieb: > Michael K. schrieb: >> Na dann merk dir doch, welche Bits in dem Byte schon gesetzt sind und >> übertrage alles auf einmal. > > Das ist ja eine grandiose Idee. Genau, deshalb gibts die u8glib. Ich hab die u8glib genau deshalb entwickelt, weil man bei dem ST7565R keine einzelnen Bits mit SPI setzen UND weil ich nicht den kompletten Framebuffer im Speicher des uC halten wollte. Oliver
u8glib schrieb: > Genau, deshalb gibts die u8glib. Und was kannst du damit bewerkstelligen? Wenn man keinen Bildspeicher im µC hat, ist man eben auf's Rücklesen angewiesen und wenn auch das nicht geht, dann muß man seine grafischen Gadgets eben bei allen_ Veränderungen sich selbst zeichnen lassen _und strikt dafür sorgen, daß sie sich bytemäßig im Dieplay-RAM nicht in die Quere kommen. Das ist ganz schön einschränkend. Die Alternative wäre Banding, also einen Streifen (auf dem Stack festlegen und alle Gadgets sich zeichnen lassen und alles was nicht in den aktuellen Streifen reingeht, ins Nirwana schreiben, dann diesen Streifen ausgeben, dann einen nächsten Streifen festlegen, dann das gleiche Spielchen... Tja, so geht's, wenn man zuvor nicht gründlich plant. W.S.
W.S. schrieb: > Die Alternative wäre Banding, also einen Streifen (auf dem Stack > festlegen und alle Gadgets sich zeichnen lassen und alles was nicht in > den aktuellen Streifen reingeht, ins Nirwana schreiben, dann diesen > Streifen ausgeben, dann einen nächsten Streifen festlegen, dann das > gleiche Spielchen... Genau so. Oliver
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.