Bienvenue aux nouveaux arrivants sur FantasPic !
- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.
--- L’équipe FantasPic ---
- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.
--- L’équipe FantasPic ---
Modérateur : Jérémy
Montre analogique GC9A01
- paulfjujo

Maître- Messages : 3330
- Âge : 75
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
Temps-x a écrit :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 !
Montre analogique GC9A01
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+
pour cette précision, même si mon Pic est moins rapide que le tien sur le protocole SPI, ça devrait tourner 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.....
Montre analogique GC9A01
- paulfjujo

Maître- Messages : 3330
- Âge : 75
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
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
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
Montre analogique GC9A01
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
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+
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
paulfjujo a écrit :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
Montre analogique GC9A01
- paulfjujo

Maître- Messages : 3330
- Âge : 75
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
bonjour à tous,
140 pixel sur un rayon maximal possible de 240/2 = 120 ?
dans mon cas
// Aiguille Troteuse, epaisseur 1 pixel est constituée de
dessin : Longueur * ( couple coordonnées x + y + couleur 16b)
=> 90*( 2+2)= = 360
Effacement: restituer la sauvegarde arriere plan BMP
longueur * ( couple xy + index couleur 8b)=> 90 * (2+1)=270
Aiguille minute
dessin 82 *(2+2)= 328
effacement 82 *(2+1)= 246
Aiguille Heure
dessin 76 *(2+2)= 304
effacement 76 *(2+1)= 228
ce qui donne déja : 360+270 +328+246 +304+228 = 1736 bytes en RAM !
J'ai testé en triplan les aiguilles Minutes et Heure
=> rajout de 2 autres aiguiles Minute et 2 autres aiguilles Heure
soit 2 * (328+246 +304+228)= 2* 1106= 2212 bytes
nouveau total affecté en RAM : pour 7 aiguilles 1 troteuse, 3 minutes, 3 heures
1736+2212= 3948 bytes !
et là ..problemeo ..pas assez de RAM pour afficher les chiffres
// problemo allocation fonte #06
pour contenir ma fonte de gros caracteres qui prend à elle seule 2322 bytes
3948 + 2322 =6270
avec Fonte #06 en RAM
Program space used 15868h ( 88168) of 20000h bytes ( 67.3%)
Data space used 13ADh ( 5037) of 2000h bytes ( 61.5%)
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 BEEh ( 3054) of BEEh bytes (100.0%)
.. possibilté de reduire la taille de la fonte caractere à seulement 5 chiffres 1,2 ,3,6,9
modif majeure : passé la Fonte #06 en FLASH ( au lieu de RAM)
et suppression du selecteur de fonte (1 parmi 8) pour usage directe pointeur fonte en Flash
//avec selecteur de fonte en RAM
// Font_Active = 6;
// Select_Font_Type(Font_Active);
.... modif pour usage direct
SetFont(Arial_Narrow22x32);
economie de Ram palpable :
avec Fonte #06 en FLASH
18F47K42 Memory Summary:
Program space used 151BAh ( 86458) of 20000h bytes ( 66.0%)
Data space used A8Ch ( 2700) of 2000h bytes ( 33.0%)
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 1500h ( 5376) of 1500h bytes (100.0%)
explications sur La difference de taille RAM entre Dessin et Effacement :
L'Effacement sert à restituer le contenu BMP situé SOUS l'aiguille,(qui a été sauvegardé juste avant le dessin de l'aiguille)
je me sert de l'index palette 256 couleur en 8 bits , pointant sur une autre palette index de 16 couleurs
pour remettre la couleur d'origine BMP.
Alors que pour le Dessin, il faut bien envoyer une couleur 16 bits (2 bytes) sur l'OLED
adressage indirect indexé !
Dans ce contexte, je vais pouvoir retester ma version 7 aiguilles ...
TempsX a écrit :avec une aiguille de 140 pixels,
qui représente 1 simple trait, ok c'est faisable
140 pixel sur un rayon maximal possible de 240/2 = 120 ?
dans mon cas
Code : Tout sélectionner
#define Long_Troteuse 95
#define Long_Minute 82
#define Long_Heure 76 // Aiguille Troteuse, epaisseur 1 pixel est constituée de
dessin : Longueur * ( couple coordonnées x + y + couleur 16b)
=> 90*( 2+2)= = 360
Effacement: restituer la sauvegarde arriere plan BMP
longueur * ( couple xy + index couleur 8b)=> 90 * (2+1)=270
Aiguille minute
dessin 82 *(2+2)= 328
effacement 82 *(2+1)= 246
Aiguille Heure
dessin 76 *(2+2)= 304
effacement 76 *(2+1)= 228
ce qui donne déja : 360+270 +328+246 +304+228 = 1736 bytes en RAM !
J'ai testé en triplan les aiguilles Minutes et Heure
=> rajout de 2 autres aiguiles Minute et 2 autres aiguilles Heure
soit 2 * (328+246 +304+228)= 2* 1106= 2212 bytes
nouveau total affecté en RAM : pour 7 aiguilles 1 troteuse, 3 minutes, 3 heures
1736+2212= 3948 bytes !
et là ..problemeo ..pas assez de RAM pour afficher les chiffres
// problemo allocation fonte #06
pour contenir ma fonte de gros caracteres qui prend à elle seule 2322 bytes
3948 + 2322 =6270
avec Fonte #06 en RAM
Program space used 15868h ( 88168) of 20000h bytes ( 67.3%)
Data space used 13ADh ( 5037) of 2000h bytes ( 61.5%)
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 BEEh ( 3054) of BEEh bytes (100.0%)
.. possibilté de reduire la taille de la fonte caractere à seulement 5 chiffres 1,2 ,3,6,9
modif majeure : passé la Fonte #06 en FLASH ( au lieu de RAM)
et suppression du selecteur de fonte (1 parmi 8) pour usage directe pointeur fonte en Flash
//avec selecteur de fonte en RAM
// Font_Active = 6;
// Select_Font_Type(Font_Active);
.... modif pour usage direct
SetFont(Arial_Narrow22x32);
economie de Ram palpable :avec Fonte #06 en FLASH
18F47K42 Memory Summary:
Program space used 151BAh ( 86458) of 20000h bytes ( 66.0%)
Data space used A8Ch ( 2700) of 2000h bytes ( 33.0%)
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 1500h ( 5376) of 1500h bytes (100.0%)
explications sur La difference de taille RAM entre Dessin et Effacement :
L'Effacement sert à restituer le contenu BMP situé SOUS l'aiguille,(qui a été sauvegardé juste avant le dessin de l'aiguille)
je me sert de l'index palette 256 couleur en 8 bits , pointant sur une autre palette index de 16 couleurs
pour remettre la couleur d'origine BMP.
Alors que pour le Dessin, il faut bien envoyer une couleur 16 bits (2 bytes) sur l'OLED
adressage indirect indexé !
Montre analogique GC9A01
- paulfjujo

Maître- Messages : 3330
- Âge : 75
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
bonsoir,
je suis parti sur un autre concept que d'utiliser des structures avec x,y,couleur
... ça fait peut etre plus propre en langage C
mais maintenant j'utilise plutot une vision asm ...
je declare une grande table de bytes representant la surface des pixels BMP à remettre en place
apres l'affichage de 1 + 3 +3 aiguilles ( aiguille Minute et Heure dédoublées pour epaisseur de 3 pixels)
et 7 pointeurs sur le debut de zone à remplir...
extrais de code pour test usage des pointeurs
.. à suivre ...
je suis parti sur un autre concept que d'utiliser des structures avec x,y,couleur
... ça fait peut etre plus propre en langage C
mais maintenant j'utilise plutot une vision asm ...
je declare une grande table de bytes representant la surface des pixels BMP à remettre en place
apres l'affichage de 1 + 3 +3 aiguilles ( aiguille Minute et Heure dédoublées pour epaisseur de 3 pixels)
et 7 pointeurs sur le debut de zone à remplir...
extrais de code pour test usage des pointeurs
Code : Tout sélectionner
#define Long_Troteuse 95 //maxima
#define Long_Minute 82 //maxima
#define Long_Heure 76 //maxima
#define Taille_AR Long_Troteuse*4 +Long_Minute*12+ Long_Heure*12
#define Fin_Arriere_Plan = P_Heu2+Long_Heure
uint8_t Arriere_Plan[Taille_AR];
uint8_t * P_Trot;
uint8_t * P_Min ;
uint8_t * P_Min1;
uint8_t * P_Min2;
uint8_t * P_Heu ;
uint8_t * P_Heu1;
uint8_t * P_Heu2;
uint8_t * P_End;
// 3 epaisseur pour Min et Heure
// principe de sauvegarde pixel BMP avant d'ecrire le Pixel Aiguille
// 1 pixel modulo 4 dans la table !
// n1 le N° du pixel en cours de l'aiguille selectionnée
void Save_and_PutPixel(int8_t x,int8_t y,uint16_t color,uint8_t Choix)
{ uint16_t Index_Coul;
uint16_t k1,k2;
switch (Choix)
{ k1=n1<<2;
case 1:
*( P_Trot+k1) = x;
*( P_Trot+k1+1) = y;
Index_Coul= Image_de_Fond[x +((int32_t) y *240)];
k2=Palette_RGB[Index_Coul]; // sur 16b
*( P_Trot+k1+2) =k2>>8;
*( P_Trot+k1+3) =k2 & 0x00FF;
PutPixel(x,y,_Rouge);
break;
case 2:
* (P_Min+k1) = x;
* (P_Min+k1+1) = y;
Index_Coul= Image_de_Fond[x +((int32_t) y *240)];
k2=Palette_RGB[Index_Coul];
* (P_Min+k1+2) =k2>>8;
* (P_Min+k1+3) =k2 & 0x00FF;
PutPixel(x,y,_Noir);
break;
case 21:
*( P_Min1+k1) = x;
*( P_Min1+k1+1) = y;
Index_Coul= (uint16_t)Image_de_Fond[x +((int32_t) y *240)];
*( P_Min1+k1+2) =Index_Coul>>8;
*( P_Min1+k1+3) =Index_Coul & 0x00FF;
PutPixel(x,y,_Noir);
break;
case 22:
* (P_Min2+k1) = x;
*(P_Min2+k1+1) = y;
Index_Coul= (uint16_t)Image_de_Fond[x +((int32_t) y *240)];
* (P_Min2+k1+2) =Index_Coul>>8;
* (P_Min2+k1+3) =Index_Coul & 0x00FF;
PutPixel(x,y,_Noir);
break;
case 3:
* (P_Heu+k1) = x;
* (P_Heu+k1+1) = y;
Index_Coul= (uint16_t)Image_de_Fond[x +((int32_t) y *240)];
* (P_Heu+k1+2) =Index_Coul>>8;
* (P_Heu+k1+3) =Index_Coul & 0x00FF;
PutPixel(x,y,_Navy);
break;
case 31:
* (P_Heu1+k1) = x;
* (P_Heu1+k1+1) = y;
Index_Coul= (uint16_t)Image_de_Fond[x +((int32_t) y *240)];
* (P_Heu1+k1+2) =Index_Coul>>8;
* (P_Heu1+k1+3) =Index_Coul & 0x00FF;
PutPixel(x,y,_Navy);
break;
case 32:
* (P_Heu2+k1) = x;
* (P_Heu2+k1+1) = y;
Index_Coul= (uint16_t)Image_de_Fond[x +((int32_t) y *240)];
* (P_Heu2+k1+2) =Index_Coul>>8;
* (P_Heu2+k1+3) =Index_Coul & 0x00FF;
PutPixel(x,y,_Navy);
break;
default:
CPrint("Problem\r\n");
}
}
//--- simple - TESTs pointeurs ----
int main(void)
{
OSCCON1 = 0x60;
OSCCON3 = 0x00;
OSCEN = 0x00;
OSCFRQ = 0x08; // 0x08=>64Mhz
OSCTUNE = 0x00;
__delay_ms(100);
Hardware_Init();
for (i = 0; i<sizeof (TEXTE); i++) TEXTE[i] = 0;
txt = &TEXTE[0];
Compte_Octets = UART1_RX_BUFFER_SIZE - 1;
UART1_Init(); //115200 ou 921600 bds
CRLF1();
CPrint("\r\n Projet MPLABX IDE 6.30 : _18F47K42_Horloge_Analog_GC9A01_2026\r\n Version "VERSION"\r\n");
sprintf(txt, " Compile le %s a %s UTC\r\n version XC8 : %d et PACK %s\r\n et Optimisation Niveau 2\r\n", __DATE__, __TIME__, __XC8_VERSION, PACK);
Print(txt);
P_Trot = & Arriere_Plan[0];
P_Min = P_Trot + (Long_Troteuse<<2); // 4 bytes par pixel : x,y,couleur 16bits
P_Min1 = P_Min + (Long_Minute<<2);
P_Min2 = P_Min1 + (Long_Minute<<2);
P_Heu = P_Min2 + (Long_Minute<<2);
P_Heu1= P_Heu + (Long_Heure<<2);
P_Heu2= P_Heu1 + (Long_Heure<<2);
P_End= P_Heu2+ + (Long_Heure<<2);
sprintf (CRam1," Taille Arrie_plan = %5d 0x%4X \r\n",Taille_AR,Taille_AR );
Print(CRam1);
sprintf (CRam1," Arriere_Plan= 0x%04X\r\n",P_Trot );
Print(CRam1);
sprintf (CRam1," Minute = 0x%04X\r\n",P_Min);
Print(CRam1);
sprintf (CRam1," Heure = 0x%04X\r\n",P_Heu);
Print(CRam1);
sprintf (CRam1," End = 0x%04X\r\n",P_End);
Print(CRam1);
do
{}
while(1);
return 0;
}
.. à suivre ...
Montre analogique GC9A01
Bonsoir paulfjujo, et tout le forum,
Le langage C c'est bien car tout est inclus, mais il y a le revert de la médaille, car tu ne vas pas pouvoir manipuler certaines fonctions, ou récupérer
des données qui seraient essentiel pour cette horloge.
Je me suis décidé à écrire quelques lignes en ASM ce Wend-end. Mon horloge tourne, avec aiguille seconde, minute, heure.....
Mais bon c'est pas le plus difficille à faire, je me suis même pas posé la question comment faire...
Il n'y a aucun calcul à faire en ASM Pic, car j'ai écrit un petit programme sur PC en RapidQ pour calculer les positions. tout tient dans un tableau
120 octets
J'ai encore beaucoup de place dans le pic, car le fichier de Tom et Jerry est compressé, il fait 35526 octets pour une couleur RGB(565)
Les aiguilles sont dessinner avec l'algorithme de Bresenham, et là !! ça devient un avantage d'avoir fait cette fonction.
Je vais modifier la compression, elle sera faite par ligne d'écran de gauche à droite sur 240 pixels.
A+
paulfjujo a écrit :Source du message mais maintenant j'utilise plutot une vision asm ...
Le langage C c'est bien car tout est inclus, mais il y a le revert de la médaille, car tu ne vas pas pouvoir manipuler certaines fonctions, ou récupérer
des données qui seraient essentiel pour cette horloge.
Je me suis décidé à écrire quelques lignes en ASM ce Wend-end. Mon horloge tourne, avec aiguille seconde, minute, heure.....
Mais bon c'est pas le plus difficille à faire, je me suis même pas posé la question comment faire...
Il n'y a aucun calcul à faire en ASM Pic, car j'ai écrit un petit programme sur PC en RapidQ pour calculer les positions. tout tient dans un tableau
120 octets
J'ai encore beaucoup de place dans le pic, car le fichier de Tom et Jerry est compressé, il fait 35526 octets pour une couleur RGB(565)
Les aiguilles sont dessinner avec l'algorithme de Bresenham, et là !! ça devient un avantage d'avoir fait cette fonction.
Je vais modifier la compression, elle sera faite par ligne d'écran de gauche à droite sur 240 pixels.
Retourner vers « Généralités sur les PICs »
Qui est en ligne
Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 16 invités
