[paulfjujo]

Bonjour tout le monde,

Question à Pauljujo, quand tu as un fichier 8 bits ta configuration reste en 16 bits
Car tu es bien obligé d'envoyer deux octets à chaque fois pour afficher un pixel
La seule chose que tu gagnes en ayant un fichier 8 bits c'est la taille mis dans le pic.

Ce qui fait que tu ne gagneras aucune vitesse au niveau de la
transmission d'un pixel même avec un fichier 8 bits.

Est-ce que j'ai raison ou est-ce que j'ai tort ?

A+

Oui, tout à fait ...

mais 57600 bytes au lieu de 115200 ,ça laisse plus de place pour y mettre du code
..et je transforme la palette 256 couleurs RGB332 en palette 256 couleurs RGB565 sur 2 bytes ,assimilable pour la couleur OLED 16bits
le but n'est pas de gagner en vitesse puisque je dispose d'un delay d'attente > 920mS entre chaque seconde..
chaque seconde :
Affichage des 3 aiguilles pendant 920ms
puis remise en place de l'arriere plan

j'en suis à :
18F47K42 Memory Summary:
Program space used 16D6Eh ( 93550) of 20000h bytes ( 71.4%)
Data space used 1423h ( 5155) of 2000h bytes ( 62.9%)
Configuration bits used 5h ( 5) of 5h words (100.0%)
EEPROM space used 0h ( 0) of 400h bytes ( 0.0%)
ID Location space used 0h ( 0) of 10h bytes ( 0.0%)
Data heap space used B7Ah ( 2938) of B7Ah bytes (100.0%)

en utilisant qu'une seule fonte caractere seulement.

remarque :
93550 - 57600 = 35950 déja occupé par le code
si BMP de 115200 bytes
=> impossible avec 128K de flash !

[Temps-x]

Bonsoir paulfjujo,

pour cette précision, même si mon Pic est moins rapide que le tien sur le protocole SPI, ça devrait tourner encore pas mal de petit truc à régler dans ma tête.

Je n'ai pas encore écrit une seule ligne de code sur cette montre, je pratique la théorie avant toute chose, faire tourner cette aiguille, ce n'est pas vraiment difficile, ce qui est difficile, c'est d'avoir un vrai fond graphique de grande taille avec plus de 16 couleurs, sans effacer le reste.

Le soir de semaine travaillé, je ne peux rien écrire, pas le temps.....

A+