SPI Hardware sur PIC18F27K42

[Temps-x]

Bonsoir paulfjujo,

Source du message je recherche donc un algo plus performant ,tout en restant rapide et sans usage de flottants..
voici ma fonction de Lecture et affichage fichier BMP

Ça t'intéresse en ASM ? Ça sera sûrement plus rapide quand C

Je me suis aperçu de quelque chose il y a quelques jours, le pixel de mon écran d'ordinateur n'a pas la même valeur qui est lue dans le fichier BMP

Ça n'a pas vraiment d'importance, car la conversion fonctionne très bien, et de plus le rendu est meilleur sur mon petit écran SPI, qu'un fichier transformer BMP 24 bits vers RG565 par le programme ASM

Attention, au début de la lecture, c'est important, car le décallage d'un pixel va changer ta couleur, j'ai testé

A+

[paulfjujo]

bonsoir,

ma lecture directe de fichier BMP 24bits est maintenant OK ... (appli 18F47K42 XC8 )
un BMP16 s'affiche de haut en bas , un BMP24 de bas en haut

avec YAT configuré en Binaire pour TX et string en RX
YAT :config buffer par defaut inp 4096 bytes et out 2048 bytes..il est recommandé de ne pas les modifier
ça marche aussi ,mais reste moins rapide qu'avec COM Port Toolkits, mais l'avantage est un affichage coté RX ..en forme et donc tres lisible
contrairement à COMport

resultats avec SPI à 32Mhz UART à 921600 bauds

avec YAT:

image 16bits residente en flash
DrawImageRGB(60,60,Image_128x160,128,160);
affichage Image_128x160_RGB en 148508 uS soit 0.149 sec.

Coccinelle_240x240x16b.bmp
s'affiche de haut en bas
Chargement du BMP en 4158732 uS, soit 4.159 sec.

Cocinella_240x240x24b.bmp
s'affiche de bas en haut
Chargement du BMP en 6176178 uS, soit 6.176 sec.

voltmetre_240x240x24b.bmp
s'affiche de bas en haut
Chargement du BMP en 6765376 uS, soit 6.765 sec.

altimetre_240x240x24b.bmp
s'affiche de bas en haut
Chargement du BMP en 6555626 uS, soit 6.556 sec.

avec COMPORT Toolkit 4.0 ( à 921600bds):

C:\MPLABX_Projects\18F47K42_RTS_UART1_2026.X\voltmetre_240x240_24b.bmp
Chargement du BMP en 2459528 uS, soit 2.460 sec.

C:\MPLABX_Projects\18F47K42_RTS_UART1_2026.X\airspeed_240x240x24b.bmp
.. Chargement du BMP en 2433940 uS, soit 2.434 sec.

C:\MPLABX_Projects\18F47K42_RTS_UART1_2026.X\Coccinella_240x240_24b.bmp
000094;18:31:44.806 Fin de lecture fichier *.bmp.. Recu 172798 bytes RGB565
.. Chargement du BMP en 2627302 uS, soit 2.627 sec

C:\MPLABX_Projects\18F47K42_RTS_UART1_2026.X\Coccinelle_240x240x16.bmp
.. Fin de lecture fichier *.bmp.. Recu 115200 bytes RGB565..
Chargement du BMP en 1480690 uS, soit 1.481 sec.

Chargement du BMP en 526252 uS, soit 0.526 sec.
C:\MPLABX_Projects\18F47K42_RTS_UART1_2026.X\Tigre_16.bmp

fichiers BMP pour ces tests :

BMP_for_tests.zip

Lien sur vidéo

je vais donc maintenant rattacher la partie SDCARD ...
pour y stocker les fichiers BMP envoyés .

detail et source sur ma page web

à suivre sur un autre post ..

[Temps-x]

Bonsoir paulfjujo,

J'ai acheté le même écran que toi à 2.50 euros, Je vais le tester...

Pour info

Actuellement avec mon petit écran spi, je peux lire un fichier Bmp 24 bits, fichier Bmp 16 bits, fichier hex, et j'ai rajouté le fichier Wav à 11025 Bytes/Sec pour 11025 Hz, mono qui passe très bien à 115200 bauds, pas besoin de delay entre chaque octet, fréquence Pwm 86800 Hz comme ça pas besoin de filtre, branchement direct sur petit ampli pc

pour ton résultat

A+

[gwion]

2,50€ ?
Je crois que je me suis fait avoir les gars...

2026-03-14 19_11_50-Apple 27_ LED - Studio Display - Verre standard - Inclinaison - Ecran PC - Garan.png

[Temps-x]

Bonsoir gwion,

Le prix c'est 2.69 euros, mais j'ai payé en réalité 2.21 euros, regarde à droite y il y a le prix que j'ai payé réellement, c'est l'avantage de choisir le jour où les prix sont bas, avec 6 commandes groupé (port gratuit) et 2 euros de réduction.

Prix.jpg

C'est la journée où AliExpress a fait une grosse réduction sur tous ses produits. J'en ai profité maintenant, il faut voir s'il fonctionne bien, verdict ce soir vers les 2 heures du matin.

A+

[venom]

Bonjour à tous. Bon j'ai reçu mes pics et l'écran. Va falloir que je trouve un peu de temps pour réaliser un montage sur breadboard Et testé vos codes / programmes






@++

[Temps-x]

Bonjour venom,

Voila queque photo sur mon écran rond, c'est le même que paulfjujo,

Tom.jpg

Lion.jpg

Cocinelle.jpg

Je crois bien qu'il ne supporte pas les grandes vitesses, ce qui expliquerait le prix, je vais le tester avec COM Port Toolkit 4.0, je mettrais le résultat
ici.

Bon celui-là tu sais qui sait....

Gérard.jpg

A+

[Gérard]

C'est bien ma moustache.
Temps-x

[paulfjujo]

bonjour TempsX et à tous,


Avec quoi prends-tu les photos de ton ecran ?
car elles sont super nettes et reflettent bien la qualité grafique de ce OLED GC9A1
Rappel: Affichage Coccinella_240x240_24b.bmp
avec YAT 921600bds ... Chargement du BMP en 3305368 uS, soit 3.305 sec.
avec COM PORT 921600bds ... Chargement du BMP en 2535996 uS soit 2.535 sec
COM PORT toolkit est plus rapide , mais moins convivial au niveau
de l'affichage reception en Ascii (msg envoyés par le PIC)


Quid de l'animation des aiguilles ?
ouvrir un post specifique sur ce sujet ?
et image de fond en FLASH ..car ne tient pas en RAM



ci dessous avec un fond de clock dessiné en RAM
sans fioritures( ni chiffres des heures)

Code : Tout sélectionner



void  Draw_Clock_Face(void)
{     int i=0;

      //  Ecran_Noir();    // <- le plus rapide   1,1sec
      // Draw 12 lines
      for ( i = 0; i < 360; i =i+30)
       {
        sx = cos((i - 90) * Grade);
        sy = sin((i - 90) * Grade);
        xx0 = sx * 114 + 120;
        yy0 = sy * 114 + 140;
        xx1 = sx * 100 + 120;
        yy1 = sy * 100 + 140;

        Draw_Line(xx0, yy0, xx1, yy1, COLOR_GREEN);
      }

      // Draw 60 dots
      for (i = 0; i < 360; i += 6)
       {
        sx = cos((i - 90) * Grade);
        sy = sin((i - 90) * Grade);
        xx0 = sx * 102 + 120;
        yy0 = sy * 102 + 140;
        // Draw minute markers
       Put_Pixel(xx0, yy0, COLOR_WHITE);

        // Draw main quadrant dots
        if (i == 0 || i == 180) FillCircle(xx0, yy0, 4, COLOR_WHITE);
        if (i == 90 || i == 270) FillCircle(xx0, yy0, 4, COLOR_WHITE);
      }

      FillCircle(120, 141, 3, COLOR_WHITE);
      // Pre-compute hand degrees, x & y coords for a fast screen update
      sdeg = xz;  // rtc.getSecond() * 6;                // 0-59 -> 0-354
      mdeg = xz/60; //rtc.getMinute() * 6 + sdeg * Pas_Seconde; // 0-59 -> 0-360 - includes seconds
      hdeg = xz/360; //rtc.getHour() * 30 + mdeg * Pas_Heure; // 0-11 -> 0-360 - includes minutes and seconds
      hx = cos((hdeg - 90) * Grade);
      hy = sin((hdeg - 90) * Grade);
      mx = cos((mdeg - 90) * Grade);
      my = sin((mdeg - 90) * Grade);
      sx = cos((sdeg - 90) * Grade);
      sy = sin((sdeg - 90) * Grade);

     // if (rtc.getSecond() == 0 || initial) {
       if (xz % 60== 0 )
       {
       // initial = 0;
        // Erase hour and minute hand positions every minute
        Draw_Line(ohx, ohy, 120, 141, COLOR_BLACK);
        ohx = hx * 62 + 121;
        ohy = hy * 62 + 141;
        Draw_Line(omx, omy, 120, 141, COLOR_BLACK);
        omx = mx * 84 + 120;
        omy = my * 84 + 141;
      }

      // Redraw new hand positions, hour and minute hands not erased here to avoid flicker
      Draw_Line(osx, osy, 120, 141, COLOR_BLACK);
      osx = sx * 90 + 121;
      osy = sy * 90 + 141;
      Draw_Line(osx, osy, 120, 141, COLOR_RED);
      Draw_Line(ohx, ohy, 120, 141, COLOR_WHITE);
      Draw_Line(omx, omy, 120, 141, COLOR_WHITE);
      Draw_Line(osx, osy, 120, 141, COLOR_RED);

      FillCircle(120, 141, 4, COLOR_RED);
      //img.pushSprite(0, 0);
      // lastsec = xz;   //rtc.getSecond();

  }
  
  
     CPrint(" Simule Montre : Draw_Clock_Face()\r\n");
     Clear_LCD();
     xz=0;
     do
     {
     Draw_Clock_Face();
     Delay_ms(100);
     xz++;
     }
     while(xz<360);
     Delay_xSec(5);
   
  sur ce simple test, l'ecran est entierment redessiné !
  l'aiguille n'etant pas gérée via un sprite ..   
 ni pilotée par la RTC  
  
  



[Temps-x]

Bonjour paulfjujo, Gérard, et tout le forum,

Source du message Avec quoi prends-tu les photos de ton ecran ?

Avec mon téléphone portable.

J'envoie les photos avec mon programme que j'ai écrit en RapidQ, il faut compter en général 10 secondes à 500 000 bauds

Ce qui donne ceci en terme de temps pour la cocinelle 6,719 secondes

Envoyer.jpg

La vitesse d'envoi sera améliorée par la suite, mais pour l'instant ce n'est pas une de mes priorités, car je sais d'ou ça vient si ça va pas plus vite.

Source du message e crois bien qu'il ne supporte pas les grandes vitesses, ce qui expliquerait le prix, je vais le tester avec COM Port Toolkit 4.0, je mettrais le résultat ici.

Fin de compte l'écran fonctionne bien à grande vitesse, c'est la vitesse SPI qui n'arrive pas à suivre par rapport au données Usart quand on tourne à 500 000 bauds, le pic de paulfjujo est plus rapide que celui que j'utilise, pour l'instant je reste à 250 000 bauds ou 115200 bauds quand je veux écouter de la musique

Source du message Quid de l'animation des aiguilles ?

Oui je réfléchis à cela.... je ne pense pas que les mathématiques sont la solution

Source du message ouvrir un post specifique sur ce sujet ?

Le post tu veux l'ouvrir en C ou ASM ou en terain neutre

Dans cette histoire d'écran rond, il y a encore un fauve, on va finir par y rester...

A+