[Temps-x]

Bonsoir paulfjujo, francois77, et tout le forum,

Apparemment ses écrans on une définition de 240x240 pixels, et d'après ce que j'ai compris 1 pixel peut avoir une couleur RGB(16 bits).

Ce qui nous fait 57600 pixels, et ce bien ça ?

pour cette essai réussi...

A+

[paulfjujo]

Bonsoir paulfjujo, francois77, et tout le forum,

Ce qui nous fait 57600 pixels, et ce bien ça ?

oui , 240x240 = 57600 pixels , mais necessite x 2 (16 bits couleurs) => ecriture de 115200 bytes pour effacer l'ecran !
ce qui peut expliquer cette lenteur d'effacement en SPI bit bang 1,47MHz

Code : Tout sélectionner

 
(0.000) sur YAT terminal, show time stamp activé !
(0.000) Debut du test 1 duree de 100 000 SendCmd encadré de 2 CRLF 
(0.000) 
(1.092) 
(0.000) .fin du test 1
(0.049) 
(0.000) 
(0.000) Debut du test 2  Ecran_Noir() 

1,092 sec / 100 000 => SendCmd en 10.92µS
effacement d'ecran en
115200x10,92 /1000 000=> 1,25 sec + quelques µS


code généré

Code : Tout sélectionner

;PIC18F27K42_UART1_ADC_SPI_LCD_Rond_CGA9A01_2023-0313.c,1383 ::         for (L1=0;L1<100000;L1++)    SendCmd(0);
0x61A4    0x0100          MOVLB       0
0x61A6    0x6B79          CLRF        _L1, 1
0x61A8    0x6B7A          CLRF        _L1+1, 1
0x61AA    0x6B7B          CLRF        _L1+2, 1
0x61AC    0x6B7C          CLRF        _L1+3, 1
L_main299:
0x61AE    0x0E00          MOVLW       0
0x61B0    0x5D7C          SUBWF       _L1+3, 0, 1
0x61B2    0xE108          BNZ         L__main534
0x61B4    0x0E01          MOVLW       1
0x61B6    0x5D7B          SUBWF       _L1+2, 0, 1
0x61B8    0xE105          BNZ         L__main534
0x61BA    0x0E86          MOVLW       134
0x61BC    0x5D7A          SUBWF       _L1+1, 0, 1
0x61BE    0xE102          BNZ         L__main534
0x61C0    0x0EA0          MOVLW       160
0x61C2    0x5D79          SUBWF       _L1, 0, 1
L__main534:
0x61C4    0xE20C          BC          L_main300
0x61C6    0x010C          MOVLB       12
0x61C8    0x6BC3          CLRF        FARG_SendCmd_value, 1
0x61CA    0xF004EC5C      CALL        _SendCmd, 0
0x61CE    0x0E01          MOVLW       1
0x61D0    0x0100          MOVLB       0
0x61D2    0x2779          ADDWF       _L1, 1, 1
0x61D4    0x0E00          MOVLW       0
0x61D6    0x237A          ADDWFC      _L1+1, 1, 1
0x61D8    0x237B          ADDWFC      _L1+2, 1, 1
0x61DA    0x237C          ADDWFC      _L1+3, 1, 1
0x61DC    0xD7E8          BRA         L_main299
L_main300:
;PIC18F27K42_UART1_ADC_SPI_LCD_Rond_CGA9A01_2023-0313.c,1384 ::         CRLF1();
0x61DE    0xF010EC60      CALL        _CRLF1, 0


_SendCmd:
;tft_gc9a01_spi_2023.c,132 ::         void SendCmd(unsigned char value)
;tft_gc9a01_spi_2023.c,134 ::         cx=value;
0x08B8    0xF003CCC3      MOVFF       FARG_SendCmd_value, R3
;tft_gc9a01_spi_2023.c,135 ::         _DC=0;
0x08BC    0x94BB          BCF         LATB, 2 
;tft_gc9a01_spi_2023.c,136 ::         for(i=0;i<8;i++)
0x08BE    0x6A02          CLRF        R2 
L_SendCmd5:
0x08C0    0x0E08          MOVLW       8
0x08C2    0x5C02          SUBWF       R2, 0 
0x08C4    0xE20F          BC          L_SendCmd6
;tft_gc9a01_spi_2023.c,137 ::         {   if((cx&0x80)==0x80)
0x08C6    0x0E80          MOVLW       128
0x08C8    0x1403          ANDWF       R3, 0 
0x08CA    0x6E01          MOVWF       R1 
0x08CC    0x5001          MOVF        R1, 0 
0x08CE    0x0A80          XORLW       128
0x08D0    0xE102          BNZ         L_SendCmd8
;tft_gc9a01_spi_2023.c,138 ::         _MOSI=1;
0x08D2    0x88BB          BSF         LATB, 4 
0x08D4    0xD001          BRA         L_SendCmd9
L_SendCmd8:
;tft_gc9a01_spi_2023.c,140 ::         _MOSI=0;
0x08D6    0x98BB          BCF         LATB, 4 
L_SendCmd9:
;tft_gc9a01_spi_2023.c,141 ::         _CLOCK=1; _CLOCK=0;
0x08D8    0x86BB          BSF         LATB, 3 
0x08DA    0x96BB          BCF         LATB, 3 
;tft_gc9a01_spi_2023.c,142 ::         cx=cx<<1;
0x08DC    0x3603          RLCF        R3, 1 
0x08DE    0x9003          BCF         R3, 0 
;tft_gc9a01_spi_2023.c,136 ::         for(i=0;i<8;i++)
0x08E0    0x2A02          INCF        R2, 1 
;tft_gc9a01_spi_2023.c,143 ::         }
0x08E2    0xD7EE          BRA         L_SendCmd5
L_SendCmd6:
;tft_gc9a01_spi_2023.c,144 ::         }
L_end_SendCmd:
0x08E4    0x0012          RETURN      0
; end of _SendCmd




surement plus long qu'en ASM 100%

[francois77]

Bonjour Paul, Temps-x et tout le forum

Je viens de regarder le temps d'effacement de l'écran en ASM en simulation 670ms

La solution pour un effacement complet plus rapide serait de ne traiter que les pixels visibles

Rectangle = E 240 * 240 = 57600

Cercle = 120*120*3.14 = 45216

on devrait arriver a gagner environ 20% a la louche pour un effacement complet de l'écran

Bof 20%

A+

Francois

[paulfjujo]

.....

Cercle = 120*120*3.14 = 45216

on devrait arriver a gagner environ 20% a la louche pour un effacement complet de l'écran
...

sauf qu'il faut plus de calculs pour acceder à cette zone de cercle..

Code : Tout sélectionner

(0.048)  Clear_LCD()
(1.123) 
(0.000) Debut du test  : 10 fois  Rectangle Noir
(0.031) 
(12.856) 
(0.000) .fin du test 
(0.000) 
(0.000) Debut du test  : 10 fois Cercle Noir r=120 
(0.050) 
(45.868)
(0.000) .fin du test

soit 1,28sec pour rectangle 0,239,0,239,couleur
et 4,58 sec pour Cercle 120,120,120,couleur

nota :
le chronometrage de YAT terminal est à +-50mS près ( 1 tic timming PC)
(solution la plus simpliste)
c'est pourquoi je fais au moins une dizaine de boucle pour le chrono.
il faut un CRLF, retour à ligne pour que le chrono s'affiche sur le terminal

l'usage de SMT1 en chronometre serait precis à +-62,5nS !

[francois77]

Paul,

On doit pouvoir effacer plus rapidement l'écran en mode "rectangle" par zone pour refaire un cercle

j'ai mis un petit dessin

Capture.PNG

Ma solution était uniquement pour la raz de l'écran :langue:

Pour le reste pas de magie

A+
francois

[paulfjujo]

Paul,

On doit pouvoir effacer plus rapidement l'écran en mode "rectangle" par zone pour refaire un cercle

j'ai mis un petit dessin


Capture.PNG



Ma solution était uniquement pour la raz de l'écran

Pour le reste pas de magie

A+
francois

je suis d'accord avec toi, en ce qui concerne le nombre de pixels à couvrir,
qui globalement est moindre..
mais tu vas perdre beaucoup de temps ( sans X) a redéfinir les zones de chaque sous-rectangles
avec setwindow(x1,y1,x2,y2);
pour moi ce n'est pas rentable ..
à moins de me démonter le contraire .. avec X

[paulfjujo]

Le 18F27K42 avec 128K de Flash
peut stocker cette image BMP 220x232 65Kcouleurs , sans besoin de carte SD ou Eeprom externe
au prix de limitation partie code et surtout sans les 8 fontes en ROM !

l'image est dans un fichier Lady_bug_.h
de 240 lignes de 240 valeurs ( mots de 16 bits = couleur RGB)
J'ai du decouper le fichier image en 2 parties
1ere partie 0 à 119 .... 57600 bytes
2em partie 120 à 232 .. ... 53760 bytes
car MC n'accepte que modulo 64Kbytes datas en Flash
et reduire la 2em partie de 8 lignes
..car on a quand meme besoin de place pour le code programme !

GC9A01_BMP_65Kc_Lady_Bug_test_220_Lignes_2023-0314.jpg

le fichier compilé ... SPI et cdes .. taille 345Ko

PIC18F27K42_OLED_GC9A01_SPI_Bit_Bang_Image_65Kc_MC_2023-03.zip

sur port B

[paulfjujo]

cette fois , AVEC MES IMAGES ...
pas facile de transformer une image quelconque en BMP 16 Bits RGB 565 !
la plupart des logiciels PSP , XnView .... traitent les BMP en 8 ou 24 bits ...sans passer par le format 16Bits
j'ai trouvé ceci :
http://www.pixfonter.net/bitmap-convert ... brary.html
LCD Bitmap Converter for Microchip Library v2.0
BMC4MLA_Setup.exe

pour modifier 2 images airspeed et voltmetre
de jpg à BMP
le programme cree un fichier au format C

j'ai recupéré uniquement la partie data
file datas organisé en lignes de 16 bytes
1 ligne = 240x2=480 bytes
240 lignes = 480*240=> 115200 bytes
8 lignes de 240 pixels = 480*8= 3840 bytes

pour rester modulo 64Ko maxi
j'ai coupé le fichier en 2 parties de 56700 bytes
Problemos :
la premiere partie data affiche la partie basse de l'image !
Attention : direction bas-> haut!!
Attention : SetOrientation(2) Portrait\r\n"); ou Paysage (orientation=1)suivant l'image ...
Attention : il faut inverser aussi MSB et LSB ! pour respecter les couleurs !

* Attention
Au besoin , il faudra eventuellement supprimer quelques lignes d'affichage,
pour récuperer de la place dans la Flash pour la partie programme ..

j'ai mis une compilation conditionnelle pour ne conserver que l'affichage BMP
et donc le minimum d'application programme => le maxima de Flash dispo
et là, le BMP de 115200 bytes rentre facile dans les 128K flash du 18F27K42
vu que j'ai (, via statistic MikroC)
Flash Rom Usage = 125268 bytes 95,6% reste 4,4 % dispo soit 5802 bytes
RAM Used 595 btes soit 7.3% reste 5165 bytes + heap =2410 bytes

La manip n'est donc pas tres aisée ... mais faisable

les 2 fichier include image dans le zip
image originale : Airspeed realisé en image de synthese Povray+Moray (C)PF

GC9A01_AirSpeed_240x240a.jpg

voltmetre , trouvé aux puces de LEYMENT 01

GC9A01_Voltmetre_240x240.jpg

_LCD_GC9A01_SPI_Base_BMP_18F27K42.zip

nota : les photos sont en deça de la qualité réelle obtenue ..
super cet écran !

[francois77]

Bonjour Paul,

Il te resta a faire varier l'aiguille de ton Galva.

Bravo

A+

Francois

[Temps-x]

Bonsoir paulfjujo, francois77, et tout le forum,

Source du message oui , 240x240 = 57600 pixels , mais necessite x 2 (16 bits couleurs) => ecriture de 115200 bytes pour effacer l'ecran !
ce qui peut expliquer cette lenteur d'effacement en SPI bit bang 1,47MHz

pour l'information sur le nombre de pixel et la couleur, je m'en doutais un peu mais je voulais être sur car j'écris un petit programme pour qu'en puisse s'amusait un peu, ça plaira à francois77.

Maintenant que je sais à quelle vitesse tourne le SPI Big Bang, il est est donc plus rapide qu'un Pic18F26K22 configurer avec ses registres qui sont prévus pour cela.

pour cette démonstration réussi et de bonne qualité... merci aussi pour le lien du soft, ainsi que tes fichier en C

Bon comme dit françois77 faut les faire bouger ses aiguilles,

Les aiguilles c'est comme les jambes, ils sont fait pour qu'ils puisses bouger.

A+