[Temps-x]

Source du message Il faut faire une exception pour les chiffres, sinon on ne pourra travailler l'esthétique, en plus eux ils restent fixes.

Si on fais cela, ça devient trop facile, ce concours est fais pour se creusser les neurones, c'est comme un défi pour celui qui veut participer.

Source du message ChatGPT me dit que la vitesse max en SPI avec les 8 bits est de 32 MHz.

C'est vrai d'après paulfjujo, car il à testé avec un Pic18F47K42 et c'est largement suffisant si on ne fait pas des aiguilles de grosses tailles

Pour ma par, je me suis fabriqué un compresseur de fichier Bmp, , la décompression se fait en 20 ligne en ASM

Par exemple un fichier comme ci-dessous en format BMP (16 bits) a une taille de 118784 octets

04-11-2026 14-00-50 (24 bits).png

Une fois compressé avec mon format, le fichier fait 32934 octets sans aucune perte !!

Autre exemple fichier comme ci-dessous en format BMP (16 bits) a une taille de 118784 octets

04-11-2026 14-00-40 (24 bits).png

Une fois compressé , le fichier fait 38601 octet

Je peux même réduire encore la taille, car j'ai coçu un autre paramêtre dans la compression.

Ce qui me permets d'avoir encore de la place pour autre chose, comme les aiguilles

A+

[paulfjujo]

bonjour à tous,



image BMP compressée de 32934 bytes ..OK ça rentre à l'aise sur un 18F26K22
et encore mieux sur un 18F27K42!
mais pour gerer les affichages aiguilles , il faut pouvoir LIRE le contenu du BMP sous les aiguilles
pour sauvegarder le contenu , afin d'EFFACER les anciennes positions, remplacées par le fond d'ecran
puis Afficher le nouveau contenu position aiguilles en cours.

associer position d'aiguille et contenu fond d'ecran !
si en plus ton contenu BMP est compressé ???

sur le 18F27K42, j'ai testé le rafraichissement d'un BMP de 220x220x2 ..254mS
à chaque boucle programme :
beaucoup trop lent! flickering tres important ..inutilisable

Ma situation :
En simpifiant et ne gardant QUE le minima necessaire
*UART pour remise à l'heure RTC et aide au debugging
*I2C2 pour RTC
*SPI1 32MHz pour l'OLED
*STM1 pour chronometrage 99.8% !!

la compilation donne :
*Programm space used : 94.2% (sans SMT1)
*Data Ram space used : 44.2%
Eeprom not used

AVEC Arriere plan montre situé en Flash:
* Coccinelle 220x220 RGB565 16bits ..sur 2 tables de 48400 bytes soit 96800 bytes en Flash
* Table de 360 sinus et 360 cosinus en flottant 360x2*4 => 2880 bytes en flash
* 1 seule police de caractere Arial_Narrow22x32 -> 2322 bytes en RAM char de 22x32 pixel
* Buffer UART 128bytes

J'affiche le fond d'ecran BMP 1 seule fois, puis
* dessin des graduations sec et 5sec
* affichage des 4 chiffres quadran 12,3,6,9 (char de 22x32 pixel)

Debut boucle :
* lecture RTC
* dessin des 3 aiguilles (positions angulaires Liées à RTC)

job to do.... en cours
Traitement sauvegarde et restitution arrire plan BMP
...SANS depasser les 5.8% restant pour le code !

..goto debut Boucle


La taille du BMP doit etre carrée et supériere à la longueur (troteuse*2)
puisque c'est la zone, aire du mouvement Troteuse.. (choix 108 pixels) => carré de 220x220
Celle ci n'empietant pas sur les graduations et chiffres
le contenu SOUS les aiguilles appartiendra donc toujours au contenu BMP.

le point commun Aiguilles et BMP est le centre de l'ecran en 119,119 (120 pixels : entre 0 et 119)
la table des sinus cos est centrée de -180 à +180 avec mon ecran orienté HAUT coté connections du module
de sorte à avoir l'aiguille seconde verticale sur Minuit (ou 00H)
sur le debut de ma table angulaire index 0 à 359 (secondes x 6)

si il manque de la palce pour le code ..reduire le Bitmap BMP à 210x210 et Long. troteuse 104 pixels

[F6FCO]

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 ?

De mon coté je voulais travailler sur un 18F2525 mais je pense que ce sera juste en mémoire, je passe sur 18F2620

[Temps-x]

Bonsoir paulfjujo, F6FCO et tout le forum,

Source du message 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 ?

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.

Un graphique peut représenter n'importe quoi, mais on doit au moins la voir.

Réglement : post #57 ou j'explique ceci

Je sais c'est pas facile, mais c'est faisable, ça implique pas mal de connaisance dans la programmation.

paulfjujo a presque réussi à le faire, mais le gros problème c'est qu'il faut redessiner le graphique à chaque passage d'une aiguille

Source du message De mon coté je voulais travailler sur un 18F2525 mais je pense que ce sera juste en mémoire, je passe sur 18F2620

Effectivement le Pic18F2525 n'a que 49152 octets de mémoire programme, c'est trop juste, par contre un Pic18F2620 à 65536 octets de mémoire
programme, mais ça sera encore trop juste si tu ne compresse pas les données comme je l'ai fait.

Un Bimap pour cette écran représente (240x240) x 2 = 115200 octets

A+

[satinas]

Sacré Temps-x
- Je comprends toujours rien à cette histoire de bitmap.
- Tu as réinventé la compression RLE déjà très utilisée dans le format BMP.

[F6FCO]

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 ?

[Temps-x]

Un Bimap pour cette écran représente (240x240) x 2 = 115200 octets, j'ai donc créé un programme PC pour compresser les données, puis je mets
les données dans mon Pic en mémoire programme

Voici le programme

Compresseur.png

Voici un fichier qui à était compressé avec mon programme téléchargement ICI

A+