SPI Hardware sur PIC18F27K42

[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
          


Le code ASCII va de 0 à 255 caractères. le zéro compte comme caractère, mais il ne possède pas de caractère

Tu crois utiliser un chiffre, ou chaîne binaire, ils n'ont rien en réalité...

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... En ASM, vu que c'est un langage de bas niveau, il sait le faire


Pour revenir à ton problème, là !! je crois que je ne peux pas faire grand chose, à part Patcher 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+

[paulfjujo]

bonjour,


Bonjour à tous,

sur COMPORT Toolkit
si on a coché la case RAW
n'importe quelle valeur (0 à 255) peut etre envoyée SANS interpretation
donc y compris le 00

Pour moi un string est une chaine de caracteres
qui sera donc interpretée principalemet comme de l'ascii
et comporte un 0 (\0) Terminateur de string..
dans ce cas une valeur nulle termine,coupe la chaine
contrairement au RAW.

Or si j'active rajout de CR LF en fin d'envoi
CR et LF sont des caracteres speciaux ,specifiquement utilisé
dans un string (chaine de caractere), et cela doit interferer avec le choix RAW data.

Dans la doc :
HEX data type Unlimited number of messages (depended on system resources), every message < 64Kb
String data type One message < 64Kb < 64K ....mais 115200 bytes en 2 fois avec message d'alerte intermediaire
Send raw data One message < 64Kb < 64K ... mais 115200b en 1 seule fois (sans le rajout de CR LF à la fin)
le fichier de 115200 bytes passe bien en 1 seule fois,sans message d'alerte

Raw data ABC = binaire pur 01000001,01000010,01000011
HEX data ABC representation du byte en hexadecimal xx (00 à FF) 414243
string "ABC\0" en ascii -> en decimal 65666700 ou en hexa 41h42h43h00h

L'interpretation d'une RAW data est tres subjective,
car depend uniquement de comment le programmeur veut la visualiser sur un ecran
et sous quel format il la traite.

cette notion de raw data ou string est tres piégeuse lorqu'on veut afficher
un texte sur un LCD (ou autre)
ex LCD de 24 car/ligne
on dispose d'un tableau de 24 bytes Message[24]
si on y range 1 par 1 les caracteres ..no problemo
si on veut envoyer une chaine de 24 caracteres, il ne faudra pas oublier
de dimensionner le tableau Message[25] pour y loger le \0 terminateur
Message[25]=0; ..sous peine d'aleas ou plantage programme.


nota : meme en C on peut envoyer un zero -> \0 pour delimiter un string

Remarques :
nota : xc8 est tres ( , trop) rigoureux sur le format specifié pour 1 byte
char
unsigned char
int8_t
uint8_t
sans oublier l'usage dans les structures ou union..

le programmeur ne peut plus faire ce qu'il veut ,sans generer des tonnes de warning
c'est pourtant le programmeur qui sait comment il veut traiter la data 8 bits
et ce n'est pas au compilo d'imposer son format ..
la designation de Byte permettait au moins de laisser un choix libre et universel au programmeur.
On est dans un monde de contrainte et normalisation qui va detruire l'innovation .

En ASM , on fait (ou faisait ! ) effectivement ce que l'on veut ! mais risky sans ceinture de securité !
La derniere version de compilateur MPLAB ASM se barde de normalisation !
..et avec l'IA qui va s'en meler

[Temps-x]

Bonsoir paulfjujo, et tout le forum,

Le problème de Windows, c'est qu'il fonctionne avec un débugueur en arrière-plan.

Le débugueur contrôle tout ce que tu peux faire, et quand tu ne fais pas ce qu'il faut, un message d'erreur s'affiche sur ton écran.

Même en utilisant ASM, on peut pas en sortir, à moins d'utiliser une API qui te le permette, ça existe ils ont prévu ça

Source du message nota : meme en C on peut envoyer un zero -> \0 pour delimiter un string

C'est vrai, j'ai pu lire dans certains forums que le C++ permet cela, en RapidQ tu ne peux pas rajouter la chaîne 0 dans une variable$ , et sur bien autres langages évolué aussi, c'est bien pour cela que j'ai spécifié certains langages.

Sous Dos on faisait ce qu'on veut.... il est bien loin ce temps-là !!

Tout est une histoire de Temps

A+