Temps-x a écrit :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 !

pour cette précision, même si mon Pic est moins rapide que le tien sur le protocole SPI, ça devrait tourner