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.
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.
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...
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
GLCD_segments.png
(25 KB)
