[Temps-x]

Il n'y a eu aucune modification du règlement, il y a eu juste des précisions, car certaines personnes ne comprenaient pas ce que je voulais leurs dire.

paulfjujo la suivi et compris.

Source du message Un fond bitmap il y en a un.

Non, il faut un graphique, comme je l'ai dit au début, et redit en cour du post 57, il y a pas mal de temps ( 11 avr. 2026 ), un fond sans rien n'est pas valable, ça serait trop facile.

C'est plus un jeu qu'un concours, c'est surtout pour muscler notre cerveau comme beaucoup l'ont compris ici.


A+

[venom]

mince j'avais mal vue. C'est pas une vidéo de paulfjujo mais de F6FC0

Bravo a toi F6FC0 tu as sortie une belle montre entre la pergola, les panneaux solaires, le système pour que chaque chat mange dans sa gamelle.... je 'e sais pas comment tu fais pour géré tout ça mais






@++

[satinas]

Bonjour, elles sont jolies vos horloges

C'est pas compliqué, F6FCO, il faut un superbe fond d'écran, mais il ne faut pas l'envoyer sous forme de bitmap, cela m'a été clairement dit. Il est regrettable que ta question n'ai pas eu de réponse correcte, car cela aurait pu améliorer la compréhension. Je propose de passer aux courbes de Bézier et repousser l'échéance à la fin de la décennie.

Un point que je ne comprends pas dans le réglement ? tu dis à Satinas pas de bitmap mais tu nous présentes des écrans avec des GrosMinets ou tête jaune ? tu les as dessinés en code ?

Réponse incompréhensible :

Le Bimap est autorisé dans le Pic, mais l'envoi par usart, spi ,IC², ou autre moyen ne l'est pas, comme voulait faire satinas, et de plus pour durcir le concours on doit rester avec un microcontroleur Pic 8 bits

F6FCO insiste

Moi non plus je ne comprends pas, ton bitmap de fond il faut bien que tu l'envoies par SPI, tu ne le graves pas au burin sur l'écran ?

Là pas de réponse, on est reparti sur la compression, qui est un sujet annexe et hors réglement ...

[paulfjujo]

bonjour à tous,


Belle presentation de F6FCO !
Peux-tu preciser le format de ton image de fond taille et nombre de couleurs ?
une image en 2 couleurs revient à ne pas utiliser de BMP eb arriere plan.

actuellement,j'utilise une image BMP 24bits couleurs qui apres reduction du nombre de couleurs à 256
avec Paint Shop Pro 5 reduit notablement la taille de la table du BMP , à 240x240 = 57600bytes
je recupere la palette associée au Bitmap 256 couleurs
table de 256x R,G,B ( RGB888)
Avec excel je cree une table correspondante en 256x 16bits RGB565 assimilable par l'Oled
Le BMP 256couleur est traduit en table C avec https://notisrac.github.io/FileToCArray/

Pour afficher le BMP, il suffit d'utiliser les coordonnes x,y de chaque pixel de la table BMP en C
pour recuperer l'index de couleur 16bits de la palette RGB565
et envoyer le MSB et LSB en SPI vers l'oled

Nota:
il y a bien sur une perte d'info couleur , depend beaucoup du nombre initial de couleur dans l'image
originale/ initiale BMP 24B
on pourrait meme utiliser une image 16 couleurs ... mais la taille image reste 240x240=57600 bytes !

ou creer une image RONDE ! (PI()x240x240)/4 => 45238 bytes au lieu de 57600!
mais avec du code en plus!

si la couleur rouge n'existe pas dans l'image,on peut alors utiliser un Bitmap 24bits
avec Rouge=0 => les couleurs G,B etant sur 1 seul byte
tennat dans 57600 bytes


Reduire la taille de l'image en la compressant , c'est une piste ...
mais il faut prenser à la suite ..sauvegarde et restitution de l'arriere plan des aiguilles ...

la solution de facilité : redessiner entierement l'image arriere plan prend trop de temps (102mS en C )
=> flickering il faut descendre à <=20mS
en ASM ?



... à suivre

[satinas]

Bref vous envoyez des bitmaps, quoi

[paulfjujo]

Bref vous envoyez des bitmaps, quoi

Oui et NON
..je ne suis pas normand ..

il est inclus comme un fichier annexe dans le programme ...
table de 57600 bytes, donc resident.
au lieu d'etre envoyé de l'exterieur via l'UART par exemple.

[satinas]

Un montre à pic serait donc censée avoir besoin d'un PC aux fesses pour savoir ce qu'elle doit afficher quand on la démarre, on est où là ?

[paulfjujo]

Un montre à pic serait donc censée avoir besoin d'un PC aux fesses pour savoir ce qu'elle doit afficher quand on la démarre, on est où là ?

il faut bien initialiser la RTC ! la 1ere fois .. via l'UART !
ou via des BP sur entrees PIC .. sans PC aux fesses

a moins d'etre avec un ESP32 et un server NTP pour synchroniser date et heure en Wifi ...

[satinas]

On va pas encore dévier, on parlait de bitmap, et d'ailleurs un bitmap compressé est toujours un bitmap.
Je verrai bien la RTC à côté du pic, et un seul poussoir pour la mettre à l'heure, en jouant sur la durée d'appui. En fait la RTC c'est du poids en trop, confert l'horloge inspirée de https://www.romanblack.com/one_sec.htm pour s'en passer.
Tu sais que le 18F27K42 fait du DMA sur le SPI, c'est le moment viewtopic.php?t=1241

[F6FCO]

D'accord, je comprends qu'il faut un truc derrière pour prouver que les aiguilles ne le déforment pas en passant dessus. Perso faire de la compression d'image ne m'intéresse pas plus que çà et je ne perdrai pas de temps là-dessus, aucune utilité en petite robotique. Si c'est le but il fallait le spécifier clairement au départ, ce qui n'a pas été fait, donc je considère que la montre ci dessous tient les engagements du réglement. Ici le modif de fond d'écran est créé par code. Vite fait pour l'exemple, on pourrait faire plus compliqué, le PIC en a encore sous le pied.


https://www.youtube.com/watch?v=fyxhPj9LPA4

Paul, je n'avais besoin que de 4 couleurs, une pour le fond, une pour les chiffres et deux pour les ombres claires et foncées: 240x240 14400 octets.Le soft 3D que j'ai utilisé pour le dessin ne permet pas beaucoup plus.
Une routine pour la mise a l'heure fait partie des trucs à ajouter mais je ne me vois pas porter çà au poignet avec un PIC PDIP, PCB et alim dans le sac à dos.

la solution de facilité : redessiner entierement l'image arriere plan prend trop de temps (102mS en C )
=> flickering il faut descendre à <=20mS
en ASM ?

Non je ne pense pas, même avec mon image de 14k sur le PIC à 32MHz on la voit s'afficher, rapide mais très visible. Elle ne le fait qu'une fois au départ alors çà va mais on ne pourrait pas s'en servir pour la ré-afficher à chaque mouvement d'aiguille, ce serait saccadé et moche. Je vais mesurer le temps d'affichage et je te dirai.
EDIT: affichage fond d'écran 338ms pour 14.4k, PIC18F2620 à 32MHz PLL et SPI 8MHz

NOTA: Désolé pour la qualité vidéo mais mon APN ne veut rien savoir cette fois, faite avec le smartphone. J'essaierai d'en faire une mieux mais j'ai encore des trucs à ajouter. Bizarrement l'APN qui a bien fonctionné hier me rend bien ce matin le contexte dans la vidéo sauf l'écran de la montre qu'il rend tout noir. Vidéo faite avec le smartphone. Je vais essayer de faire mieux.