Un peu de programmation :
Pour ce qui est de la programmation des LCD, j'ai dû créer des tables de caractères pour pouvoir afficher les valeurs en un peu plus gros que les caractères de 5mm d'origine. J'ai fait deux polices, l'une reprenant la classique LCD, et une autre qui ressemble plus à du 7 segments. Comme je n'ai pas trop de mémoire, je n'ai créé que des chiffres. un chiffre représente quand même 9 octets (deux polices de 10 caractères = 180octets en ram), par exemple, un 2 codé en police classique :
caractere_2[9] = {0x1C, 0x3E, 0x63, 0x03, 0x06, 0x18, 0x60, 0x7F, 0x3F}
Lorsque je me suis bien pris la tête à coder mes caractères, j'avais dans l'idée d'afficher en double les lignes de 1 à 6 du tableau pour diminuer la taille en mémoire, afin de sortir un caractère de 7x14 pixels avec seulement 9 octets. le résultat prévu était :
XXX 1C
XXXXX 3E
XX XX 63
XX XX
XX 03
XX
XX 06
XX
XX 18
XX
XX 60
XX
XXXXXXX 7F
XXXXXX 3F
Sauf que j'avais oublié de doubler les lignes du milieu... ça m'a affiché ça :
XXX 1C
XXXXX 3E
XX XX 63
XX 03
XX 06
XX 18
XX 60
XXXXXXX 7F
XXXXXX 3F
Petite erreur, mais intéressante finalement. Je me suis aperçu que je pouvais garder ça, donc j'ai défini deux tailles : 0 : simple en 7x9 (l'erreur), et 1 : 7x14 (l'idée d'origine) en doublant les lignes du milieu. Mais j'ai fini par élargir mes caractères en transformant mon octet "ligne" en un word, qui double chaque bits de l'octet, ce qui m'a permis d'obtenir deux tailles supplémentaires, taille 2 (14x9) :
XXXXXX 1C
XXXXXXXXXX 3E
XXXX XXXX 63
XXXX 03
XXXX 06
XXXX 18
XXXX 60
XXXXXXXXXXXXXX 7F
XXXXXXXXXXXX 3F
et taille 3 (14x14)
XXXXXX 1C
XXXXXXXXXX 3E
XXXX XXXX 63
XXXX XXXX
XXXX 03
XXXX
XXXX 06
XXXX
XXXX 18
XXXX
XXXX 60
XXXX
XXXXXXXXXXXXXX 7F
XXXXXXXXXXXX 3F
Côté écran, ça donne ça :
Avec dans l'ordre des lignes :
- police interne du LCD 5x7
- police perso 0, taille 0
- police perso 1, taille 0
- police perso 0, taille 1
- police perso 1, taille 1
- police perso 0, taille 2
- police perso 1, taille 2
- police perso 0, taille 3
- police perso 1, taille 3
Il faut que je règle le contraste, c'est un peu faiblard...
Pour la rapidité d'affichage, le remplissage de l'écran ci-dessus est invisible. Pour ceux qui me connaissent, ils savent déjà que je n'utilise aucun digitalWrite() ou pinMode() pour envoyer les données du 168 au T6963C, ni aucun delay() dans les impulsions, le T6963 est donné pour des tempos de 100ns, mes signaux font minimum 2 cycles FOSC, donc 123ns, je suis pile-poil dans les temps!
Le rétroéclairage est géré par une PWM du 168, donc par logiciel. Le mec qui avait développé le code d'origine du 168 chez sparkfun avait utilisé le timer2 qui générait une interruption toutes les 0.5ms, et à chaque interruption, il comptait pour savoir où il en était. S'il avait atteint la valeur d'éclairage souhaitée, faisait un bit_set / bit_clear sur la pin de sortie. une belle PWM en soft, sûr, mais qui devait bouffer un temps pas possible dans le code. Il n'avait même pas vu qu'il avait câblé les leds du rétroéclairage sur la pin OC1B, et qu'il suffisait de faire tourner le timer1 en PWM pour se décharger de toute perte de temps. Tout comme il avait défini un buffer de réception série de 512 octets (donc indexé par une variable de 16 bits et occupation du quart de la RAM), alors qu'un buffer de 256 octets était suffisant et tellement plus pratique à gérer : un index sur 8 bits revient tout seul à zéro après 255, même pas besoin de faire un index = index % 256 ou encore un if (index > 255) index = 0... autre bug rigolo : selon l'inclinaison d'un ligne à tracer, il manquait des pixels. Il y a aussi une fonction qui était dans la doc, mais pas implémentée dans le code, quand on l'appelle par port série, le LCD l'affichait sous forme de caractères insensés.
Bref, je ne sais pas comment ils recrutent leurs développeurs chez sparkfun, mais il vaut mieux se méfier de leurs produits...