[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+

[paulfjujo]

bonjour,

version aiguille filaire ..en version accélrée pour faire la video ci dessous
visu dynamique accélérée

à suivre : doublement epaisseur aiguille minute et heure

Nota:
Attention à la subtilité
* couleur arriere plan Tom et Jerry BMP => en RGB332 8 bits et valeur index Palette 256 couleurs du fichier ! tranformée en RGB565
* couleur aiguille = valeur RGB565 16bits

les coordonnes XY du vecteur aiguille permettent de recuperer les couleurs originales du BMP ( pour pouvoir les restituer plus tard)
ces memes coordonées stockées dans un buffer , sont utilisées pour afficher les pixels Aiguilles avec leur couleur RGB565 predefinies
apres un delay important (>950mS), puis remise en place couleurs BMP
le rafraichissement aiguille se faisant quand dès qu' on atteint la seconde suivante (à 1000mS )

j'ai utilisé SMT1 chrono pour definir/mettre un delay d'affichage le plus grand possible pour limiter le flickering..

Logigramme

[Temps-x]

Bonsoir paulfjujo, et tout le forum,


Tu es bien dans ce qui est demandé au début du post #1, c'est validé
Tu es le premier à l'avoir fait, reste à voir avec les autres participants encore une fois

En restant honnête, on voit quand même qu'il manque des couleurs, le fichier original comporte en 24 bits (5752 couleurs) une fois passé en 16 bits
(1763 couleurs) qu'il faudra remettre en 256 couleurs par la suite... une sacrée descente ..... mais ça reste une belle démonstration, avec beaucoup
d'imagination technique

Source du message à suivre : doublement epaisseur aiguille minute et heure

Justement , et c'est pour cela que je t'ai posé la question concernant la vitesse d'affichage, et vitesse SPI, avec une aiguille de 140 pixels,
qui représente 1 simple trait, ok c'est faisable

Maintenant si on multiplis par 5 pixels, qui est représente dans l'horloge de Tom et Jerry, ça nous fait (140*5) *2 = 1400 données à envoyer

Est ce que ça va suivre ?

J'ai contrôlé sur mon Pic18F26K22 la vitesse SPI, elle avoisine les 2 µs arrondi à 3 µs par données, ce qui nous fait 1400*3 = 4200 µS

Sachant qu'il y a l'aiguille des minutes, et seconde à afficher, on exagérant beaucoup ça nous donne (4200 *3 = 12600 µs) /1000 = 12,6 ms

Logiquement c'est faisable.

En ce qui me concerne mon fichier restera en 16 bits compressé, et peut être utilisation de Bresenham

Et pourtant j'avais dit que je ne l'utiliserai pas, tout le monde peut se tromper, et personne n'est parfait.

A+