1 Konzept

Gespeichert von DL6GL am Mo., 25.03.2019 - 11:55

Als gewohnheitsmäßiger BASCOM-Nutzer fremdelte ich dann doch mit der Arduino IDE. Rasche Ergebnisse mussten her. "Mister Display" HKipnik hat in [2] eine Library "Uni-TFT-ILI9341-Uno.zip" für das ILI9341 in einer BASCOM-Umgebung auf Arduino UNO veröffentlicht. Das Testprogramm "ILI9341-8bit-UNO.bas" lief auf Anhieb.

Mit den drei noch verfügbaren Ports ist allerdings kein Staat zu machen, es sei denn, notwendige Steuerungsfunktionen von außen erfolgen seriell über TX/RX, Anschlüsse 0 und 1, bzw. via USB. I2C wäre mir lieber. Das TFT belegt aber den Anschluss A4 (PC4/SDA) für den Software-Reset des Displays. Um den Port PC4/SDA frei zu bekommen, wurde der Reset-Pin "RES" des Arduino mit dem für den TFT-Reset vorgesehenen LCD-Pin LCD-RST verbunden (Abb. 1.1). Das TFT erhält damit den Reset vom Arduino. Dazu wurden die Pins auf der TFT-Steckerleiste zum Arduino A4 (PC4) und A5 (PC5) ausgelötet. Nun sind die Ports SDA und SCL für die I2C-Kommunikation verwendbar.

Da auf die Darstellung von Bitmap-Bildchen über den SD-Kartenslot gut verzichtet werden kann, würden noch PB2 bis PB5 am Arduino zur Verfügung stehen.

TFT Shield modifications

Abb. 1.1: Modifikation des TFT-Boards für eine I2C-Kommunikation.

Die damit verbundene Absicht ist folgende:

  1. Der Arduino ist nur für die Displaysteuerung zuständig. Dafür ist der Flash-Speicher ausreichend.
  2. Ein Master-Controller legt fest, welche Daten in welcher Form auf dem Display dargestellt werden sollen.
  3. Kopplung über I2C.

Master slave configuration

Abb. 1.2: Master-Slave-Konfiguration.

Als Master wurde für Testzwecke ein ATmega16 mit einem 16x2-Display eingesetzt.

Auf beiden Seiten, Master und erst Recht Slave, wird Hardware-I2C eingesetzt. Die Ports müssen also entsprechend zugeordnet werden:

Funktion Controller SCL SDA
Master ATmega16 PC0 PC1
Slave ATmega328P PC5 PC4

Es ist noch eine dritte Verbindung zwischen Master (PC2) und Slave (PB2) vorgesehen: zur Synchronisation. Das LCD im Slave benötigt eine gewisse Zeit zum Malen, je mehr Pixel, je mehr Zeit. Kommt während dieser Ausführungszeit ein neuer I2C-Befehl, gerät alles durcheinander. Der Master muss also mitbekommen, ob der Slave noch mit Malen beschäftigt ist oder nicht. Das könnte mit entsprechendem Aufwand auch mit einem I2C-Protokoll vom Slave zurück zum Master erledigt werden, mit der der Slave eine entsprechende Quittierung an den Master zurückschickt "Ich habe fertig mit Malen, lass mal wieder was kommen".

War mir zu kompliziert. "KISS" (keep it simple and stupid) ist für den Anfang immer noch die bessere Lösung. Stattdessen legt der Slave vor Beginn eines jeden Befehls an das LCD den Port PB2 auf high, mit Abschluss dann wieder auf low. Der Master prüft vor dem Absenden eines neuen Befehls, ob das Signal an seinem Port PC2 low ist, und wartet ggf. darauf.