[infos] LCD graphique 160 x 128, en détails (T6963)

Alors voilà, peut-être que ça peut en intéresser certains : comment qu'il marche?

1 - L'écran en lui-même, caractéristiques :


Marque : Distar, modèle DS-G160128STBWW
Monochrome : blanc sur fond rétroéclairé bleu,
Alimentation simple en 5V,
communication : parallèle 8 bits,
dimensions totales : 12.9cm x 10.2cm
Taille d'affichage : 10.1cm x 8.2cm
taille de pixel : 0.54mm x 0.54mm

un peu plus de détails :
Chip : Toshiba T6963
RAM : 64Ko
fonctions : set/reset pixel, texte (table de caractères en ROM interne + possibilité de table utilisateur), read/write RAM et registres, et divers petites fonctions classiques d'écran graphique : cursor ON/OFF...

2 - Option : le serial backpack de sparkfun pour comm en série (jusqu'à 115200 b/s) :

un petit ATmega168 sur un bout d'époxy qui assure la traduction série vers parallèle (le mode parallèle demande en tout 13 lignes numériques...). Les fonctions de l'ATmega168 sont set_pixel, ligne, rectangle, cercle, put_text, clear... d'autres fonctions sont écrites mais inaccessibles (le programme livré avec n'est pas fini...). De plus, les lignes sont discontinues si elles sont à moins de 45° de l'horizontale, ce qui n'est pas très pro sur un produit à vendre... Heureusement, il y a possibilité de souder dessus un connecteur ICSP pour finir le boulot du programmateur de chez Sparkfun. C'est d'ailleurs ce qui m'a poussé à décortiquer le bidule, car le 168 pourrait assurer des fonctions supplémentaires pour alléger les commandes que l'on doit envoyer en série : il faut actuellement 4 octets à envoyer pour dessiner un simple pixel...

Les détails du câblage pour la reprogrammation ici : http://arduino.cc/forum/index.php/topic,76145.0.html

3 - avantages de reprogrammer le 168 :

Etant déjà mal programmé à la base, il est intéressant d'avoir des graphiques gérés par le 168 (une page de formulaire par exemple), et on lui envoie seulement les données à afficher dans ce formulaire, ce qui allège grandement le µP qui est derrière et qui n'aura plus besoin de créer l'interface graphique...

Dans mon cas, je voudrais faire un ordinateur de bord pour voiture. j'en suis à devoir afficher une 20aine de données dans différentes pages. Comme je l'explique plus loin, il est possible d'avoir plusieurs pages, donc le 168 crée et gère les pages, et mon arduino n'a plus qu'à envoyer les 20 données, ainsi que le numéro de la page qui doit être affichée (21 données par série, c'est transparent). mon arduino peut donc mieux s'occuper des nombreuses mesures de fréquence, interruptions, boutons etc etc... Sans avoir à redessiner chaque page quand on change de visualisation.

4 - Décorticage, étude des fonctions :

Le chip toshiba qui dirige le LCD ne propose pas beaucoup de fonctions. c'est un µP générique pour LCD, c'est tout. Sur le PCB (circuit imprimé), on trouve donc ce chip T6963, une RAM de 64Ko, une ROM (taille?) et 4 drivers LCD (genre de simples latchs).
La tension VEE est générée par le T6963, c'est toujours ça de gagné.
Après près d'une semaine de retournement des datasheets, j'ai découvert le fonctionnement :

On envoie des données directement dans la RAM (on a accès aux 64Ko, donc on les envoie où on veut), on dit au T6963 où se trouves les données d'affichage, et c'est tout. le T6963 fera un balayage de la ram à chaque modification pour les envoyer aux latchs du LCD.

Pixels, texte...

Les deux fonctions graphiques et texte fonctionnent parallèlement, on peut choisir en une seule commande graphique ON/OFF et texte ON/OFF, ce qui permet d'avoir du graphique et du texte simultanément, du graphique seul ou du texte seul, ou rien du tout.

Attention, si on peut mettre un pixel où on veut, le texte, lui, se pose sur une grille de 20 lignes x 16 colonnes, il faut donc aligner le graphique par rapport au texte et non l'inverse.

organisation de la RAM :
Il faut sortir le papier, crayon et calculatrice pour découvrir que :

- mode graphique mode texte
fonctionnement 1 bit = 1 pixel
(1 octet = 8 pixels en ligne)
1 octet = 1 caractère
(espace par défaut)
taille mémoire
pour un écran complet
2560 octets 320 octets

on voit que pour avoir du graphique et du texte simultanément, il faut "allouer" 2880 octets dans la ram. Mais que faire des 62656 octets restants? à part y coller une table de 128 caractères persos (soit 1024 octets max), on peut découper cette ram en 22 pages écran, puisqu'on peut écrire où on veut, et envoyer le T6963 lire ailleurs. Exemple, le T6963 affiche les données de 0x000 à 0x0B3F (première page), pendant qu'on prépare une seconde page de 0x0B40 à 0x167F, et quand on le voudra, on dira au T6963 d'afficher les données à partir de 0x0B40, ce qui nous affranchit des dessins pendant l'affichage...

Pour dessiner sur l'écran, la méthode est quelque peu compliquée à programmer, car il faut calculer l'emplacement mémoire qui correspond au pixel ou au caractère que l'on veut lire ou écrire.

mode graphique :

il faut imaginer la RAM comme étant sur l'écran : les 8 premiers pixels de la première ligne font le premier octet de la RAM, les 8 seconds pixels de la première ligne font le second octet de la RAM et ainsi de suite, puis les 8 premiers pixels de la seconde ligne font le nième octet de la RAM, avec n = 20 x numéro de ligne. On finira par s'y retrouver, au besoin, on peut toujours fouiller dans les sources chez Sparkfun, côté pixel, c'est correct. Ensuite, deux méthodes pour écrire un pixel : soit en n'écrire qu'un seul (le plus courant), soit par 8 en envoyant directement un octet dans la RAM. C'est d'ailleurs cette seconde méthode qu'il faut appliquer pour effacer l'écran : envoyer 2560 octets à 0x00, il n'y a pas de fonction pour ça, ou sinon, changer de page, peut-être plus rapide...

mode texte :

dans le même esprit, un octet = un caractère, en ligne. les 20 caractères de la première ligne sont les 20 premiers octets de la RAM texte etc etc.

Accès à la RAM (lecture ou écriture) :

Là, c'est assez long : il faut envoyer dans l'ordre :
- lowByte(adresse);
- highByte(adresse);
- code "adresse RAM".
Ensuite, il faut lire (1 envoi : commande lecture, une réception : octet data) ou écrire (deux envois : data puis commande). Le tout est relativement bien expliqué dans un PDF (en anglais) que j'avais imprimé mais que je ne retrouve plus... si j'ai le courage, je le traduirai, mais n'y comptez pas trop...

la suite prochainement...

En lisant ton premier message au sujet de l'utilisation de cet écran, une idée me vient à l'esprit.
Serait'il possible de remplacer le 168 par un 328, et d'ajouter une carte Sd sur "le bout d'époxy" afin de précharger des "bases" graphiques ?

ben si tu sais dessouder / souder sur les SMD, pas de souci! Tu peux même mettre n'importequel µP (en refaisant un bout d'époxy, bien sûr), tout dépend de ce que tu veux réellement faire... Il faut savoir qu'il ne te reste que les 3 pins libres sur l'ATmega, mais l'avantage est qu'elles sont sur le connecteur ICSP (PB3:5 = MOSI, MISO et SCK, avec du GND, VCC et RESET, tout ce qu'il faut pour relier un composant ou circuit supplémentaire). Mais 3 pins seront-elles suffisantes pour gérer une SD? Si oui, alors tu m'intéresses, car je me posais également la question...

Vu que la seule différence entre les deux, c'est qu'un 328 à deux fois plus de mémoire (flash, eeprom et ram), le 168 ne saurait-il pas gérer une SD (toujours avec 3 pins, moyennant peut-être l'adaptation d'un bus série synchrone 3 fils (Sck, DI, DO))... à voir, par exemple, cela semblerait réalisable avec ça : SparkFun SD/MMC Card Breakout - BOB-12941 - SparkFun Electronics...

C'est vrai qu'on pourrait alors charger sur la SD des "skins" super sympas (même s'ils sont monochromes XD), avec des configs et tout et tout... voire même des petites animations (en préchargeant une dizaine de pages dans la RAM du LCD, puis en faisant boucler le T6963 dessus...)

tout plein d'idées!

EDIT : Boulétor a encore frappé dès le matin (dormi que 4h cette nuit, ce doit être pour ça) : Ben oui, on a le connecteur ICSP qui fait aussi SPI, donc idéal pour y connecter une SD directement (enfin via un adaptateur 5V -> 3.3V). Il ne reste plus qu'à prévoir l'utilisation de la pin "/SS", qui est sur le PB2, soit la sortie PWM utilisée pour la gestion du rétro-éclairage. Dans ce cas, on peut virer la petite résistance (qui est entre PB2 et le transistor des leds du back-light) pour les déconnecter, on utilisera un système annexe (un simple potar) pour gérer fixement le back-light du LCD et récupérer ainsi la pin "/SS" pour le SPI. Mais si le 168 est en master, on peut s'affranchir du "/SS" (à vérifier sur le datasheet du 168) et garder le PWM... ça devient plus que tentant d'un coup!!!

Je suis justement en train de "bricoler" avec des SD.

Le 168 n'est pas assez "costaud" pour gérer ça...

Pour la SD il faut mosi-miso-sck + Chipselect (je ne suis pas sur que CS soit obligatoire).

Jean-François:
Pour la SD il faut mosi-miso-sck + Chipselect (je ne suis pas sur que CS soit obligatoire).

Si tu as un seul esclave sur le bus SPI, tu peux effectivement coller CS à la masse :wink:

Bonjour
Pour ma part s'il reste une sortie disponible sur l'Arduino je préfère gérer CS.
En mettant CS à la masse on prend un petit risque de perturbation de la carte SD à la mise sous tension de l'Arduino car les sorties MOSI, et SCK peuvent 'hésiter' un peu avant de prendre leurs valeurs initiales...
D'autre part il est sans doute préférable de laisser la carte SD s'initialiser avant de valider son interface SPI par CS.

Je suis du côté d'al1fch, dans la mesure où le CS du port SPI de l'ATmega est facilement accessible (on n'a pas besoin de gérer l'intensité du rétroéclairage par logiciel...). Et en effet, il semble que si on a une perturbation sur les lignes SPI alors que le CS est à 0, alors il faut réinitialiser la SD pour pouvoir reprendre son contrôle.

JF, qu'entends-tu par le côté "pas assez costaud" du 168? il demande un gros buffer? (sûr qu'avec 1/2K de ram, on n'ira pas loin our gérer un buffer série et SD...)

Mais dans l'idée, il y aurait des choses à chercher, tant qu'à mettre 65 euros dans un LCD...

Je m'attaque aux fonctions texte, donc une suite de l'étude à venir...

al1fch:
Bonjour
Pour ma part s'il reste une sortie disponible sur l'Arduino je préfère gérer CS.
En mettant CS à la masse on prend un petit risque de perturbation de la carte SD à la mise sous tension de l'Arduino car les sorties MOSI, et SCK peuvent 'hésiter' un peu avant de prendre leurs valeurs initiales...
D'autre part il est sans doute préférable de laisser la carte SD s'initialiser avant de valider son interface SPI par CS.

Effectivement si il y a la place c'est préféreable, j'avais lu un peu vite

Oliv4945:
Effectivement si il y a la place c'est préféreable, j'avais lu un peu vite

C'est ce que je disais : il ne reste plus de place, sauf à sacrifier la gestion logicielle du rétroéclairage qui n'est qu'un gadget, et qui nous libèrerait justement le CS du port SPI, que demander de mieux... Quand au petit pimousse de 168, je pense qu'il peut gérer une SD, à condition de bien faire attention dans la programmation. J'ai fouillé dans le hardware serial, si la ram est inférieure à 1000 octetc, ils allouent un buffer série de 32 octets, sinon, 128. j'ai modifié pour qu'entre 1000 et 2000 octets, il ne soit alloué que 64 octets, j'ai donc gagné 64 octets de ram... Ce genre de manip doit être faite un peu partout s on veut que ça tienne, car beaucoup de sketches touts faits ne se soucient pas trop de l'utilisation de la ram, vu que sur un PC, il n'y a pas de limite et que les programmeurs de sketches ont tendance à avoir une formation de base sur PC...

Super_Cinci:
JF, qu'entends-tu par le côté "pas assez costaud" du 168? il demande un gros buffer? (sûr qu'avec 1/2K de ram, on n'ira pas loin our gérer un buffer série et SD...)

On en discutait avec skywodd, sans trop approfondir, mais les essais que j'ai fait avec ma duemilanove(168) ne me permettent pas d'utiliser la Carte SD.

Jean-François:
On en discutait avec skywodd, sans trop approfondir, mais les essais que j'ai fait avec ma duemilanove(168) ne me permettent pas d'utiliser la Carte SD.

Tu as un lien vers ce topic? (ou était-ce privé... :slight_smile: ), car ça m'intrigue. Surtout le pourquoi tu n'y arrives pas. Peut-être faut-il coder directement sur le hard (par les registres et non pas SD.h, on n'est jamais si bien servi que par soi-même (ma devise))? Je pense que je ne vais pas tarder à prendre un support SD et au pire, s'il ne trouve pas sa place sur le 168, j'ai un autre projet qui l'accueillera sur un 2560...

http://arduino.cc/forum/index.php/topic,75761.0.html

Jean-François:
http://arduino.cc/forum/index.php/topic,75761.0.html

je viens juste de tout lire :slight_smile: merci!