Graphlcd Plugin und AVR

Zitat

Original von gda

Wie funktioniert denn LCD_SetBrightness()? Ich dachte die Helligkeit wird über die Hintergrundbeleuchtung
und der Kontrast über die negative Kontrastspannung geregelt.
Ist dein Display etwas besonderes, oder kann das jedes Display mit einem T6963c?

Hallo,

ich verwende kein T6963C sondern das Noritake-Itron gu256x128-3900. Das hat schon eine Helligkeitsreglung eingebaut.

Grüße
Andreas

Zitat

Original von powarman
ich verwende kein T6963C sondern das Noritake-Itron gu256x128-3900. Das hat schon eine Helligkeitsreglung eingebaut.

Das erklärt einiges, obwohl die Ansteuerung ansonsten der für den T6963c
schon sehr ähnelt.

Gerald

Danke für die Quellen,
ich habe mir WinAVR mal installiert und Deine Quellen kompiliert. Dann erhalte ich eine hex Datei mit fast 16k. Reicht das, wenn ich dieses Hefile in den AVR brenne? Sprich, mir würde ein ATMega168-20 reichen? Zum brennen will ich demnächst mal Bascom-AVR probieren, da ist ein ISP Proggi drin. Oder kann das aus irgendwelchen Gründen nicht klappen?

EDIT habe mittlerweile versucht den Code für den ATmega168-20 kompilieren zu lassen. Ging gar nicht! Dann mit dem atmega162 Dazu habe ich in der Makefile den MPU Typ geändert auf atmega162. Aber jetzt bekomme ich eine Fehlermeldung, dass in graphics.cpp in der Funktion InitFont pgm_read_byte_far_(...) nicht deklariert wäre, dabei habe ich pgmspace.h drin gelassen. Muss wohl noch reichlich Doku lesen, bis ich das alles schnalle...

Ok, wenn ich das jetzt richtig verstanden habe, geht es bei dem Fehler um eine Funktion, die auf den kleineren Bausteinen gar nicht verwendet werden kann (zu wenig Speicher), wenn ich das "_far" aus der Funktion nehme, kompiliert er sauber durch (für nen AT90S8515). Dazu habe ich noch die Registernamen und die Ports anpassen müssen.

Jetzt muß ich das noch auf mein Display anpassen ... wow, ist das spannend

Habs noch nicht hinbekommen avrctl auf mein Display umzuschreiben. Dafür habe ich geschafft den Treiber aus den AVRlib fürs ks0108 soweit zu bewegen, mir ein Bild aus dem EEPROM aufs Display zu schreiben.

Wenn ich ein Terminal öffne, bekomme ich auch die Buchstaben zurück.

Baudrate derzeit bei 115200; läuft auf nem AT90S8515. Da der AVR aber viel weniger RAM hat, wollte ich auch den cmd_buffer auf 64 Bytes reduzieren. Das bekomme ich aber nicht hin. Könnt Ihr mir da mal auf die Sprünge helfen, was man alles anpassen muß?
Auf der AVR Seite hab ich:

case CMD_DISP_SET_COL_DATA:
      {
        static uint16_t col;
        static uint16_t offset;
        static uint16_t len;


        if (cmd_len > 68) //vorher 2500
        {
          cmd_pos = 0;
          break;
        }

und vorher den LcdBuffer und CmdBuffer auf niedrigere Adressen (weil nur interner RAM) gelegt. Ich würde gerne ohne externen RAM auskommen.

hi,
vllt. wirst du hier fündig: http://hg.muempf.de/picctl/fil…base/glcddrivers/picctl.c

in meinem treiber ist schon alles auf 64bytes beschränkt.

Danke Dir, das sieht fast so aus, wie ich das auch schon habe. Die Sahnestückchen kopiere ich mir natürlich

348 void cDriverPICCtl::CmdDispSetColData(uint8_t yoffset, uint8_t xoffset, uint8_t length, uint8_t * data)


      349 {


      350     uint8_t cmd[64];

Hier baust Du doch ein Aray von 0-63 Integerwerten, welches vorher 2500 Bytes groß war, richtig? Da der Header schon 6 Bytes hat, bleiben für die Daten nur noch 58 Bytes. Was allerdings auch nix macht, weil die Aufrufe der Funktion eh nur 30 Bytes an Daten ( width/8 ) groß werden kann. Stimmts? Bei meinem 128x64 wären das also 128/8=16 Bytes/Zeile. Das sollte dann locker gehen; wenn auch etwas langsam.

Vielen Dank soweit, ich hoffe ich bekomme das jetzt endlich mal hin.

Zitat

Original von naicheben
Hier baust Du doch ein Aray von 0-63 Integerwerten, welches vorher 2500 Bytes groß war, richtig? Da der Header schon 6 Bytes hat, bleiben für die Daten nur noch 58 Bytes. Was allerdings auch nix macht, weil die Aufrufe der Funktion eh nur 30 Bytes an Daten ( width/8 ) groß werden kann. Stimmts? Bei meinem 128x64 wären das also 128/8=16 Bytes/Zeile. Das sollte dann locker gehen; wenn auch etwas langsam.

also mit deinem ersten satz kann ich nix anfangen? woher nimmst du die zahl von 2500bytes?
der rest ist absolut korrekt.

in der cDriverAvrCtl::CmdDispSetRowData(....)

uint8_t cmd[2560];

so wird das im Original von Powarman initialisiert. Das war ja im Prinzip die Stelle, an der wir mit unseren Speicherwinzlingen nicht mitspielen können.

Eigentlich müßte das aber voll egal sein, solange length+8 nicht größer wird, als der SRAM-Empfangs-Puffer im µC. Warum mußtest Du den Wert denn trotzdem runtersetzen?

ah, ich sehe was du meinst. ich habs einfach aus prinzip kleiner gemacht. die firmware verarbeitet (momentan) keine längeren commandos.
eigentlich sollte da noch mit einem zusätzlichen if gecheckt werden, ob auch wirklich weniger als 65bytes gesendet wird.
btw: meiner ist nicht direkt ein speicherwinzling. 1kbyte empfangspuffer hat das teil in hardware. aber ich wollte den krams einfach und überschaubar halten. wenn alles läuft so wie es soll, bohre ich die firmware an dieser stelle wohl noch auf.

Ich bin erschöpft...
Jetzt habe ich ne ganze Woche jeden Tag bis spät in die Nacht rumexperimentiert. Ich kann dem AVR über USB sagen, schalte auf Master/Slave oder auch Lösche das Display. Aber LCDd initialisert (baut die Verbindung über /dev/ttyUSB0 auf) bekommt aber kein Acknowledge. Wenn ich das mit dem Terminal mache, sehe ich aber das Acknowledge! Muss ich da auf eine bestimmte graphlcd-base Version achten, oder geht das nur mit vdr-graphlcd-plugin?

Hatte Ihr da auch Probleme? Ich benutze graphlcd-base-0.1.5
lcdproc Version weiß ich grad nicht auswendig ... Ist die wichtig?

ööhm.. was hat LCDd mit graphlcd zu tun? wenn du da ein bild raufhaben willst versuch es mal mit 'showpic'.

Ich wollte MMSv2-1.1.0 auf dem Display steuern. Außerdem dann eben den VDR.

In MMSv2 läßt sich dann Musik auswählen, ohne immer gleich den Fernseher anzumachen. Leider bietet es nur eine Schnitstelle zu LCDd und nicht zu graphlcd.

Ich habe mir mal ein paar mehr Punkte gesetzt, zum "debuggen", die tauchen dann in messages auf.

Feb 21 19:19:09 SMT-7020S LCDd: avrctl: AvrCtl initialized.
Feb 21 19:19:09 SMT-7020S LCDd: avrctl: AvrCtl wait for Acknowledg after CmdCtrlSetSlave.

Das kommt direkt vor dem WaitForAck() und es geht dann nicht weiter. Das Display ist dann aber im Slavemode

Bei Showpic ist es das gleiche.

Kann das was mit dem Timeout zu tun haben? Wenn ich das Display über die Kommandozeile anspreche geht es.

naicheben@SMT-7020S:/usr/src/zslack-dev/LCD/graphlcd-base-0.1.5/tools/showpic$  echo -e '\xaa\x10\x00\x00' > /dev/ttyUSB0
naicheben@SMT-7020S:/usr/src/zslack-dev/LCD/graphlcd-base-0.1.5/tools/showpic$  echo -e '\xaa\x15\x00\x00' > /dev/ttyUSB0
naicheben@SMT-7020S:/usr/src/zslack-dev/LCD/graphlcd-base-0.1.5/tools/showpic$  echo -e '\xaa\x20\x00\x00' > /dev/ttyUSB0

Löscht das Display und versetzt es wieder in den Mastermode. Es kommt irgendwie scheinbar kein Ack zurück. Kann das am USB-Seriellwandler liegen?

stty -F /dev/ttyUSB0
speed 921600 baud; line = 0;
min = 1; time = 0;
-brkint -imaxbel
-opost
-isig -icanon -echo -echoe

Ich bin ja auch ein wenig doof. Als ich mit dem Terminal von Bascom-AVR getestet habe, konnte ich nicht schneller als 115200 einstellen. Damit läuft alles wunderbar und ich dachte, wenn ich jetzt beide Seiten auf 921600 stelle, wird das auch funktionieren. Was ich nicht bedacht habe: ich habe einen MAX232N zwischen meinem WebTiger-Board und dem USB-RS232-Wandler von Reichelt... Der MAX232 kann aber nur 120K übertragen! Es ist immer gut ALLE Datenblätter zu lesen.