Utilisation de TcomportRésolu

Question

Bonjour &#224; tous,

Je suis nouveau sur le forum, et novice en POO... J'utilise Delphi 4.
Je souhaite utiliser Tcomport pour recevoir des trames de donn&#233;es binaires &#224; 9600 bauds. Elles sont &#233;mises par un microcontroleur. La trame fait toujours 10 octets, mais la cadence &#224; laquelle elles sont &#233;mises par le UC change (de 2 trames secondes &#224; 10 trames secondes). Il n'y a pas de contr&#244;le de flux, donc le UC envoie autoritairement ces trames de donn&#233;es binaires.
J'ai essay&#233; de les r&#233;cup&#233;rer &#224; l'aide de OnRxChar, avec Comport.read(data,1). Je lis donc mes octets un par un puis les visualise &#224; l'aide de Memo.text.

Ca marche &#224; peu pr&#232;s, mais j'ai rencontr&#233; les probl&#232;mes suivants:
- Si l'&#233;mission des trames s'interrompt, mon affichage de donn&#233;es s'interrompt aussi alors que le buffer contient encore une cinquantaine de data. Je m'en suis apper&#231;u en reprenant l'&#233;mission avec des trames de tests (donc diff&#233;rentes au niveau des datas), et les 50 (environ) premi&#232;res datas affich&#233;es correspondaient &#224; des anciennes donn&#233;es stock&#233;es dans le buffer.

- Si la trame est compos&#233; de la valeur 0 (en binaire et non pas le caract&#232;re), cette valeur ne semble pas vu par comport.Read. J'ai vu sur le forum qu'un autre d&#233;veloppeur a rencontr&#233; exactement le m&#234;me probl&#232;me. Il n'y a pas eu de solution propos&#233;, et il a contourn&#233; le probl&#232;me en g&#233;n&#233;rant des trames ASCII et non pas binaire. Dans mon application je ne peux pas modifier le format des trames de donn&#233;es re&#231;ues. Je suis donc condamn&#233; &#224; trouver une solution. 

Mes questions:
- Le composant TCOMPORT est il con&#231;u pour recevoir des donn&#233;es binaires? Si oui, y a-t-il un param&#233;trage &#224; effectuer pour l'informer d'interpr&#233;ter correctement une donn&#233;e re&#231;ue?
- Comment r&#233;soudre le traitement de la valeur 0 lors d'une r&#233;ception?
- Comment utiliser Tcomport pour que les datas re&#231;ues soient instantann&#233;ment lues au lieu d'&#234;tre stock&#233;e plus ou moins longtemps dans le buffer?
- Quelqu'un peut il me faire parvenir un programme fonctionnel complet pour Delphi 4 utilisant Tcomport pour recevoir des trames binaires sans contr&#244;le de flux afin que je comprenne bien toutes les subtilit&#233;s afin de ne pas perdre des donn&#233;es en cours de route, ou bloquer le programme &#224; cause d'une absence de Time-out? (Je le redis, je suis totalement novice POO).

Merci &#224; tous pour votre aide


 Christian

jlen100 · Accepted Answer

salut,

c'est pas un probl&#232;me de recevoir de donn&#233;es binaire avec Tcomport.

1ere chose quand tu utilises l'&#233;v&#232;ment OnRxChar utilises la variable
count pour lire l'ensemnble des donn&#233;es contenue dans le buffer faire
read (data,1) risque de te faire perdre des donn&#233;es (c'est du &#224; la
gestion des &#233;vent par Windows)

si ta trame fait toujours 10 octets le plus simple c'est de faire:



si tu lance un timeout externe;

timeout.enabled:=true;

while (Comport1.inputcount<10)and timeout.enabled do Application.ProcessMessages;//pour ne pas bloquer

if not timeout.enabled then // si le temps est d&#233;pass&#233;

begin

 showmessage('Erreur Communication')

exit; on sort sinon &#231;a plante

end;

comport1.read(data,10);//on re&#231;oit la totalit&#233; de la trame

ton data peut &#234;tre un record si tes donn&#233;es peuvent &#234;tre structur&#233;es;



personnellement je pr&#233;f&#232;re passer par un string m&#234;me pour des donn&#233;es
binaires; en effet dans ce cas Comport se moque &#233;perdument du type de
donn&#233;es qui sont re&#231;ues et on cr&#233;e un tableau dynamique dont chaque
caract&#232;re est un octet ensuite il suffit de transtyper pour r&#233;cuperer
les valeurs

par exemple si tu re&#231;ois une trame binaire constitu&#233;e :

d'un char+2 integer+un boolean

var 

    chaine:string;

    caractere:char

       val1,val2:integer;

     flag:boolean;

    valint:^integer

    valbool:^boolean;

begin

while Comport1.inputcount<10 do Application.ProcessMessages;//pour ne pas bloquer


comport1.readstr(chaine,10);//on re&#231;oit la totalit&#233; de la trame

caractere:=chaine[1];

valint:=@chaine[2];

val1:=valint^;

valint:=@chaine[6];


val2:=valint^;

valboolt:=@chaine[10];

flag:=valbool^;



@+

jlen

cs_CHARLI78 · Answer

Bonjour,
Merci  Jlen pour ta r&#233;ponse. Je vais essayer ta solution. As tu des infos concernant l'absence de d&#233;tection de la valeur 0 lors d'une r&#233;ception de donn&#233;es?

@+

 Christian

jlen100 · Answer

je n'ai jamais eu le probl&#232;me bien je communique en binaire avec des
microprocesseurs (les donn&#233;es que je re&#231;ois  n'ont pas toujours de
trames constantes en g&#233;n&#233;ral je formate au niveau du micropross ainsi:
type de donn&#233;es + donn&#233;es binaires et c'est &#224; la r&#233;ception que
j'interpr&#232;te dans certains cas pour diminuer la charge du CPU je passe
par un scanner(timer) et une doblebufferisation si cela t'interesse vas
voir ma source: pilotage 4 axes) tu trouveras dans la m&#233;thode scanner la fa&#231;on de faire



@+

jlen

cs_CHARLI78 · Answer

Merci encore pour ton aide. 


 Christian

cs_shining · Answer

il faut faire attention au piège du caratère 0, #0 ou chr(0) c'est la même chose c'est un caractère zero terminal, qui signifie la fin du fichier ou texte
tu peux faire un Test d'ailleurs !!!

TEdit.Text := 'Hello' + #0 + 'World' , seul Hello apparaîtra !!!

c'est notamment le cas dans un tableau de type Char 
si ton tableau est de type chaîne tu ne pourras plus lire les octets suivants le caractère #0 avec un Edit mais ça ne veut pas dire qu'il n'ya plus de données !!! 

pour y remedier utilises un Tableau de type Byte 
var
Buffer :array[0..512] of Byte;

on recoit l'évènement OnRxChar

on a alors le paramètre Count qui nous donne le nombres d'octets dans le tampon

dans ce cas on utilise ComPort.Read(Buffer , Count); en prenant le soin de vidé le tableau au préalable FillChar(Buffer , SizeOf(Buffer) , 0);
okay tu va me dire mais là on mets bien un #0 dans le Buffer, certes sauf que nous allons convertir ces données en Hexadécimal

var
S : String;
I : Integer;
begin
    S := '';
    for i := 0 to ComPort.InputCount -1 do
        S := S + IntToHex(Buffer[I] , 2) + ' '; <== l'espace pour avoir une meilleur lisibilité des trames mais pas obligatoire !!!
    TEdit1.Text := TRimRight(S);
   donc en cas de valeur "0" tu auras "00" en valeur de type chaîne tout en sachant qu'on règle général les micro-contrôleurs communiquent par blocs d'octets en 'Byte' et rarement en Char 'Ascii' telles les vieux modems dans le pire des cas tu pourra refaire la même manip sauf qu'au lieu de mettre 'IntToHex' tu peux mettre chr(Buffer[I]) pour avoir la valeur Ascii

jlen100 · Answer

salut shining;

dans le cas de Tcomport tu peux tr&#232;s recevoir un caractere #0 avec la
m&#233;thode ReadStr; il le rangera dans la chaine comme tout autre
caractere il ne termine la chaine que quand il a re&#231;u count caracteres
et peu importe leur valeur.

il suffit d'ailleurs de regarder les methodes de CPORT pour constater
que les m&#233;thodes read et readstr utilisent les m&#234;mes proc&#233;dures de
lecture



function TCustomComPort.Read(var Buffer; Count: Integer): Integer;

var

  AsyncPtr: PAsync;

begin

  InitAsync(AsyncPtr);

  try

    ReadAsync(Buffer, Count, AsyncPtr);

    Result :=  WaitForAsync(AsyncPtr);

  finally

    DoneAsync(AsyncPtr);

  end;

end;



// perform asynchronous read operation

function TCustomComPort. ReadStrAsync (var Str: string; Count: Integer; var AsyncPtr: PAsync): Integer;

begin

  SetLength(Str, Count);

  if Count > 0 then

    Result : = ReadAsync(Str[1], Count, AsyncPtr)

  else

    Result :=  0;

end;



// perform synchronous read operation

function TCustomComPort. ReadStr (var Str: string; Count: Integer): Integer;

var

  AsyncPtr: PAsync;

begin

  InitAsync(AsyncPtr);

  try

    ReadStrAsync(Str, Count, AsyncPtr);

    Result : = WaitForAsync(AsyncPtr);

    SetLength(Str, Result);

  finally

    DoneAsync(AsyncPtr);

  end;

end;

seule l'affectation des variables diff&#232;re --> variable typ&#233; dans un cas non typ&#233;e dans l'autre



on peut donc utiliser l'une ou l'autre des m&#233;thodes sans perte de
donn&#233;e les cas de read ne se justifie que quand on veut affecter
directement une variable.

l'avantage de readstr &#233;tant de garder une constante dans la lecture et
de pouvoir affecter &#224; posteriori les variables (definition d'un
proctocole plus souple avec lecture en bloc et traitement asynchrone en
batch) contrairement &#224; read qui impose de connaitre le type de variable
&#224; priori.



@+

jlen

cs_CHARLI78 · Answer

Bonjour,

Merci &#224; Shining et &#224; Jlen pour leur aide.  Tout cela me demande de prendre un peu de recul (car novice en POO). Je vais donc refaire des tests pour bien comprendre comment tout cela fonctionne en prenant en compte les conseils qui m'ont &#233;t&#233; donn&#233;s. Ca n'a pas l'air si simple que cela de recevoir des donn&#233;es binaire par le port s&#233;rie sous Windows...

@+


 Christian

jlen100 · Answer

le caractere #0 dans une chaineest surtout g&#232;nant &#224; l'affichage ou il
est consid&#233;r&#233; comme un 0 terminal ou quand affecte la chaine &#224; un
TCaption pour la m&#234;me raison

 maintenant 

si tu fais

var buffer:string;

begin

buffer:='Hello' + #0 + 'World';

edit1.Text:buffer;---->resultat 'Hello'

edit2.Text:=inttostr(length(buffer));---->'11' soit la totalit&#233; de 'Hello' + #0 + 'World';


edit3.Text:=inttostr(length(buffer));---->'5' soit seulement  'Hello'

end;

ceci demontre clairement que l'on peut utiliser un string pour
transmettre des donn&#233;es binaire : il se comporte comme un tableau
dynamique et c'est comme cela que je l'utilise; c'est quand m&#234;me plus
simple que de d&#233;clarer le tableau et de l' intialiser d'autant plus que
tu r&#233;cup&#232;res facilement le nombre de caract&#232;res re&#231;us en faisant
nombrecaracteres:=length(buffer); alors que dans le cas d'un tableau
type array[]of byte tu dois assigner une variable pour concerver cette
valeur.



@+

jlen

jlen100 · Answer

j'ai cliqu&#233; trop vite

 var buffer:string;

 begin

 buffer:='Hello' + #0 + 'World';

 edit1.Text:buffer;---->resultat 'Hello'

 edit2.Text:=inttostr(length(buffer));---->'11' soit la totalit&#233; de 'Hello' + #0 + 'World';

  edit3.Text:=inttostr(lengt( Edit2.Text));---->'5' soit seulement  'Hello'

 end;



@+

jlen

jlen100 · Answer

note aussi que je fais la m&#234;me chose pour envoyer mes trames sur le
port s&#233;rie, elles sont ainsi constitu&#233;es indiff&#233;remment de caract&#232;res
et de donn&#233;es binaires et pour la constituer il suffit de faire une
concat&#233;nation de l'ensemble par exemple cema peut &#234;tre: 

buffer:=commande+parametre1+parametre2+.....+parametreN+checksum;

buffer:=chr(length(buffer))+buffer; //ici on ajoute au d&#233;but le nombre
de carct&#232;res a recevoir; g&#233;n&#233;ralement je limite la trame &#224; 253
caract&#233;res et les parametres peuvent &#234;ter de tout types



@+

jlen

cs_CHARLI78 · Answer

Bonjour &#224; tous

Plus j'essaie d'avancer dans la compr&#233;hension du fonctionnement de Tcomport, plus je regresse. Je n'ai  toujours pas compris comment Tcomport g&#232;re la r&#233;ception des donn&#233;es sur le port s&#233;rie, ni comment faire pour r&#233;cup&#233;rer mes donn&#233;es. Plus j'avance et moins ca marche. (mon niveau en POO est toujours "d&#233;butant niveau -1".
J'ai bien vu qu'il faut saupoudrer un peu de "timeOut", peut &#234;tre un peu de "inputCount", que l'on peut lire ses data 1 par 1 ou par bloc de N, que l'on peut utiliser une m&#233;thode ou une autre pour r&#233;cup&#233;rer ses datas. Mais finalement quelle est la bonne m&#233;thode?

Faut- il commencer par vider le buffer, si oui comment
Faut - il lire &#224; intervale r&#233;gulier la pr&#233;sence de data dans le buffer &#224; l'aide d'un timer
Faut-il utiliser la m&#233;thode OnRxChar.

J'ai fait un petit programme tout simple avec l'instruction ReadByte (qui provient du livre' j'exploite les interface de mon PC sous Windows') qui s'interroge sous timer. Tout marche parfaitement. Il n'y a pas de donn&#233;es perdues, ni de donn&#233;es qui restent dans le buffer et la valeur 0 est correctement affich&#233;e &#224; l'&#233;cran. Mais avec Tcomport je n'arrive &#224; rien de satisfaisant.

Serait-il donc possible que quelqu'un me fournisse un exemple basic de r&#233;ception de donn&#233;es en continu par la liaison s&#233;rie g&#233;rant les probl&#232;mes de time out, de buffer etc... Cela me permettrait de d&#233;marrer d'une base fonctionnelle pour bien comprendre les m&#233;canismes de ce composant.

Merci encore


 Christian

jlen100 · Answer

salut;

si tu nous disais ce que tu veux faire exactement et comment tu traite tes donn&#233;es ensuite on pourrais t'aider un peu plus.

toutes les m&#233;thodes qu'on t'as donn&#233;e fonctionnent 

Utilser un timer ou le OnRxChar d&#233;pend surtout de la fa&#231;on dont tu traites les donn&#233;es ensuite

le OnRxChar permet de d&#233;clencher l'&#233;v&#232;nement sur un caract&#232;re de d&#233;but
de trame s'il ton d&#233;but de trame est constant c'est lui qu'il faut
utiliser en d&#233;finissant dans le concepteur le eventchar et en mettant
le EvRxChar &#224; true;

ensuite dans le OnRxChar



while comport1.inputcount<10 do begin end;

comport1.readstr(buffer,10);



le probleme que l'on peut rencontrer avec le OnRxChar c'est que si l'on
pas trait&#233; les donn&#233;e avant la trame suivante on perd des donn&#233;es



si tu utilises un timer par exemple toute les 200ms

en variable globale

var buffer:string;

procedure Form1.timer(Sender: TObject)

var buf:string;

 i:integer;

begin

    with comport1 do

    begin

         i:=inputcount;//on r&#233;cup&#232;re le nombre de caract&#232;re &#224; lire

       if i<>0 then  readstr(buf,i);//on lit les caract&#232;res

    end;

    buffer:=buffer+buf; on les ajoutes au buffer et l'on traite apr&#232;s

end;

ensuite tu traite tes donn&#233;es comme avec un tableau le premier
caract&#232;re &#233;tant &#224; la position 1 (buffer[1) et la derni&#232;re &#224;
length(buffer);

avec l'une de ces 2 m&#233;thodes tu devrais pouvoir t'en sortir.



@+

jlen

cs_CHARLI78 · Answer

Bonjour Jlen,
Merci pour ta r&#233;ponse. J'ai opt&#233; pour la premi&#232;re solution (attente de caract&#232;re). Ca marche &#224; un d&#233;tail pr&#234;t. Comme je te l'ai dit dans mon premier message, je cherche &#224; recevoir des trames de 10 octets binaires. Le d&#233;but de trame a une ent&#234;te de reconnaissance contante faite de 2 octets: 0AAH puis 055H. Les 8 autres octets ont des valeurs quelconques entre 00H et 0FFH.

Comme je n'ai pas r&#233;ussi &#224; me synchroniser sur mon d&#233;but de trame, je re&#231;ois bien mes 10 octets, mais &#224; cheval sur 2 trames.
Comment est il possible de param&#233;trer Tcomport pour me synchroniser sur le d&#233;but de trame. Le param&#233;trage de EventChar porte apparemment sur un char et non pas sur une valeur hexad&#233;cimale.
L'autre solution serait peut-&#234;tre d'utiliser le temps mort entre mort entre 2 trames cons&#233;cutives (mini 100 mS) pour synchroniser la r&#233;ception sur un d&#233;but de trame, mais je ne sais pas le programmer.

@+

 Christian

jlen100 · Answer

pour le caractere 0AAH c'est 170 en d&#233;cimal dans eventchar tu mets #170

 me probleme c'est omme tu re&#231;ois des valeurs binaire il est
probable que dans ta trame ru te retrouve avec un second couple de
valeur identique au d&#233;but de trame la difficult&#233; est surtout de
synchroniser ta trame au d&#233;part. En principe avec les micro controleurs
on leur envoie une commande de synchronisation qui permet d'&#234;tre sur
sur qu'on a bien un d&#233;but de trame  sinon tu ne sera jamais sur
d'avoir un d&#233;but de trame.

une solution consiste &#224; d&#233;tecter un d&#233;but de trame et d'attendre 
la  trame entiere+10caract&#232;re. tu v&#233;rifies que le 11eme 
caract&#232;re est bien un caract&#232;re de d&#233;but de trame si c'est le cas tu as
des chances d'&#234;tre synchrnis&#233;. sinon tu relance la procedure.

Tu peux am&#233;liorer cette pocedure en recevant plusieurs trames (entre 5
et dix)et en recherchant les d&#233;buts de trames jusqu'&#224; la fin du buffer
; si tu trouves bien l' occurence  au moins 4 fois avant la fin de
du buffer  tu peux consid&#233;rer &#234;tre synchronis&#233; il te suffit de
calculer la position de la derni&#232;re occurence d'attendre la fin de
cette trame et tu seras synchronis&#233;.



@+

jlen

cs_CHARLI78 · Answer

Ca y est je recois mes trames correctement synchronis&#233;es. Ce n'est pas du travail de pro, mais &#231;a fonctionne. Cela me permet d'avoir &#224; pr&#233;sent une base de travail fonctionnelle pour faire diff&#233;rents tests sur Tcomport.

Merci encore Jlen pour ton aide et ta patience.


 Christian

jlen100 · Answer

tu vois qu'on y arrive avec un peu de patiente et beaucoup de pers&#233;v&#233;rance

 aller bon courage pour la suite



@+

jlen

cs_shining · Answer

Dans le cas où ton tableau est de type Byte une autre méthode consiste à lire les 1er octets transmis

var
Buffer  : array[0..$FF] of Byte;
Header  : WORD;// soit 2 Octets
begin
     ...
    if ComPort.InputCount = 2 then
    begin
        ComPort.Read(Header , 2);   // lecture de 2 Octets
        Header := Header and $FFFF; 
        if Header = $55AA then
        begin
            while not(ComPort.inputCount=8)
            begin
               Application.ProcessMessages;
             // on fait rien on attend juste que le buffer se remplisse !!!          
            end; 
           if ComPort.Count = 8 then // on s'assure que le compte est bon !!
           begin
               FillChar(Buffer , SizeOf(Buffer) , 0);// on vide le buffer 
               Comport.Read(Buffer[0] , 8); // le Buffer[0] n'est pas vraiment obligatoire on peut très bien mettre Buffer tout simplement
           end;  
           // maintenant les données son stockées à partir de zero dans le Buffer, accessible comme suit Buffer[0]

en tout cas c'est comme ça que procéderait un micro-contrôleur
autre astuce encore étant données qu'un micro contrôleur est cadencé par son horloge interne il nécessite donc un certain delay entre chaque "octet" dans ce cas là juste à la reception de OnRxChar tu peux mettre 
Sleep(I1*I2)
I1 étant le nombre d'octets attendus !!!
I2 etant environs le temps que prend le cpu pour transmettre 1 Octet en principe 2 ms c'est suffisant

Donc dans ton cas ça fait 
Sleep(10*2), ainsi tu auras un bloc plus complet !! et tu évites de bouffer du CPU avec les "while InputCount" !!!

jlen100 · Answer

lire 2 octets puis les 8 autres apr&#232;s n'est pas tr&#232;s judicieux du point
de vue utilisation du cpu---> on r&#233;p&#232;te 2 fois la proc&#233;dure il vaut
mieux  la totalit&#233; des caract&#232;res avec inputcount et n'appeller
qu'une fois la proc&#233;dure read.



De m&#234;me read surchargeant obligatoirement le buffer par les caract&#232;res
re&#231;us et attendant que la totalit&#233; soit transmise il est inutile de
vider la buffer avant d'appeler la procedure tu peux donc supprimer :

            
FillChar(Buffer , SizeOf(Buffer) , 0);// on vide le buffer 

sans aucun risque

enfin il me semple que le sleep est bloquant et qu'ainsi  non
seulement il bouffe autant de CPU que while inputcount mais qu'en plus
il n'autorise pas l'ex&#233;cution des messages windows il vaut mieux
utiliser un timer et de ne r&#233;cuperer que les octets transmis mais dans
ce cas il faut g&#233;rer un pointeur (l'utilisation de while inputcount ou
lancer un read() avec un nombre de caracteres &#224; lire>nombre de
caract&#232;res re&#231;u dans un ontimer entraine une instabilit&#233; de windows :
de l'&#233;cran instable au d&#233;placement des fen&#234;tres au plantage complet de
l'appli voir de windows)



@+

jlen

cs_CHARLI78 · Answer

Bonjour,
Merci encore &#224; Jlen et &#224; Shining pour votre aide.  Mon niveau de d&#233;veloppeur ne me permet pas de rentrer dans des consid&#233;rations trop techniques. J'avais eu la m&#234;me id&#233;e que celle de Shining pour d&#233;tecter mon ent&#234;te de trame. Dans un premier temps &#231;a r&#233;pond &#224; mon cahier des charges, donc je vais continuer &#224; faire une lecture de 2 +8 octets.

@+


 Christian

jlen100 · Answer

si ta trame &#224; une structure constante tu peux d&#233;finir une variable:



trame: record

      header:word;

     variable1: integer; //ici tu mets tes variables correspondant au type dont tu as besoin

     variable2:integer;

end;

seule condition que la taille de trame soit sup&#233;rieure &#224; 10



une fois que tu as synchronis&#233; ta r&#233;ception tu peux faire

with comport1 do

begin

    while inputcount<10 do Application.ProcessMessages

    read(trame,10);//tu r&#233;cup&#232;res ta trame format&#233;e

end;

@+

jlen

Utilisation de Tcomport

22 réponses

Votre réponse

Discussions similaires