[paulfjujo]

mon entete bitmap tigre_16b.bmp

Code : Tout sélectionner


 Demande d'envoi Fichier Image BMP , valide 4sec
....
 Stop envoi YAT
Buffer : BMF 
 Entete BMP de 54 bytes
0> 0x42 0x4D 0x46 0xA0 0x00 0x00 0x00 0x00 
1> 0x00 0x00 0x46 0x00 0x00 0x00 0x38 0x00 
2> 0x00 0x00 0x80 0x00 0x00 0x00 0x60 0xFF 
3> 0xFF 0xFF 0x01 0x00 0x10 0x00 0x03 0x00 
4> 0x00 0x00 0x00 0xA0 0x00 0x00 0x12 0x0B 
5> 0x00 0x00 0x12 0x0B 0x00 0x00 0x00 0x00 
6> 0x00 0x00 0x00 0x00 

 HEADER :
 type 4D42
 Taille: 41030
 Headsize 70
 W=128 x H=-160
 plan=    1 
  bitsColor=   16
 ResolH: 2834 
 ResolV: 2834

bon, la messe est dite ,
modif en ligne 24bits -> 16bits
avec lecture entete bimap

[paulfjujo]

bonjour à tous ...


Test avec fichier d'essai BMP crée avec PSP5 BMP 24bits
transformé en BMP16b avec "C:\Program Files (x86)\DisplayModule\Image Converter\DisplayModule Image Converter.exe"
re-transformé ensuite en *.C toujours avec DisplayModule Image Converter.exe"
fichier renommé image_test_128x160_16.h
const uint8_t Image_128x160_RGB[40960]=
{ .... 40960 bytes
};

Resultat:
Problemo :
s'affiche PRESQUE OK avec Orientation =0
car la partie texte est penchée .. presque en Italique !

* coté config OLED :
void Init_CG9A01(void)
{
............
SendCmd(0x36); //GC9A01A_MADCTL); // 0x36H Memory Access Control
// Row address order Bottom to Top (When MY MADCTL B7=1)
// Column address order Right to Left (When MX MADCTL B6=1).
// Column address order Left to Right (When MX MADCTL B6=0).
// Normal Mode (When MADCTL MV B5=0)
// LCD Refresh Top to Bottom (When MADCTL ML B4=0)
// RGB-BGR Order RGB (When MADCTL BGR B3=0)
// LCD Horiz refresh order Left to Right(When MADCTL MH B2=0)
// ( MADCTL B1=0 B0=0)
// SendData(0b00001000); // 0x08 RGB et HAUT de l'ecran coté connecteur avec orientation=0
SendData(0x0C); // RGB et Column address order Right to left
............

apres modif affichage image en flash
test avec Image_test_16.bmp -> image_test_128x160_16.h ..40960 datas ...OK
ecriture bien droite !
encore un probleme d'intervalle et limites...pour setwindow

Code : Tout sélectionner


 C:\MPLABX_Projects\18F47K42_RTS_UART1_2026.X
 
  uint32_t DrawImageRGB(uint16_t x, uint16_t  y, const uint8_t * bitmap, uint16_t  w, uint16_t  h)
{
  uint16_t  j,x1,y1; 
  uint32_t taille , ImageSize;
  ImageSize=0;
  taille=(uint32_t)w*h; 
  taille=taille << 1;
  x1= x+w -1;                          <--- rajout -1  23/02/2026
  y1= y+ h-1;                          <--- rajout -1  23/02/2026
  SetWindow(x,y,x1,y1);
  SendCmd(0x2C);
  for (j=0;j<taille;j++)
  {
       SendData(Image_128x160_RGB[j]);
        ImageSize++;
  }   
   return (ImageSize);
}  
    
 main .............   
    
     Ecran_Noir();
     DrawRectangle(46,46,128+52,160+52,_Rouge ); // 0x001F=_Bleu);
     __delay_xSec(2);
    START_SMT1 
     // image crée avec PSP5 en 24bits 
    // transformée en 16bits avec Display Converter
    // tranformée en *.h    40960 bytes obtenu avec Display Converter BMP -> h
     L0=DrawImageRGB(48,48,Image_128x160_RGB,128,160) ; 
    STOP_SMT1 
    L1=SMT1_Measure; 
    L2=L1<<1;    // à 500Khz tick=2µS => multiplie par 2   , à 31,25KHz L1>>5 par 32
    sprintf(CRam1," %lu Bytes lus avec affichage Image_128x160_RGB en %lu uS  soit %3.3f sec.\r\n",L0,L2,(float)L2/1000000);
    Print(CRam1);
    CRLF1();
    __delay_xSec(3);

Display_module_Comparaison_image_24b_16b.jpg

nota: j'utilise XNVIEW pour pouvoir afficher un BMP 16 bits
PSP5 ne peut pas l'afficher , ni d'ailleurs transformer un 25b en 16b

image_test_128x160_16-bmp.zip

[paulfjujo]

bonjour,

une question à temps X

Comment rajouter CR LF sur l'envoi d'un string avec COMPOPRT Toolkit

mon application faisant autre chose que d'attendre un envoi de fichier
affiche entre autres 2 autres images 128x160 residentes , + acquisition BM280, date/heure RTC
j'utilise 2 modes de dialogue avec COMPORT
Choix avec l'etat d'une entree PIC
RA3=1 , je peux Faire une requete Demande d' envoi de fichier bmp
laisse 4 secondes pour cliquer sur l'envoi fichier sur COMPORT
RA3=0 je peux envoyer une commande quelconque au PIC
donc
- soit chargement de fichier , exclusivement avec via Send fichier
- soit dialogue operateur via Send texte (ex: modif en ligne de vitesse SPI ou vitesse UART ou mode Bavard )
dans une des fenetre SEND
or il me faut un CR ou CR LF en fin de texte , pour detecter/armer la capture par interruption RX UART

sur VBray terminal il suffit de rajouter
ex: BAV=2\0x0D\0X0A
ou simplement cocher la cas CR à coté de la fenetre d'envoi

Malgré l'Help du programme COMPORT , je n'ai pas trouvé comment inserer de l'hexadecimal ou un code ascii < 32
comme \r\n en fin de string (comme sur YAT!)

A priori YAT ne peut pas envoyer de fichier RAW
mais je l'utilise en parralele sur le TX UART1 , pour la qualité d'affichage Ecran
affichage trop cafouillis sur COMPORT...

Bref ,je n'ai pas encore trouvé le terminal ideal ..
VBRAY terminal
YAT Terminal
COMPORT
COOL terminal

[Temps-x]

Bonjour paulfjujo, et tout le forum,

Source du message Comment rajouter CR LF sur l'envoi d'un string avec COMPOPRT Toolkit

Mieux que la télé, voici en image

1.png

2.png

3.png

Suite à ta demande, j'ai cherché un peu, mais comme j'avais fouillé pas mal dessus le logiciel, je me suis dit que ça devait être là.

Ils font quand même de belles choses, les ruses, dommage qu'ils soient aussi stupides dans leur mentalité.

A+

[paulfjujo]

.... Mieux que la télé, voici en image
Suite à ta demande, j'ai cherché un peu, mais comme j'avais fouillé pas mal dessus le logiciel, je me suis dit que ça devait être là.

extra caché dans l'Expand
avec le libellé "Macro Usage", je n'ai meme pas regardé là ,
à croire que le champ reservé pour Send est considéré comme une macro ..
mais ça marche !

[paulfjujo]

A priori le rajout de CRLF dans Macro Usage "On send"
fait que si je charge une image BMP16 RGB565 de 240x240 --> 115200 bytes
l'image s'affiche à moitié et ce message apparait ..do you want to stop transmission ?

je reponds NON et la suite de l'image apparait

il y a une notion de limite à 65K dans la doc ....
mais alors pourquoi l'image s'affiche t-elle d'une seul tenant si je mais None (rein) à la place de CRLF

pas de probleme pour une image 128x160 -> 57600bytes < 65ko

Le CRLF donne t-il à penser que c'est un fichier Ascii et non un Raw (binaire)

COMPORT_limit_si_CRLF.jpg

[Temps-x]

Bonsoir paulfjujo, et tout le forum,

Après avoir étudié les API sur le port série, j'ai découvert plein de choses, et en réalité ça n'existe pas l'envoi du binaire, ou du nombre, par contre
le string existe bien dans l'API

Voici l'API qui envoie les données sur un port série en RapidQ, mais ça reste similaire en autre langage, j'ai contrôlé

Code : Tout sélectionner


 DECLARE FUNCTION WriteFile LIB "kernel32" ALIAS "WriteFile" (hFile AS LONG,lpBuffer AS STRING,nNumberOfBytesToWrite AS DWORD,_
  BYREF lpNumberOfBytesWritten AS DWORD,lpOverlapped AS OVERLAPPED) AS LONG                                                     

Ce qui nous donne

    lngStatus = WriteFile(Handle,strData,dwBytesToWrite,dwByesWritten,0&)

          lngStatus = si tout est ok, il renvoi un nombre plus grand que zéro

          Handle = numéro d'un fichier ouvert sur le disque dur, je ne sais pas ou il se trouve. 

          strData = donnée en format string

          dwBytesToWrite = longueur des données à écrire

          dwByesWritten = contrôle, mais en réalité on ne s'en sert pas
          


Comme le code ASCII contient 255 caractères, il détourne les fonctions

Exemple avec le numéro 65 ce qui nous donne chr$(65) qui correspond au A majuscule, c'est de même pour le
binaire, il y a une fonction qui s'occupe de le traduire en string

Le seule soucis, et il est de taille !! c'est dans la plupart des langages de haut niveau, il ne connaît pas le caractère zéro

L'API.... elle !!

elle sait le faire, elle peut envoyer un zéro, mais pas dans la plupart des langages évoluer...

Pour revenir à ton problème, là je crois que je peux pas faire grand chose, à part paché l'exécutable pour que ce message n'apparaisse plus, mais on rentre dans l'illégalité, parfois ça rend bien service de savoir le faire.


A+