[Gérard]

bonsoir,

Schema ici

Video là
avant alignement et remplacement des chiffres par des plus gros.

avec source ...et Hex

Bonjour à tous,

Paul, je n'arrive pas à ouvrir le lien vers le schéma. Test avec 2 ordis.

La vidéo :

[paulfjujo]

bonsoir,

Paul, je n'arrive pas à ouvrir le lien vers le schéma. Test avec 2 ordis.

entre temps j'ai réactualisé le schema !

et j'ai aussi rajouté un effacement complet d'ecran, QUE si on modifie les parametres de la RTC ,via un terminal
car les nouvelles positions des aiguilles ne seraient plus en rapport avec les anciennes positions .. risque de baver !
c'est quasiment invisible..

[Gérard]

Ca marche.

[Temps-x]

Bonsoir paulfjujo, Gérard, venom, cyril13110, et tout le forum,


Je vous tient au courant de mes premier ligne en ASM pour cette montre, j'ai réusi à logé certain fichier graphique dans un 18F26K22 qui a seulement 64k, comme je travaille je n'avais pas tellemnt le temps, sans x

Des que j'ai fini d'écrire le programme je vous le fait voir.....

Source du message Temps-x, c'est une photo de ma montre.
Je n'ai pas les compétences pour le concours.

il fait le modeste Gérard comme d'hab.... je suis sur qu'il va tous nous étaler.

C'est une très belle montre que tu as là, j'espère que tu sais ton servir....

reste à voir

A+

[venom]

Bonjour à tous.

D'accord Temps-X, Merci de donner des nouvelles.
T'inquiète on à tous des à côtés. Même si ça passe vite tu as dit pour fin d'année






@++

[Temps-x]

Bonjour tout le forum,

Pas Possible, c'est pas Français... Voici dans un Pic18F26K22 qui a seulement 64k de mémoire programme.

Les données sont en mémoire programme, il n’y a pas de transmission usart.

Taille du bmp : 176128 octets

IMG_20260406_151341.jpg

Taille du bmp : 176128 octets

IMG_20260406_153303.jpg

je crois que je pourais faire tenir 2 fichiers graphique en mémoire programme, en graphique moyen.

Voici le schéma

Schéma.png

Maintenant je m'attaque à faire tourner les aiguille.

4 Fichier à choisir pour mettre dans le pic Pic18F26K22 teléchargement ICI

Schéma téléchargement ICI

A+

[paulfjujo]

bonjour TempS et à tous,

tu as bon fond !

MAIS commment tu rentres 176 128 bytes dans 64K Flash ?
ou c'est un BMP 8bits 256 couleurs : 240x240=57600

Mettre un fond d'image c'est une chose
..mais il faut avoir aussi un peu de place pour le code !

on pourrait effectivement reduire drastiquement le code que j'utilise
* pas d'UART, ni interrupt, ni SMT1
* le minima pour L'OLED : bus SPI, 'init OLED , putpixel ,drawline ,DrawBMP ,pas de fontes de caracteres
* le minima RTC I2Cinit, Registre init,lecture RTC (quid Mise à jour)
pour faire rentrer au chausse pied une image 240x240x2 de 115200 .. et garder suffisament de place pour le code
mais j'en doute fort ... ASM plus fort que tout ?

j'ai fait un test avec un BMP16bits de 128x160 -> 40960 bytes
image centrée dans un cercle exterieur Noir
facile pour un 18F47K42 !


AVEC la gestion des aiguilles, RTC ...
taille de code 68.5% 89769 bytes
taille ram 49.4% 4050 bytes

MAIS ...il me reste à sauvegarder la partie image SOUS les aiguilles
pour pouvoir la restituer apres deplacement ,qui necessiteront des buffers en RAM !
Pas evident puisqu'on ne peut pas lire le buffer de l'OLED ...
relire les 2 bytes couleur de chaque pixel via la table ( fichier BMP.H en flash )
avec un decalage d'origine (Centre du BMP et centre du cercle second) ..
bref de quoi cogiter.
comme tu dis ..pas impossible !

pourquoi faire simple quand on peut faire inextricable

mais bon , je vais laisser un peu de boulot aux autres participants..

Horlog_Analog_Img_test_2026-0406.jpg

[venom]

vous êtes trop fort les résultats sont là
Bon Temps-X reste la gestion des aiguilles + réparation du fond ...

@paulfjujo super rendu avec les aiguilles qui tournent même si je n'en doutais pas 1 secondes sans jeux de mots

Je ne suis pas sûr de savoir sortir un truc aussi poussé mais bon... On y croit

@Temps-X c'est quoi ton bouton reset sur le MCLR ? Ça fait plusieurs montage que je vois ça





@++

[Temps-x]

Source du message MAIS commment tu rentres 176 128 bytes dans 64K Flash ?

Toutes les ruses sont permi dans ce grand concours avec un grand nombre de participants, du moment de rester honnête en fournissant les fichiers pour que d'autres personnes puissent faire la même chose avec le même pic.

J'attendais que tu me poses cette question on n'a pas de pétrole mais on a des idées....

je me suis fabriqué un format de compression personnalisé il faudra que je lui trouve un non , il fonctionne bien quand il n'y a pas beaucoup de couleurs.

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

04-06-2026 17-47-49 (24 bits).png

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

Mon format de compression n'est pas valable pour les graphiques avec beaucoup de couleurs car la taille change peu.

Mais il peut être améliorer par la suite, la décompression se fait en 20 ligne en ASM

Source du message ASM plus fort que tout ?

Source du message j'ai fait un test avec un BMP16bits de 128x160 -> 40960 bytes
image centrée dans un cercle exterieur Noir
facile pour un 18F47K42 !

Figure-toi que j'y avais pensé, c'est bien cogiter de ta par, après suffit de redésiner par dessus, mais il y aura perte du graphique

Reste à résoudre se problemo !

Source du message @Temps-X c'est quoi ton bouton reset sur le MCLR ? Ça fait plusieurs montage que je vois ça

C'est pour faire un reset quand tu appuis dessus, le pic redémarre à zéro

A+

[Gérard]

Je déclare forfait...
Vous êtes trop forts pour moi.
Non je ne suis pas modeste, juste réaliste.

Ceci dit,
J'aime beaucoup ce que vous faites.