Animations graphiques avec Cortex-M3

[invite8699d527]

Bonjour à tous, ça fait un ou deux ans que je programme des PICs et il y a peu de temps j'ai acheté une petite carte à base d'ARM Cortex-M3, une vraie petite merveille! J'ai déjà commencé à faire joujou avec (du simple clignotement de DEL au système d'exploitation temps réel).Voilà pour la petite histoire.

On va dire que je me débrouille pas mal en programmation (je suis loin d'être un pro faut pas pousser non plus) mais j'ai jamais fait de programmation avec écran LCD graphique et je me demandais s'il y avait des techniques pour éviter de perdre trop de temps à réactualiser à chaque fois l'écran et pour arriver à faire des animations fluides. Sur le lien que j'ai donné, il y a une vidéo de démo (c'est le programme pré installé sur la carte) et par exemple, à 2m40, on voit un bête compteur de vitesse avec l'aiguille qui est devant la jauge et derrière le texte et on a pas l'impression qu'il y ait d'effacement de l'écran.

Donc voilà, est-ce que quelqu'un s'est déjà attelé à des choses dans le genre et aurait des conseils à me donner pour réaliser des animations fluides sans trop de complexité?

Merci d'avance à tous ceux qui participeront à ce sujet!
-----

[invite8699d527]

ya personne?

[Forhorse]

Pas moi desolé... Même si c'est vrai que j'aimerais bien savoir faire ça ! (mais vu le temps que je met a finaliser un projet avec un LCD alpanumerique, pour un LCD graphique couleur il me faudrait 10 ans par projet !)

[invite8699d527]

C'est pas grave, merci quand même!

Bon j'ai fait quelques tests et il s'avère que j'arrive à afficher 58 images par secondes (fond uni de couleur différente à chaque fois) ce qui est déjà plutôt sympa. Mais, parce que il y a un mais, j'ai voulu afficher une vraie photo à l'écran stockée sur une carte micro-SD et le problème, c'est qu'une image non compressée de 320x240 avec les couleurs sur 16bits ça prend un peu moins de 156ko et que du coup ça rentre pas dans la ram (qui fait 48Ko)... Pour parvenir à mes fins, je charge l'image progressivement mais le problème c'est que l'affichage n'est pas instantané et on voit un peu l'image se dérouler.

Du coup j'ai deux questions. Est-il possible de charger l'image dans la mémoire flash? car vu qu'elle fait 256Ko ça rentre. Sinon, existe-t-il une librairie pour traiter des images compressées (jpg par exemple) afin de réduire suffisement la taille pour les charger directement dans la ram?

[A voir en vidéo sur Futura]

[invitef26bdcba]

Salut,

Avec un bête PIC24H, j'arrive sans problème à 10 images secondes(320*240 16b/p) format BMP. Les données sont envoyées en deux fois, l'interface 16bit n'étant pas nécessaire vu la vitesse SPI...
La limitation étant simplement la SPI, le µC disposant encore de marche de manoeuvre côte CPU...

Donc, avec un µC à 90MIPS, ton problème doit être ailleurs...

David.

[invite8699d527]

Merci de ta réponse, c'est encourageant! Sur ma carte c'est pas par liaison SPI que ça se passe mais via un périphérique intégré (SDIO : Secure digital input/output interface) qui est fait exprès pour ça donc je ne pense pas que le problème vienne de lui.

Pourrais tu m'expliquer un peu comment tu procèdes pour le transfert de tes données? Ça se gère comment le BMP?

Personnellement, je récupère 2 octets, je les traite et j'affiche le pixel correspondant, puis je re récupère 2 octets et ainsi de suite. J'ai essayé de récupéré des paquets de 10 ou 100 octets d'un coup et de les traiter après mais ça a pas changé grand chose (c'était pas visible en tout cas)

[invitef26bdcba]

Si vraiment ta carte utilise le protocole SDIO, c'est encore plus rapide que la SPI...

Le BMP se gère très simplement, c'est juste un tableau de pixel avec la couleur du pixel codée sur 16bits (codage que tu as choisi). Pas de traitement nécessaire de la donnée, tu la lis et tu l'expédies...
http://www.daubnet.com/en/file-format-bmp

Oui, je fais aussi du traitement à la volée, lecture du pixel -> affichage du pixel.
Pas de tampon entre, La SPI est plus lente que l'affichage du pixel.

David.

[invite29971eb1]

Euh, je crois que vous parlez de choses différentes.

DavidDB parle du protocole vers l'écran et Blacksword du protocole carte SD. Enfin, c'est ce que j'en comprends.

A côté de ça, le contrôleur de LCD dispose d'une interface SPI et d'un bus de donnée 16 bits, autant dire que ça devrait poutrer grave

Tu gères par interruption tes échanges?
Si tu gères ça au fil de l'eau, en attendant la fin des transmissions dans ton programme principal, ça peut expliquer que ça rame. Du fait de la présence des périphériques, ton Cortex peut très bien lire la carte SD, écrire sur l'écran et traiter les données en même temps.

A un niveau simple, ça se fait par une gestion intelligente des interruptions et de buffers d'émission et de réception.

A un niveau plus complexe, le DMA te permettra de booster encore les perfs.

[invitef26bdcba]

Salut,

Pour moi, la SPI(SDIO) c'est pour lire la SDcard, et le port// 8bits(16bits) pour écrire vers le TFT...

Maintenant, si le TFT se gère aussi en SPI, c'est possible que cela traine pour l'affichage, mais à lire le post#4, avec plus de 50 rafraichissement/seconde, je penche pour un branchement par le port// du TFT.

Je ne pense pas que le DMA soit une véritable solution, il libère juste du temps CPU pour laisser travailler le SDIO et le PORT//(si géré effectivement en DMA)

David.

[invite8699d527]

Effectivement, pour l'écran c'est avec le FSMC (Flexible static memory controller) que c'est géré donc c'est du // 16bits. Ça doit être ma façon de gérer les choses qui fait ramer car oui j'attends effectivement de recevoir mes deux octets avant de les traiter puis d'afficher le pixel.

Est-il plus simple de gérer les interruptions ou d'utiliser un RTOS? (j'ai freeRTOS sous la main que je sais faire marcher)

Après le DMA c'est sûr que c'est pas mal mais je sais pas vraiment comment ça marche (je connais simplement le principe).

A titre informatif, je vous met mon code qui gère la réception des données et de leurs affichage (j'utilise FatFS pour accéder à la carte).

	
res = f_open( &fsrc , "0:/photo.raw" , FA_OPEN_EXISTING | FA_READ);	 //ouvre le fichier

    if ( res == FR_OK ) {    //si l'ouverture du fichier s'est bien passée
		
		LCD_SetCursor(0,0);                    //place le curseur en haut à gauche de l'écran
  		LCD_WriteRAM_Prepare();                //Prépare le futur affichage
  		for(x=0;x<76800;x++) {                //boucle pour passer les 320x240 pixels
			f_read(&fsrc, buf, 2, &br);   //lecture de 2 octets
			pix = buf[0]<<8 | buf[1];    //conversion des 2 octets en couleur 16 bits 
     		        LCD_RAM = pix;               //affichage du pixel
   		} 

      f_close(&fsrc);        //fermeture du fichier
    }

J'aurai aussi pu utiliser la fonction LCD_SetPoint(X,Y,Couleur), le code est plus simple (pas de set_cursor ni de writeram_prepare) mais au final ça prend plus de temps et il faut faire 2 boucles

[invite8699d527]

petit up du soir