[paulfjujo]

bonjour,

4 couleurs utiles ?
blanc,noir,gris,jaune
taille independante du nombre de couleurs ?

OK, tu as resolu le probleme de taille BMP pour qu'il puisse rentrer dans un 18F26K22 ....

....238 couleurs sont définies dans la palette de mon BMP.
dont au minimum bien reperables, rouge, jaune, vert, cyan, gris clair, gris foncé, noir et blanc

mon questionnement repose surtout sur la localisation des pixels à reconstituer,
apres affichage aiguille via un mappage compressé de l'arriere plan ?
car une fois affiché sur l'OLED, il occupe quand meme 57600 bytes dans la memoire OLED
mais memoire qu'on ne peut pas lire !

[Temps-x]

Bonjour paulfjujo, et tout le forum,

Source du message 238 couleurs sont définies dans la palette de mon BMP.

Normalement tu ne devrait pas avoir autant de couleur pour le fichier de la montre de Gérard, à titre d'exemple

Quand je regarde le fichier d'origine on trouve ceci

Informatio.png

Comme tu peux le voir on trouve 10 couleurs, ce qui veux dire qu'il y a un problème lors d'une réduction de l'image.

Une fois réduit dans le même format je trouve ceci

Réduction.png

De 10 couleurs en passe à 3476 couleurs mais d'ou ça peut venir ...? sa reste un problème car la compression serait bien plus importante si j'avais pas ce problème.

La preuve
Si je prends un programme de conversion d'image que j'ai écrit en RapidQ j'obtiens bien mais 10 couleurs, et là il n’y a pas photo
compression impressionnante puisque qu'on passe à 12 Ko (12480 octets)

12 ko.png

on va bientôt le faire tenir dans un Pic16F84A

Source du message mon questionnement repose surtout sur la localisation des pixels à reconstituer,

Dans la version du fichier hexadécimal que je mets en téléchargement dans le post #130 il n'y a pas de label.

ils vont être rajoutés aujourd'hui, 240 au total, pour chaque ligne, ce qui fait que tu as déjà un repère sur la ligne à te rendre (hauteur),

il ne reste plus que la largeur à traiter ou il faudra lire la largeur, ça peut aller très vite, je dirais même en 5 ou 10 lectures ça peut être fait, ou
Tu connaîtras la couleur des 2 données, ce qui est insignifiant en ASM à raison de 62,5 ns par instruction,

Après en stock dans la ram.

il ne faudra pas dépassé 25ms si on veut faire autre chose par la suite, comme un vu-métre avec l'aiguille sur les graduations.

Comme j'ai pris une journée de congé, je vais pouvoir rajouter les labels.....

A+

[paulfjujo]

Dans la version du fichier hexadécimal que je mets en téléchargement dans le post #130 il n'y a pas de label.
ils vont être rajoutés aujourd'hui, 240 au total, pour chaque ligne, ce qui fait que tu as déjà un repère sur la ligne à te rendre (hauteur),
il ne reste plus que la largeur à traiter ou il faudra lire la largeur, ça peut aller très vite, je dirais même en 5 ou 10 lectures ça peut être fait, ou
Tu connaîtras la couleur des 2 données, ce qui est insignifiant en ASM à raison de 62,5 ns par instruction,
Après en stock dans la ram.
il ne faudra pas dépassé 25ms si on veut faire autre chose par la suite, comme un vu-métre avec l'aiguille sur les graduations.

[quote]ils vont être rajoutés aujourd'hui, 240 au total, pour chaque ligne/[quote

.... il y a 240 lignes d'ecran
240x240=57600 !

tu te comprends , c'est déja pas mal ...
moi, j'ai rien pigé ..

[Temps-x]

Source du message .... il y a 240 lignes d'ecran 240x240=57600 !

C'est le programme écrit en RapidQ qui va tout gérer, pour créer un fichier ça prendra même pas 1 minute, mais bon, il faut l'écrire.

Source du message tu te comprends , c'est déja pas mal ..

Je suis parti sur une idée, mais je ne sais pas si elle va aboutir, pour l'instant c'est bien parti... reste à voir dans la vraie vie

ça sifflote de partout a ce que je peux voir

A+