Hallo, ich versuche derzeit, mich in 2 Dinge gleichzeitig einzuarbeiten, PIC18 in C zu programmieren (die "berühmte" LED blinkt schon) aber auch der obengenannte Grafikdisplaycontroller, ich nutze das Display unter Anderem bei Farnell, Nr. 2219021. Erster Versuch war, es seriell anzusteuern, die Schnittstelle des PICs sendet, ist mit den beiden Datenleitungen verbunden, aber, ich bekomme keine Reaktion des Displays zum Beispiel auf den Befehl RESET und später Set all Pixels ON. Nun bin ich erstmal auf der Suche, ob ich überhaupt das Display richtig angeschlossen habe, es gibt im Datenblatt auf der letzten Seite die Skizze (das auf kariertem Papier), aber auch das hier : http://bascom.at.ua/2014/Bibla128240B/SPI_mode.jpg Genau so habe ich es mal angeschlossen (Steckbrett, aber alle Spannungen gemessen), was mich am Meisten stutzig macht, im Datenblatt, Pin 5, V_LCD, laut Datenblatt 0,3....17V, aber, wo sollen die herkommen? Muss ich die einspeisen? Ich sehe auf dem Display lediglich einen ganz leichten Grauschleier im Anzeigebereich, der sich aber nicht verändert, egal was ich an das Display sende. Bisher sende ich zuerst RESET, dann den Befehl Set all Pixels on. Braucht es noch mehr zum Initialisieren? Hat jemand das Display, seriell angesteuert, im Einsatz und weiß ein bisschen was? Vielen Dank und viele Grüße, Michael
Hallo, vielleicht wirst Du hier fündig: http://www.hpinfotech.ro/cvavr_examples.html Oder Du suchst nach "uc1608 code github" etc. Der Schritt von der blinkenden LED zur Ansteuerung eines Grafik-Displays ist schon ein recht großer. So wie wenn Neil mal die Leiter herunterkommt. Datenblatt Figure 11 würde ich als Anschlußbild vorschlagen. Das ist aber nur schematisch. aus simple Demo.txt : Pin 17 DB0(SCK) - PORTA bit 0 Pin 16 DB1 - GND (must be connected !) Pin 15 DB2 - GND (must be connected !) Pin 14 DB3(SDA) - PORTA bit 3 Pin 13 DB4 - GND (must be connected !) Pin 12 DB5 - GND (must be connected !) Pin 11 DB6 - GND (must be connected !) Pin 10 DB7 - +3.3V (must be connected !) Pin 18 /RD - GND (must be connected !) Pin 19 /WR - GND (must be connected !) Pin 20 CD - PORTD bit 2 Pin 21 /RST - PORTD bit 3 Pin 22 CS - PORTD bit 4 Pin 23 BM0 - GND Pin 24 BM1 - GND Seite 35 "SAMPLE POWER COMMAND SEQUENCES" bräuchtest Du als Vorlage zur korrekten Initialisierung. Vlcd erzeugt das Display intern mittels Ladungspumpe. Die Spannung kannst Du an dem Pin messen. Den Kondensator benötigt es zur Glättung. Der Widerstand sorgt für den Abbau der Spannung, da es nach dem Abschalten dem Glas schaden würde, wenn die Spannung lange anstehen würde. Sie läßt sich vermutlich über Befehle verändern. Mit freundlichem Gruß
:
Bearbeitet durch User
Hallo Christian und andere Mitleser, danke für den Link, da habe ich paar weitere Sachen gefunden, aber, leider immer noch kein Erfolg..... Ich habe mich jetzt mal darauf konzentriert, die einzelnen Steuerbytes RESET, dann Set Gain, dann Enable zu senden, sozusagen ohne Ablauf, nur mit paar Pausen. Danach dann SET all Pixel On, das LSB, D0 zeigt ja an, ob ich aus- oder einschalten will, oder verstehe ich das falsch? Ich stelle mir vor, der Schirm blinkt dann dunkel/hell, ist das überhaupt richtig? Habe mit Oszi die Signale der seriellen Schnittstelle geprüft. Ich möchte im Gegensatz zur obigen Info das 3Wire-Interface nutzen, da brauche ich doch die Leitung CD nicht (bzw. ich lege sie auf Masse), da CD doch das erste Bit laut Datenblatt Seite 25 ist, CD, dann D7...D0? Ganz blöde Frage, die Bitreihenfolge passt so aber schon? Denn, der PIC18F14K22 sendet die Bits ja genau andersherum, laut Datenblatt, ich muss die also rumdrehen vor dem Senden? Hast Du zufällig auch die libs glcd.h irgendwo? Denn, da müssten ja die einzelnen Befehle drin stehen, die in den kleinen und großen Beispielen main.c genutzt werden? Zu mir selbst : Ich bin schon 'ne Zeitlang mit PICs beschäftigt, beruflich, einige Elektroniken gehen da auf mein Konto, aber bisher immer in Assembler. Möchte aber auf C umsteigen, da ich mir davon etwas "einfacheres" Programmieren vorstelle, auch im Ausblick auf die Zukunft, bisschen hardwareunabhängiger werden. Viele Grüße, Michael
....Nachtrag : Ich messe auf den ganzen Pins, 1,2,3,4 mit den Elkos 4,7µF keine Spannung und auf Pin 5 und 6 auch lediglich 50mV. Pin 8 zum Beispiel 3,3 V. ACHTUNG, habe festgestellt, ich habe ein Display mit 23 Anschlüssen, der erste aus dem Datenblatt bei Dir nc (not connected), ist bei mir nicht vorhanden. Also, auf das hier genannte Datenblatt übersetzt : Ich messe auf den ganzen Pins, 2,3,4,5 mit den Elkos 4,7µF keine Spannung und auf Pin 6 und 7 auch lediglich 50mV. Pin 9 zum Beispiel 3,3 V. Viele Grüße, Michael
Hallo, zuerst müßtest Du wissen, ob das auf Deinem Tisch liegende Display die Leitungen alle heraus führt, um den von Dir favorisierten Modus realisieren zu können. Der Chip innen drin kann wohl alles, was das UC1608 Datenblatt anbietet, aber nicht immer ist alles von außen zugänglich. Vielleicht kann Dir jemand helfen, wenn Du den Typ des Displays angibst und nicht nur den Controller. Am besten wäre es, ein vorgefertigtes Beispiel, also Schaltung mit Code nachzubauen. Die einzelnen Befehle nützen wenig, wenn Du die Powerup-Sequenz nicht zuerst gesendet hast. Man könnte auch versuchen, das Statusregister auszulesen. Setallpixelson sollte das ganze Diplay schwärzen. Reihenfolge ist in Figure 4c angegeben. Die Lib ist vermutlich irgendwo beim IAR-Compiler zu finden. Ich habe nur den Beispielcode nach kurzer Suche gefunden. Es wäre evtl sinnvoll, zuerst mal das Datenblatt, insbesondere die Befehle und das Anschlußschema zu verstehen, bevor noch was zerstört wird. Für ungeübte sind die Beschreibungen recht unübersichtlich. Meistens kapiert man das erst anhand von Beispielcode. Mit freundlichem Gruß
Hallo Michael, kannst Du uns ein Bild von Deinem Aufbau zeigen? Hier noch ein paar Links: Dislay: http://www.farnell.com/datasheets/2021853.pdf Controllerchip: http://www.hpinfotech.ro/UC1608.pdf PIC: http://ww1.microchip.com/downloads/en/DeviceDoc/40001365F.pdf > Habe mit Oszi die Signale der seriellen Schnittstelle geprüft. Zeig doch mal. Wie sind denn bei Dir BM0 und BM1 beschalten? > Denn, der PIC18F14K22 sendet die Bits ja genau andersherum, laut > Datenblatt, ich muss die also rumdrehen vor dem Senden? Eigentlich nicht. Der PIC schickt mit MSB first und das Display will auch MSB first. > ist mit den beiden Datenleitungen verbunden Blöde Frage, hast Du nur die Datenleitung verbunden, oder auch die Masse (GND)?
Hi >Ich habe mich jetzt mal darauf konzentriert, die einzelnen Steuerbytes >RESET, dann Set Gain, dann Enable zu senden, sozusagen ohne Ablauf, nur >mit paar Pausen. Was ist mit der Initialisierung des Displays? Also Sachen wie - Set Mux Rate and temperature compensation - Set LCD Mapping Control - Set LCD Bias Ratio - Set Gain and Potentiometer MfG Spess
Hallo, probier doch mal, ob Du mit dieser Bibliothek etwas anfangen kannst. https://bintray.com/olikraus/u8glib/AVR/1.18.1 https://github.com/olikraus/U8glib_Arduino Nach Auspacken der ZIP-Datei kannst Du die Datei zu Deinem Display heraus suchen und findest die Initialisierung. Leider ist der Code sehr kompliziert geschrieben. u8g_dev_uc1608_240x128.c /* see also ERC24064-1 for init sequence example */ static const uint8_t u8g_dev_uc1608_240x128_init_seq[] PROGMEM = { mit freundlichem Gruß
:
Bearbeitet durch User
Michael schrieb: > ....Nachtrag : > > Ich messe auf den ganzen Pins, 1,2,3,4 mit den Elkos 4,7µF keine > Spannung und auf Pin 5 und 6 auch lediglich 50mV. > Pin 8 zum Beispiel 3,3 V. An PIN5 müssen 15V stehen. Ist das nicht so, hast du das Display nicht initialisiert und es ist ausgeschaltet. In dem Fall kann es nichts anzeigen. Das ist so: Dein Display erzeugt mittels Kondensatoren (charge-Pump) eine Kontrastspannung (eben jene 15V) und speichert sie im Kondensator am PIN5. Die Spannung ist nötig, um die Pixel umzudrehen. Mit 3,3V geht das nicht. Jetzt muss du dem Display zu Beginn sagen, dass es jene Spannung aufdrehen sol. Dazu ist eine Kette von Befehlen nötig. Siehe dazu Command Table auf S10 des Datenblatts und darunter. Kopier dir im besten Fall die Routine von einer der oben genannten Libs. D.h. du musst also: - Strom einschalten (falls das bei dir schaltbar ist) - Einen bestimmten Zeitraum warten, bis es betriebsbereit ist (15ms?) - Eine Initroutine durchlaufen Dann kannst du erst Daten schreiben. Ich fühle mit dir. Mein erstes Display war ein DOGXL, auf ich habe lange damit gekämpft. Aber umso härter der Kampf, umso größer das Erfolgserlebnis, wenn das erste Rechteck erscheint :-)
Wenn man das beherrscht, ist man eine viel gefragte Displayinitialisierungsfachkraft. Hier noch: https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=110469 https://github.com/Matmook/PiTris oder in Assembler: (ganz unten) http://www.midasdisplays.com/products/controllers-on-board-32.page mit freundlichem Gruß
:
Bearbeitet durch User
Hallo und erstmal DANKE an alle, die sich beteiligen, ich versuche mal die Fragen der Reihe nach zu beantworten, indem mich meinen Versuchsaufbau beschreibe. Steckbrett, erwähnte ich ja schon, aber, ich messe die Spannungen jeweils direkt an den Pins des Displays. PIC steckt übrigens mit drauf, die Frage, ob GND verbunden sei, sehe ich NICHT als blöd an, beantworte sie mit "Ja, alle beteiligten Geräte, Messgerät, Oszi, Programmer, PIC, Display liegen auf derselben Masse. Aber, der Reihe nach, zunächst mal die Anschlüsse, wie gesagt, mein Display, Farnell Nummer 2219021 hat nur 23 Pins, der Pin1, der bei den anderen hier nc ist, ist bei mir nv (nicht vorhanden ;-) ). Ich beginne also mit Pin1 VB1- Hier die Belegung : 1 : Elko 4,7µ MINUS, hier gemessen 0V 2 : + vom Elko, hier gemessen 0V 3 : Elko 4,7µ MINUS, hier gemessen 0V 4 : + vom Elko, hier gemessen 0V 5 : 100nF Keramik || 10MOhm gegen Masse, hier gemessen 0V 6 : 100nF Keramik gegen Masse, hier gemessen 0V 7 : Masse 8 : 3,3V, dazwischen 100n und 10µ als Entkopplung 9 : 3,3 V 10: GND 11: GND 12: GND 13: Datenleitung vom PIC, weiter unten mehr 14: GND 15: GND 16: Taktleitung vom PIC, weiter unten mehr 17: GND 18: GND 19: GND (will ja vorab erstmal nur Kommandos senden) 20: 3,3V 21: 3,3V 22: 3,3V 23: GND Alle Spannungen an den Pins gemessen. Zu den Daten/Taktleitungen, das zweite Bild zeigt Oszilloskopbild, soweit sauber anliegend, 3,3V passt, hier der Befehl "set all Pixels ON", erkennbar am letzten Bit, also ganz rechts, das ist HIGH. Hierzu meine Frage, ich habe es aber auch schon andersherum getestet, stimmt die Reihenfolge der Bits? Also, das ganz rechte würde ich, aus Sicht des Displays als D0 sehen, in diesem Fall also set all Pixel=0 (entspricht aus). Ich wechsle das ja ab mit letztes Bit = 1, also set all Pixel = EIN, dann sollten doch alle an sein. Sind sie aber nicht, denke, weil die Spannungen des Displays selbst fehlen, das LCD hat keine, siehe oben, Pin5=0V. Weil vermutlich die Initialisierung schon nicht stimmt. Zu der komme ich jetzt : Erstmal, ich beginne grade in C, auf MPLABX, mit XC8. #include "main.h" #include <pic18f14k22.h> #include "C-TEST.h" Soweit klar. Dann in C-TEST.h erst die Definitionen : #define LCD_RESET 0b01000111 // RESET-Befehl für LCD, #define LCD_ALL_ON 0b10100101 // Alle Pixel an-Befehl für LCD #define LCD_ALL_OFF 0b00100101 // Alle Pixel aus-Befehl für LCD #define LCD_ENABLE 0b11110101 // Display enable #define GAIN_AND_POTI_LSB 0b10000001// Gain and Poti-Befehl LSB #define GAIN_AND_POTI_MSB 0b00000001// Gain and Poti-Befehl MSB #define MUX_AND_TEMP 0b00100100 // Mux and Temp-Befehl #define POWER_CONTROL 0b11110100 // Gain and Poti-Befehl LSB Ja, alle Werte andersherum als im Datenblatt, das meinte ich ja oben, aber, die Daten kommen so raus, wie Oszillogramm. Andersherum habe ich es auch probiert, keine Änderung. Dann paar PIC-spezifische Einstellungen, die scheinen zu gehen, Daten kommen ja raus wie gewünscht. Aber, jetzt, Daten ans Display : __delay_ms(30); BEFEHL_AN_DISPLAY(LCD_RESET); //Display zurücksetzen BEFEHL_AN_DISPLAY(LCD_RESET); //Display zurücksetzen __delay_ms(20); BEFEHL_AN_DISPLAY(MUX_AND_TEMP);//Display enable __delay_ms(20); BEFEHL_AN_DISPLAY(LCD_ENABLE); //Display enable __delay_ms(20); BEFEHL_AN_DISPLAY(POWER_CONTROL); //Display enable __delay_ms(20); // GAIN and POT, 2 Bytes hintereinander BEFEHL_AN_DISPLAY(GAIN_AND_POTI_LSB); BEFEHL_AN_DISPLAY(GAIN_AND_POTI_MSB); RESET sende ich zweimal, habe ich in einem Beispiel gesehen, vermutlich weil sonst vorher die Daten- und Taktsignale LOW sind, aber, auch sonst keine Änderung. Die Pausen, auch davor, sind drin, damit Display Zeit hat. Ab jetzt blinkt die LED fleißig vor sich hin, keine weiteren Daten ans Display. Wenn ich eine Taste drücke, wird folgendes getan, daraus erscheinen dann die Oszilloskopbilder, die Signale, das Programm, die Schnittstelle funktioniert also : BLINK_DISPLAY(void) { BEFEHL_AN_DISPLAY(LCD_ALL_ON); __delay_ms(250); //Pause BEFEHL_AN_DISPLAY(LCD_ALL_OFF); __delay_ms(250); //Pause } AAABER : Meine Erwartung, daß das Display nun in dem Takt blinkt, wird leider nicht erfüllt. Hat jemand eine Idee? Wie gesagt, oder auch schon weiter oben angemerkt, ich vermute, daß das Problem schon weiter oben in der Initialisierung liegt, das Display ist vermutlich garnicht an, es erzeugt sich ja keine Spannungen. Viele Grüße, Michael
Hallo, spess53 schrieb: > Was ist mit der Initialisierung des Displays? Also Sachen wie > > - Set Mux Rate and temperature compensation > - Set LCD Mapping Control > - Set LCD Bias Ratio > - Set Gain and Potentiometer Hier noch eine Antwort drauf, laut Datenblatt sind die nicht dringend notwendig, in meiner zuletzt versuchten Version habe ich es, bis auf Mapping control, drin. Viele Grüße, Michael
Und nochmal Hallo, Gerald schrieb: > Eigentlich nicht. Der PIC schickt mit MSB first und das Display will > auch MSB first. ich stolpere da über diese beiden Datenblattzeichnungen, PIC und Display, siehe Bild.....(Achtung, 2 Datenblätter auf Papier übereinander, oben PIC, unten Display) Aber, da ich den PIC beeinflussen kann, richte ich mich natürlich nach dem Display ;-) Siehe Oszilloskopbild weiter oben. Viele Grüße, Michael
Michael schrieb: D7 > 9 : 3,3 V D6 > 10: GND ... BM0 > 22: 3,3V BM1 > 23: GND Du verwendest den 9-Bit Modus (S9). Dein PIC kann aber die SPI nur mit einer Granularität von 8-Bit bedienen (zähl mal die Flanken auf dem Oszi). Entweder Du machst die SPI in Software oder spendiert noch die CD-Leitung und verwendest den 8-Bit Modus.
Michael schrieb: > oben PIC, unten Display Ja, aber das ist der USART vom PIC, nicht SPI. Ich habe oben das Datenblatt vom PIC verlinkt, schau mal da auf Seite 132, FIGURE 14-3: SPI MODE WAVEFORM (MASTER MODE).
Hi >Hier noch eine Antwort drauf, laut Datenblatt sind die nicht dringend >notwendig, in meiner zuletzt versuchten Version habe ich es, bis auf >Mapping control, drin. Im Datenblatt des UC1608 von UltraChip (Revision 1.1 vom 4.11.2004) steht, das zumindest 'Set Gain & PM' erforderlich ist. MfG Spess
Gerald schrieb: > Ja, aber das ist der USART vom PIC, nicht SPI. > > Ich habe oben das Datenblatt vom PIC verlinkt, schau mal da auf Seite > 132, FIGURE 14-3: SPI MODE WAVEFORM (MASTER MODE). Hallo Gerald, ja, das Datenblatt kenne ich, habe ich ja auch hier. Ich verwende aber den USART, als snychronen Master, mit der Eigenschaft, daß der wohl die Bits andersherum sendet. Was michnicht stört, ich drehe die Bits eben bei #define um, nicht schön aber geht. Siehst Du irgendwelche Vorteile des SPI? Vielleicht stehe ich auch auf dem Schlauch, aber, wo würden ich denn den DatenEINgang des PICs am Display anlegen? Das Display hat ja keine separate DatenAUSgangsleitung. Bei USART ists klar, eine Taktleitung, Mater bestimmt den Takt, also mein PIC, und die Datenleitung ist bidirektional (bei Bedarf, bisher sendet das Display ja nichts, es kann ja nur nach Aufforderung senden). Also, Umkehrschluß, das "Ja" am Anfang Deines Beitrags nehme ich auch als "Ja" auf meine Frage, sind die Bits umgedreht (aber, das zeigt mir das Oszi ja ;.) ). Viele Grüße, Michael
Gerald schrieb: > D7 > 9 : 3,3 V > D6 > 10: GND > ... > BM0 > 22: 3,3V > BM1 > 23: GND > > Du verwendest den 9-Bit Modus (S9). Dein PIC kann aber die SPI nur mit > einer Granularität von 8-Bit bedienen (zähl mal die Flanken auf dem > Oszi). > Entweder Du machst die SPI in Software oder spendiert noch die > CD-Leitung und verwendest den 8-Bit Modus. Nochmal Hallo Gerald, falls Du derselbe bist wie grade ;-) Ich vermute ja stark, daß da irgendwie der Hund im Pfeffer begraben ist (oder so), denn, das ist was, was ich in den Datenblättern nicht ganz verstehe. Ich teste jetzt grade Figure10:3/4 Wires SPI (S8uc), da liegen D7 und D6 auf 3,3V und BM0 und 1 auf Masse....... Viele Grüße, Michael
Gerald schrieb: > Du verwendest den 9-Bit Modus (S9). Dein PIC kann aber die SPI nur mit > einer Granularität von 8-Bit bedienen (zähl mal die Flanken auf dem > Oszi). > Entweder Du machst die SPI in Software oder spendiert noch die > CD-Leitung und verwendest den 8-Bit Modus. So, nochmal kurz ich, dreimal lesen hilft vielleicht, ne richtige Frage dazu zu formulieren ;-) Eigentlich dachte ich, ich mache 8 Bit, und stelle später die CD-Leitung, denn, für die ersten Versuche würde ich sie ja eh nur auf Masse halten, also habe ich sie fest verdrahtet. Muss die CD-Leitung für die oben gezeigten Initialisierungen überhaupt angefasst werden? Die läge ja bei allen Befehlen sowieso auf Null? Viele Grüße, Michael
Michael schrieb: > So, nochmal kurz ich, dreimal lesen hilft vielleicht, ne richtige Frage > dazu zu formulieren ;-) also, nicht daß es falsch rüberkommt, ich meine natürlich MICH, ich muss erst dreimal lesen, bevor ICH ne Frage stellen kann ;-)
spess53 schrieb: > Hi > >>Hier noch eine Antwort drauf, laut Datenblatt sind die nicht dringend >>notwendig, in meiner zuletzt versuchten Version habe ich es, bis auf >>Mapping control, drin. > > Im Datenblatt des UC1608 von UltraChip (Revision 1.1 vom 4.11.2004) > steht, das zumindest 'Set Gain & PM' erforderlich ist. > > MfG Spess Hallo, ja, deshalb habe ich es noch eingefügt, ich habe diese Tabelle im Datenblatt gefunden : SAMPLE POWER COMMAND SEQUENCES auf Seite 35, da steht bei RESET Required Set MR and TC Nicht wichtig, außer andere Werte werden gewünscht LCD Mapping Nicht wichtig, außer andere Werte werden gewünscht Bias Ratio Nicht wichtig, außer andere Werte werden gewünscht Set Gain and PM Required Write Display RAM Nicht wichtig, außer andere Werte werden gewünscht Set Display enable Required Und, ich denke, das habe ich, wenn der Code oben stimmt, die Signale laut Oszi kommen zumindest. Viele Grüße, Michael
Michael schrieb: > Was michnicht stört, ich drehe > die Bits eben bei #define um, nicht schön aber geht. > > Siehst Du irgendwelche Vorteile des SPI? Ja, das Du die Daten nicht rumdrehen musst. Betrifft ja nicht nur die Befehle, sondern letztendlich auch den Displayinhalt. Vorteil für den USART wäre wiederum, das er offenbar einen 9-Bit Modus hat. > Vielleicht stehe ich auch auf > dem Schlauch, aber, wo würden ich denn den DatenEINgang des PICs am > Display anlegen? Das Display hat ja keine separate DatenAUSgangsleitung. Den kannst Du offen lassen, oder besser mit einem Widerstand auf VCC oder GND legen. Michael schrieb: > Muss die CD-Leitung für die oben gezeigten Initialisierungen überhaupt > angefasst werden? Die läge ja bei allen Befehlen sowieso auf Null? Für die Initialisierung geht es vielleicht auch mit festem Pegel. Aber Du willst doch sicher auch mal was darstellen wollen... > Ich teste jetzt grade Figure10:3/4 Wires SPI (S8uc), da liegen D7 und D6 > auf 3,3V und BM0 und 1 auf Masse....... Ok. Im S8uc kannst Du auf die CS-Leitung fest auf Vcc legen. Jeder Pegelwechsel auf CD setzt den Busstatus zurück. So langsam müsstest Du nach der Initialisierung was zu sehen bekommen...
Michael schrieb: > ich versuche derzeit, mich in 2 Dinge gleichzeitig einzuarbeiten... Also, wenn ich das richtig sehe: Du willst einen PIC18xxx in C programmieren lernen und zugleich ein 240x128 Grafik-LCD dort anschließen und benutzen. Ist das so? Nun, mit den PIC16Fxxx hantiere ich ja oft genug herum, nicht jedoch mit den PIC18 oder 24. Aber ich gleube mich zu entsinnen, daß bei den PIC18 der RAM auch nicht grad üppig vorhanden ist. Wie also willst du das unter einen Hut bekommen? Ich mach mal ne Rechnung auf: 240x128/8--> ca. 3.8 K RAM - hast du soviel überhaupt auf dem PIC18? Immerhin ist das Display (Farnell 2219021) mit 26 € netto nicht nur ein teures Spieleug, sondern auch ein Grafik-Display und dafür braucht man einen passend großen Display-RAM, wo man seine grafischen Elemente drin aufbaut und dann das Ganze en bloc zum Display schickt. Jaja, jetzt gibt es Spezis, die behaupten, daß man ja den displayinternen RAM benutzen kann, aber den müßte man zum Modifizieren dann stückweise hereinholen und wieder hinausschaufeln - und das macht ne Menge Arbeit, es sei denn, man will das Grafik-Display als Quasi-Alpha-Display benutzen, so mit Fonts fester Breite und festen Positionen. Also mein Rat wäre folgendes: - nimm für das Basteln mit kleineren PIC's lieber ein Alpha-LCD oder sowas wie das "SANBUM" von Pollin (solange es das dort noch gibt), denn letzteres ist pixelmäßig viel kleiner und folglich weniger aufwendig, obendrein ist es billiger. - nimm für das Basteln mit dem genannten LCD von Farnell lieber einen größeren µC, der genug RAM hat. Trenne dort die zwei Dinge "Anzeigebild aufbauen" also Text und Grafik in einen Bild-RAM bringen und "Anzeigebild zum Display schaufeln". Für ersteres gibt es auch hier in diesem Forum genug an Beispielen (einfach nach gdi.c oder so mal suchen), denn dieser Teil ist hardwareunabhängig - wenn man mal von der X- und Y-Auflösung absieht. Der zweite Teil ist hingegen hardwarespeziell. Ich würde bei einem Display mit Parallelschnittstelle IMMER die 8 Bit Parallelschnittstelle bevorzugen, das geht regelmäßig am flottesten. Bei manchen Controllern sind serielle Modi hingegen oft nur einseitig, also nur Daten ZUM Display und nicht anders herum. Deswegen der Display-RAM im µC. Ansonsten ist das Anschlußbild des besagten Displays doch sehr übersichtlich und auch gut beschrieben. Hast du etwa rechts mit links verwechselt? (war mir mal zwischendurch beim SANBUM passiert...) Und nochwas: Mach dir ne passende Leiterplatte und fummle nicht so sehr mit Steckbrett herum wenn du nicht gerade Steckbrett-Weltmeister bist. W.S.
Hi >Jaja, jetzt gibt >es Spezis, die behaupten, daß man ja den displayinternen RAM benutzen kann, Trotz deiner Unkenrufe praktiziere ich das seit 18 Jahren bei Grafikdispays mit Touchscreen erfolgreich. > aber den müßte man zum Modifizieren dann stückweise hereinholen >und wieder hinausschaufeln ... Wenn man weiß wo etwas dargestellt werden soll muss man nichts 'herausholen'. >und das macht ne Menge Arbeit, es sei denn, >man will das Grafik-Display als Quasi-Alpha-Display benutzen, so mit >Fonts fester Breite und festen Positionen. Wenn das deinene Meinung ist, dann bleib ruhig dabei. MfG Spess
W.S. schrieb: > Jaja, jetzt gibt > es Spezis, die behaupten, daß man ja den displayinternen RAM benutzen > kann, aber den müßte man zum Modifizieren dann stückweise hereinholen > und wieder hinausschaufeln Nein, kann er nicht. Er hat nur eine Leitung, um in das Display zu schreiben. Wenn man weiß, was man vorher (auch grafischer Art) an welche Stelle gepinselt hat, kann man dies auch durch überschreiben ändern. Das ist kein Problem und nicht so schwer, wie von Dir beschrieben. Und um das Display zunächsteinmal zum laufen zu bekommen und ein Rechteck darauf zu malen, reicht es allemal. Und: Man kann den Bildinhalt auch partiell berechnen und dann Block für Block übertragen. Gruß Jobst
spess53 schrieb: > Wenn man weiß wo etwas dargestellt werden soll muss man nichts > 'herausholen'. Und genau DAFÜR braucht man den µC-internen Display-RAM. Sonst ist es nämlich nix mit "wenn man weiß.." Deine Alternative bedeutet tatsächlich, daß man eben keine grafischen Elemente in freier Position haben kann, weil sie dann hie und da ein Byte im displayinternen RAM mit einem anderen Element teilen müßten. Also beschränkt man sich auf Elemente fester Größe an festen Positionen, so daß man nix anderes überschreibt. Ja, kann man machen, auch 18 Jahre lang. Sieht auch entsprechend aus, so ähnlich wie dunnemals TurboVision. Ich meckere da nicht, weil es ja für den von dir vorgesehenen Einsatzfall nach deinen Worten ausreicht. W.S.
Hi
>Sieht auch entsprechend aus, so ähnlich wie dunnemals TurboVision.
Also ich hatte TurboVision komplett auf Grafikmode umgeschrieben. Das
ist also eher ein Kompliment. Vielleicht liegst liegst du bei anderen
Bewertungen ähnlich schief?
MfG Spess
spess53 schrieb: > Also ich hatte TurboVision komplett auf Grafikmode umgeschrieben. Das > ist also eher ein Kompliment. Ach wo. Ich hatte mir TV auch auf Grafik umgeschrieben. Ich denke mal, das hat wohl fast jeder mal gemacht - DAMALS. Ist also gar kein Kompliment, sondern nur der Hinweis auf die damalige Rasterhaltigkeit solcher Oberflächen im krassen Gegensatz zu echtem GUI. W.S.
W.S. schrieb: > Ansonsten ist das Anschlußbild des besagten Displays doch sehr > übersichtlich und auch gut beschrieben. Hast du etwa rechts mit links > verwechselt? (war mir mal zwischendurch beim SANBUM passiert...) Hallo und Guten Morgen, danke für die Antworten, das ist für mich "nur" Arbeit, also, im Büro, deshalb melde ich mich jetzt erst wieder. Der obige Satz regt mich grade am Meisten zum Denken an :-O Also, vorab, rechts und links klappt noch ganz gut ;-) Ganz links, also da <-------- liegt mein Pin1. Möchte aber nochmal kurz darauf hinweisen, ich habe die Variante mit Pins, da gibt es nur 23 davon. So, noch kurz zu den anderen Antworten, das sollte nur ein erster Versuch werden, bevor ich eine Leiterplatte mache. Es steht auch noch kein bestimmtes Projekt dahinter, eine Idee, grafisch nicht allzu aufwendig war mal angedacht anzugehen, deshalb wäre ich jetzt naiverweise davon ausgegangen, mir reicht zunächst der PIC und der Speicher, weil ich eigentlich nur einzelne kleine Piktogramme, meistens rechteckig, also nur Linien, anzeigen wollte. Und, nein, leider sehe ich bis jetzt immer noch nichts, ich befürchte mal, daß die LCD-Spannung nicht funktioniert, da ich diese garnicht messen kann. Aber, ob es nun an meiner Initialisierung oder am Display liegt, ich werde mir nochmal ein Display bestellen (lassen), mal sehen, ob das was bringt..... Kurz OT: Bisher habe ich mit wesentlich kleinerem PIC, 16er, allerdings in Assembler, mit Displays von EA gute Erfahrungen und auch mehrere Steuerungen gemacht. Ok, die brauchen auch wenig Speicher, weil ich da eines verwendet habe, welches selbst programmiert werden kann, da kann man Makros definieren und drin speichern, die der PIC nur aufrufen muss. Für schnelle Sachen eigentlich sehr zu empfehlen. Vielen Dank und viele Grüße, Michael
Michael schrieb: > Und, nein, leider sehe ich bis jetzt immer noch nichts, ich befürchte > mal, daß die LCD-Spannung nicht funktioniert, da ich diese garnicht > messen kann. Du meinst wohl eher, daß du die LCD-Spannung sehr wohl messen kannst, selbige gedoch nicht aus dem Knick kommt und nur um und bei Null herumdümpelt. Ich geb dir den dringenden Rat, dir einen etwas größeren µC zu greifen, wo du genug Pins zur Verfügung hast, um erstmal den stinknormalen 8 Bit Parallelzugriff tun zu können. Bei diesem Modus ist m.E. die Gefahr am geringsten, schon bei den Ansteuer-Details entscheidende Schnitzer zu machen. Wenn dein LCD dann erstmal zuckt, kannst du den BWSP ja erstmal mit 55h oder einem anderen charakteristischen Muster füllen. Ich hatte das beim besagten SANBUM auch so ähnlich gemacht. Aber mit ner Adapter-LP und gelöteten Strippen - ohne Steckbrett. Bei letzterem erstickt man leicht in Kontaktproblemen. W.S.
Bitte 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.