Moin, ich habe ein uraltes Monochrom-LCD mit 128x128 Pixeln, das ich gerne an einen Raspberry anschließen möchte. Da die meisten GPIOs belegt sind, will ich das Display über SPI anbinden und habe dazu einen PIC-Controller dazwischen geschaltet, der das Display ansteuert (und zudem über die PWM und eine Chargepump die negative Kontrastspannung erzeugt). Jetzt frage ich ich, welche Funktionen der PIC aus Sicht des Host sinnvollerweise bereit stellen sollte. Die Minimalanforderungen sind natürlich: - Pixel setzen/löschen - Bitmap in ein Rechteck kopieren - Text ausgeben (Text/Grafikmodus) Damit kann man ja eigentich schon alles machen, aber der PIC könnte natürlich auch Funktionen für Grafikprimitive bereitstellen, z.B. - Rechteck leer/gefüllt mit runden/kantigen Ecken - Ellipse leer/gefüllt - Gerade - Allgemeine Polygone leer/gefüllt Nice to have: - Steuerung des Kontrasts über den PWM Cycle Bisher ist noch relativ viel Platz im PIC, da geht schon noch was rein. Aber welche Funktionen sind sinnvoll? Wie machen das andere Controller? Habt ihr Erfahrungen/Anregungen dazu? Gibt es so etwas wie eine Standard-API and dieser Stelle? Danke!
Du könntest dir einfach mal das Datenblatt eines SPI-LCD Controllers anschauen, mir fallen im Moment z.B. die DOG LCD ein: http://www.reichelt.de/index.html?ACTION=2;GROUPID=3007;SEARCH=DOG%20LCD-Module Der verbaute Controller ist oft ein ST7565R, so das dessen Befehlssatz evtl. ein Anhaltspunkt wäre. Das hat den Vorteil, das du nicht unbedingt alles selbst entwickeln müsstest, was auf dem RPi läuft. Es gab auch mal ein SPI Display von Nokia, das recht weit verbreitet war, allerdings habe ich die Bezeichnung nicht parat. Wimre, lief das in den alten 3310 Telefonen.
Ich habe das Datenblatt des ST7565R gerade mal durchgeschaut, danke für den Hinweis. Es sieht so aus, dass der gar keine Zeichenfunktionen bereitstellt, nur set/clear pixel. Das erzeugt natürlich eine gewisse Last auf dem SPI, aber vielleicht läuft es darauf hinaus.
Hi >Es sieht so aus, dass der gar keine Zeichenfunktionen >bereitstellt, nur set/clear pixel. Nicht mal das. Es können nur Bytes geschrieben oder gelesen werden. Zeichenfunktionen findest du bei EA eDIP/EA eDIPTFT Displays. MfG Spess
Vancouver schrieb: > Jetzt frage ich ich, welche Funktionen der PIC aus Sicht des Host > sinnvollerweise bereit stellen sollte. Die Minimalanforderungen sind > natürlich: > > - Pixel setzen/löschen > - Bitmap in ein Rechteck kopieren > - Text ausgeben (Text/Grafikmodus) > > Damit kann man ja eigentich schon alles machen, aber der PIC könnte > natürlich auch Funktionen für Grafikprimitive bereitstellen, z.B. > > - Rechteck leer/gefüllt mit runden/kantigen Ecken > - Ellipse leer/gefüllt > - Gerade > - Allgemeine Polygone leer/gefüllt Das hängt natürlich auch ganz stark davon ab was du vorhast. Wenn das Display nur zur Bedeinung deiner Heizung dient, sind die Ansprüche wesentlich kleiner als wenn du vorhast ein 3D Ego-Shooter zu implementieren. Für letzteres wäre ein 2. Framebuffer im PIC interessant und Block-copy Kommandos, oder Sprites. Dann wird aus deinem PIC schon fast ein kompletter Grafikcontroller :-)
> Das hängt natürlich auch ganz stark davon ab was du vorhast. Wenn das > Display nur zur Bedeinung deiner Heizung dient, sind die Ansprüche > wesentlich kleiner als wenn du vorhast ein 3D Ego-Shooter zu > implementieren. Es geht um die Darstellung von Statusmeldungen mit ein paar grafischen Elementen (z.B. progress bar, Zeigerinstrument, usw), das ganze mit <= 10 updates/sec, aber natürlich kein Video und kein 3D. Es soll später etwa so aussehen wie das hier: https://www.youtube.com/watch?v=C1gVPZOxyYc Die eDIP/EA treiben das natürlich auf die Spitze, das macht der PIC wahrscheinlich nicht mehr mit...
Hi >Es soll später >etwa so aussehen wie das hier: >Youtube-Video "DOGXL160-7 Pedelec Display" Und wozu brauchst du dann den Rasberry? Das kann ein 8-Bitter problemlos. Mfg Spess
Vancouver schrieb: > Es geht um die Darstellung von Statusmeldungen mit ein paar grafischen > Elementen (z.B. progress bar, Zeigerinstrument, usw), das ganze mit <= > 10 updates/sec, aber natürlich kein Video und kein 3D. Es soll später > etwa so aussehen wie das hier: > Youtube-Video "DOGXL160-7 Pedelec Display" Wenn's nur um diese Anwendung geht (oder eine Ähnliche), könnte man sich sogar ein dediziertes API ausdenken. Dabei kümmert der PIC sich um die ganze Darstellung und das RasPi schickt lediglich die einzelnen Werten wie Geschwindigkeit, Akkuladestatus usw.
> Und wozu brauchst du dann den Rasberry? Das kann ein 8-Bitter > problemlos. Das war nur ein Beispiel um zu zeigen wie die Anzeige aussehen könnte. Die Anwendung ist eine andere, die braucht richtig Rechenleistung (eigenttlich ist es es ist auch kein RaspPi sondern ein BananaPi, weil der Raspberry zu langsam ist).
Vancouver schrieb: > Gibt es so etwas wie eine > Standard-API and dieser Stelle? Nicht wirklich. Deine Anforderung erinnert mich ein wenig an die Grafik-Terminals vergangener Tage wie zb ein Tektronix 4105. Aber anders als der DEC-VT100 Standard, hat es bei den Grafik-Terminals keines geschafft, so etwas wie einen De-Facto Standard zu setzen. Am ehesten war es noch besagtes 4105, bei dem man oft Glück hatte, wenn Software es unterstützte. > Aber welche Funktionen sind sinnvoll? Die die du benutzen kannst. Ich denke, einer der wichtigsten Punkte ist es, dass du dir so etwas wie eine Kommando-Syntax zurecht legst, so dass du auch in Zukunft noch erweitern kannst. Es bringt auch nichts, wenn du jetzt rein auf Verdacht dir eine Menge Funktionen einfallen lässt und implentierst, die du dein Leben lang nicht brauchst.
Wie wäre es, einen Interpreter für (einen Deinen Anforderungen entsprechenden Subset von) HP-GL/2 (https://en.wikipedia.org/wiki/HPGL) auf dem PIC zu implementeiren? Es gibt auch noch cairo (http://cairographics.org) aber das ist wohl eine sehr dicke Kanone für so einen PICcolo ;)
Man könnte auch zb u8glib für den pic32 über diverse "Register" oder bytesequenzen einbinden. Zb. Aus drawrect() macht man fix dr(sx,sy,w,h), auf spi schickt man dann "dr 0 0 10 50" Oder Drawrect= Register 1F =1 dann mit Daten aus den Registern sx sy w h Funktion aufrufen.
Warum vorher festlegen? Die halbwegs verbreiteten Protokolle sind zu umfangreich. Implementierung dauert ewig und 90% brauchst du eh nicht. Du willst sowieso nur mit einem Anwendungsprogramm benutzen. Nimm doch ein erweiterbares Protokoll und bei jedem Problem, was sich auf dem Pic einfacher lösen lässt, erfindest du ein neues Kommando.
Vielen Dank für Eure Antworten, das sind alles sehr gute Ideen und Hinweise.
Meine Empfehlung: den PIC so wenig wie nur möglich machen lassen, also nur Framebuffer anzeigen. Malen kannst du dann auf dem Raspberry PI bequem mit cairo machen.
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.