SPI Hardware sur PIC18F27K42

[Temps-x]

Bonjour paulfjujo, et tout le forum,

Source du message ne image en jpg et aussi le fichier correspondant en hexadecimal (du texte ascii, assimilable en C)

En quelle dimension pour ton image ?

Quelle sens de bayage ?

A+

[Temps-x]

Bonjour paulfjujo, et tout le forum,

J'ai fait plusieurs tests en envoyant une image par l'usart sur mon écran SPI, elle met 41 secondes pour un affichage complet.

Même avec une augmentation de la vitesse de l'usant, le temps reste constant, pour l'affichage (41 secondes)

Si s'affiche l'image stockée en mémoire programme sans l'usart, elle met 1 seconde.

J'utilise SPI Sofware qui est au maximum de sa vitesse, mon écran a une dimension de (128x160) 16 bits de couleurs (2 octets),
ce qui nous fait 40960 octets à envoyer pour affichage d'une image complète

As-tu déjà testé l'envoi d'une image sur l'usart pour un affichage d'une image sur un écran SPI seulement avec un Pic, sans aucune aide d'autre composant.

Si oui, combien de temps met-elle à s'afficher ?


A+

[venom]

Bonjour J'ai fait plusieurs tests en envoyant une image par l'usart sur mon écran SPI, elle met 41 secondes pour un affichage complet.
A+

41 seconde... Merci pour l'info. Je me demandais justement le temps d'envoi

Mais quand tu l'envoies tu la stock en mémoire ou l'image s'affiche au fur et à mesure sur ton écran ?

Quel serait le moyen d'améliorer le temps ? J'imagine stocker toutes les images dans de la mémoire a l'avance pour par exemple faire des menus graphique etc... ?






@++

[paulfjujo]

bonjour à tous,




Nota: je ne me sert pas de la liaison UART pour charger l'image
elle est stockée directement en Flash code (fichier ascii Daffy_Duck_Bmp.h)

Conditions d' usage avec void Init_SPI1(void)
et UART à 460800bds

avec le code necessaire à l'I2C2 , RTC, BMP280 et les fontes grafiques
je n'ai plus la place de mettre de grandes images ....(115Ko)
mais ton image de 40960 k pourrait peut etre rentrer ?
car actuellement j'ai
Program space used D688h ( 54920) of 20000h bytes ( 41.9%)
Data space used 1092h ( 4242) of 2000h bytes ( 51.8%)
peux-tu partager ton fichier en forrmat ascii *.H ou en *.BMP par defaut

J'utilise donc actuellement une petite image de 120x120 N&B seulement
avec chrono entre les 2 CRLF1 via YAT terminal
et ce code:

Code : Tout sélectionner

   
    Ecran_Noir();  
    CPrint("\r\n  Affichage Daffy_Duck_BMP 120x120\r\n");
    CRLF1();
    DrawBitMap(60,60,duck_120_bitmap,120,120,_Blanc) ;
    CRLF1();
    CPrint(" ..fin Affichage Image Daffy \r\n"); 

Test SPI à 32MHz
(11:23:05.316) Affichage Daffy_Duck_BMP 120x120 ......en 591mS
(11:23:05.344)
(11:23:05.935)
(11:23:05.935) ..fin Affichage Image Daffy
(11:23:05.952)

Test SPI à 8MHz
(11:29:45.302) Affichage Daffy_Duck_BMP 120x120 ..........en 730mS
(11:29:45.302)
(11:29:46.032)
(11:29:46.032) ..fin Affichage Image Daffy


Test avec 10 commandes successives Ecran_Noir
BAUD=3 => SPI 8MHz
(14:51:20.008) Mesure durée 10 x Ecran Noir -> 2,3 sec
(14:51:20.051)
(14:51:22.350)

BAUD=0 => SPI 32MHz
(17:00:45.114) Mesure durée 10 x Ecran Noir 1.46 sec
(17:00:45.136)
(17:00:46.595)


j'ai rajouté la possibilité de modifier en ligne ,la vitesse SPI en BAUD

Code : Tout sélectionner

 
 dans traitement dialogue operateur via YAT terminal
   // BAUD SPI 
      if((*(p1)=='B') && (*(p1+1)=='A') && (*(p1+2)=='U')& (*(p1+3)=='D') & (*(p1+4)=='=')  )
      {
       cx= *(p1+5);
       if (   ( cx < '8')  && (cx >47) )   // 0 à 7
       {   SPI1CON0bits.EN = 0; 
           cx= *(p1+5); 
           SPI1BAUD =(cx-48); 
           CPrint("\r\nNew SPI1 BAUD="); PrintChar(cx);CRLF1();
           SPI1CON0bits.EN = 1; // SPI Module is enabled
       }
       CRLF1();
       p1=0;
      }   
      
   dans l'init SPI
   SPI1CLK = 0x00;     // SPI Clock Source Fosc (64MHz)
    // CLKSEL<3:0>: SPI Clock Source Selection bits
    // 0101 = TMR2_Postscaled     //0100 = TMR0_overflow
    //0011 = CLKREF     //0010 = MFINTOSC     //0001 = HFINTOSC     //0000 = FOSC
    //SPI1BAUD = 31;      // SPI Clock = 64MHz / (2*(31+1)) = 1MHz;
    //SPI1BAUD = 15;      // SPI Clock = 64MHz / (2*(15+1)) = 2MHz;
    
    //SPI1BAUD = 7;      // SPI Clock = 64MHz / (2*(BAUD+1)) = 4MHz;
    //SPI1BAUD = 3;      // SPI Clock = 64MHz / (2*(3+1)) = 8MHz;
    //SPI1BAUD = 1;      // SPI Clock = 64MHz / (2*(1+1)) = 16MHz;
    SPI1BAUD = 0;   // 32 Mhz   
           
      


==============================================
un autre exemple testé sur autre application OLED :

******************
coté spi à 32Mhz
*******************
Optimisation chargement image ,
via l'usage de pointeurs .
et un peu plus de code utilisé ...
23/03/2023
(14:22:04.791) Test Duree de Chargement image Voltmetre.bmp
(14:22
(14:04.981) Stop. SMT1=3074432 ,soit 192152 uS ..............192mS

nota:
image affichée en 2 paquets de 57600 bytes
et chaque paquet de 57600
en 16 fois 16 bytes

nota : l'image Volmetre.bmp de 115200 bytes est stockée en 2 parties en flash code ,
ATTENTION : la partie code programme restante est limitée à 128 - 115= 13Ko SEULEMENT !

calculs theoriques :
SPI à 32Mhz
1 byte transmis à 3.2Mhz soit 0.03125µS
115200 bytes * 0.03125 => 3600 µS => 3.6mS
mais avec le contexte encadrant l'envoi effectif d'un byte SPI
+ les boucles
+ lecture data en Flash
=> ..192mS reelement obtenu



coté UART
exemple à 115200 bds 11520 bytes / seconde
image de 240x240 RGB 65Kcouleurs = 57600bytes*2 => 115200 bytes
duree teheorique de transfer 115200/11520 = 10 sec
pour ton image de 40960 bytes => 3.55 sec minima
mais à 460800 bds => 0.880sec => 880mS
en supposant un flux continu debit à 100% utile
mais il faut rajouter les durees de transferts vers memoire ou vers sortie SPI


On voit donc que la vitesse UART et/ou SPI ne pese qu'en partie sur le resultat global
meme avec unPIC à 64MHz ..mais 16 Mhz utile (car cycle=FOSC/4)


Questions :
* Quel protocole liaison serie utilises-tu pour le chargement du fichier ?
pour la lecture de fichier Wav via le terminal j'utilisais RTS/CTS pour
regler le flux de transfert ...et UART à 460800bds

* envoi au SPI au fil de l'eau ?
ou par paquets stockées en RAM ?


Je ne pars pas sur la solution UART pour charger une image
vu que je choisis la solution Carte SD ...
pour pouvoir garder 8 fontes caracteres ne flash pour l'OLED GC9A01
et le reste concernant I2C2 ..
..SDC ...à suivre

ou avec l'option DMA .. à potasser !
---< UART --> DMA --> SPI ?


remarque :
meme mon LCD OPEN SMART SERIAL mets
jusqu'à 4 Sec. pour l'affichage complet d'une image 320x240
(stockée sur SDCARD)

[Temps-x]

Bonjour paulfjujo, venom, et tout le forum,

Source du message Mais quand tu l'envoies tu la stock en mémoire ou l'image s'affiche au fur et à mesure sur ton écran ?

Elle apparaît progressivement sur mon écran, et je trouve le temps de boire un café.

Source du message Quel serait le moyen d'améliorer le temps ?

Ne pas l'écrire en C, car le programme serait plus volumineux, et plus lent


Il faut que je trouve un terminal où je peux envoyer un fichier image en format hexadécimal, j'ai comme un gros doute sur le port serie et le
tampon utilisé par l'orinateur.

Source du message J'imagine stocker toutes les images dans de la mémoire a l'avance pour par exemple faire des menus graphique

Stocker des images, en mémoire programme, ou en RAM, ou eprom, pas possible, pas assez de place, par contre on peut stocker des petits bouts d'images, pour faire par exemple un bouton, et les afficher à un endroit précis de l'écran.

Source du message Questions :
* Quel protocole liaison serie utilises-tu pour le chargement du fichier ?
pour la lecture de fichier Wav via le terminal j'utilisais RTS/CTS pour
regler le flux de transfert ...et UART à 460800bds

* envoi au SPI au fil de l'eau ?
ou par paquets stockées en RAM ?

Je mets l'image dans mon programme, puis je la traduis en décimal et je l'envoie sur l'émulateur du port USB-SERIAL CH340

La vitesse de mon port série est de 38400 Bauds, soit 3800 octets par seconde, le fichier à envoyer a une taille de 40960 octets, il devrait y avoir un temps d'affichage d'à peu près de 10 secondes, ce n'est pas le cas...

Pour un fichier *.Wav je mettais ça en mémoire programme, et j'utilisais un Pic18F27K42 qui a 128k de mémoire programme

Actuellement j'utilise le Pic18F26K22 qui a une mémoire programme de 64k, s'y loge une image de 40960 octets, qui met moins d'une
seconde à s'afficher.

Le problémme n'est pas dans le code ASM, qui reste plus rapide que le C n'y le spi

Je soupçonne l'usart, pas du côté Pic, mais du côté ordinateur qui attend que le tampon du pic soit vide pour y déposer la donnée.

Je vais faire des essai demain.

J'ai essayé de mettre les données par paquet d'une ligne écran, soit 256 octets en Ram, je gagne rien du tout.

Je te joins 2 images en hexadécimal 128x160 et une autre 320x240, normalement je les ai traduites pour qu'elles soient compatibles en C, il faut juste regarder la fin du fichier car je crois qu'il faut retirer un caractère.

Fichier joint : ICI


A+

[venom]

pour toutes ses précisions Temps-X

Pas la peine de préciser qu'en ASM tu ira toujours plus vite qu'en C

Ça doit être drôle de voir l'image s'afficher au fur et a mesure. Un peut comme un chargement (un poil long j'avoue )

Donc le souci du timing viendrait de l'UART côté ordi

Dès qu'on manipule des fichiers la mémoire devient vite saturé







@++

[paulfjujo]

bonjour à tous,

Je soupçonne l'usart, pas du côté Pic, mais du côté ordinateur qui attend que le tampon du pic soit vide pour y déposer la donnée.

coté PC voir le parametrage COM et le nombre et taille buffers utilisés (de 1 à 16 x 4096)


il faut bien retirer les datas reçues dans le PIC pour que le PC puisse en envoyer de nouvelles...
La vitesse de recuperation doit etre egale ou superieure à celle de l'envoi ..
sinon ça ne sert à rien de monter la vitesse de transmission..

Question : tu geres la reception en mode pooling ou interruption ?

le mode interruption est tres reactif ,mais utilise plus d'instructions MCU
en mode pooling il faut au minimum gerer le flux
via CTS et RTS

MAIS ...sur mon programmateur d' AT29C501 Atmel via un 18F26K22 ,
pour charger le fichier code via VBRAY terminal.
j'avais abandonné CTS/RTS pour utiliser finalement le protocole XON-XOFF
envoi par paquets de 16 bytes..
TXREG1=XON autorise l'envoi,
TXREG1=XOFF bloque l'envoi.
avec :
#define XOFF 19
#define XON 17
Reception trame de 16 bytes

SQA_Event_coding.jpg

Decouper le fichier d'envoi par paquets (modulo 256 bytes,voir plus ) me semble etre une bonne solution pour
ne pas engorger la reception coté PIC ..
avec un buffer RAM correspondant ...
l'usage CTS/RTS ou XON /XOFF permettant de scinder le flux.

je ferais un test avec ton fichier image ..

[Temps-x]

Bonjour paulfjujo, venom, et tout le forum,

Source du message Donc le souci du timing viendrait de l'UART côté ordi

Ou des modules chinois, reste à voir, soulagement pour ceux qui ecrivent en langage C la rapidité n'est pas le problème

Avant toutes choses : les essais qui sont faits sur la rapidité d'envoi de données ne sont pas connectés au microcontrôleur, ils sont faits à vide.

Et ben !! c'est bien du côté PC qu'il faut chercher, ou les modules chinois USB-SERIAL, CH340 FT232RL

J'ai les deux modèles et je constate que j'ai le même résultat (40 secondes) par contre, quand je me sers d'un vrai port Rs232, la vitesse est 4 fois plus rapide

10 secondes au lieu de 40 secondes, à voir avec un autre système d'exploitation, je vais faire un essai sous Windows 7, car je suis sous Windows XP.

Les émulateurs des ports série ont encore des progrès à faire, et c'est bien pour cela que je ne les aime pas

Source du message coté PC voir le parametrage COM et le nombre et taille buffers utilisés (de 1 à 16 x 4096)

Avant d'envoyer les données, je vide le buffer, et je lui alloue 65536 octets, vu que mon fichier fait 40960 octets, ça devrait loger largement.

Source du message Question : tu geres la reception en mode pooling ou interruption ?

Actuellement en mode interruption, dans les 2 cas ça n'a rien changé, et de toutes façons, comme expliqué ci-dessus, le problème vient du PC ou des
Modules chinois.

Dans tous les cas, le problème est maintenant ciblé, j'ai pu cas faire des recherches dessus.

A+

[venom]

Après oui ses modules chinois reste de l'émulation... C'est peut être dû à ça ?!






@++

[paulfjujo]

.....
Avant d'envoyer les données, je vide le buffer, et je lui alloue 65536 octets, vu que mon fichier fait 40960 octets, ça devrait loger largement.
...

buffer coté PIC ...OK
mais je parle de buffer ..... coté PC

exemple mon port COM 9 Virtuel sur YAT terminal habituellement à 9600bds par defaut ,
mais qui reste ok à 460200 bds

Ton PC XP a ses limites ...
meme mon vieux PC actuel , en WIN10 , qui date de 2013 !

Config_Port_COM9_Virtuel_Gestion_periph_WIN10.jpg

au fait, peux tu poster l'original de ton image 120x160 en *.BMP

avec le ficher TAB resultant
et dans quel sens sens explores-tu le fichier
de gauche à droite et en descendant d'une ligne
0 à 127
128 à 255
...etc ..

un truc m'interpelle
image de 120x160 => 19200 pixels
65Kcolors => 19200 x2 = 38400 bytes

.. pourquoi
un fichier de 2560 lignes de 16 bytes= 40960 bytes ?