[Débutant] Lenteur avec TComPort

**PhDt76** · 20/09/2003, 00h56

Bonjour,

Pour dialoguer avec un systeme externe (mC), via le port série, nous utilisons le composant TComPort.

Le principe du protocole de dialogue est un mirroir (chaque octet envoyé est retourné par le mC et nous devons attendre le retour pour envoyer l'octet suivant).

Nous traitons le dialogue dans l'evènement OnRxChar où nous recevons 1 octet et envoyons immédiatement le suivant ce qui a pour effet d'alimenter constament le dialogue.
Configuration du port : 19200 bauds, 8 bits, pas de parité et 1 bit de stop.

Problème :
Avec cette methode nous mettons 3 ms à renvoyer un caratère après en avoir reçu 1,(Mesures faites à l'oscilloscope) et nous avons l'assurance que le mC réagit immédiatement.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
 
//------------------------------------------------------------------------------
void __fastcall TForm1::Envoi (__int8 *Octet)
{
        ComPort1->Write(Octet,1);
}
//------------------------------------------------------------------------------
void __fastcall TForm1::Recoit(__int8 *Octet)
{
        Form1->ComPort1->Read(Octet,1);
}
//------------------------------------------------------------------------------
void __fastcall TForm1::ComPort1RxChar(TObject *Sender, int Count)
{
        char Octet;
 
        while(ComPort1->InputCount()!=0);
        {
                Recoit(&Octet);
                switch (Dialogue.Type)
                {
                case 1:
                        switch (Dialogue.Octet)
                        {
                        case 1:  //Reception N° Esclave
                                Dialogue.Octet=2;
                                Envoi (&Dialogue.Type);
                                break;
 
                        case 2:  //Reception Type de dialogue
                                Dialogue.Octet=3;
                                break;
 
                        case 3:  //Reception de l'octet d'état
                                Dialogue.Octet=4;
                                Canton[Dialogue.Esclave].Etat=Octet;
                                Envoi(&Octet);
                                break;
 
                        case 4:  //Reception N° Esclave (Acquittement)
                                Dialogue.Octet=1;
                                Dialogue.Esclave=RechercheCantonSuivant(Dialogue.Esclave);
                                Octet=Dialogue.Esclave|0x80;
                                Envoi(&Octet); //Relance du dialogue suivant
                                break;
                        }
                        break;
 
                case 2:
                break;
 
                case 3:
                break;
 
                case 4:
                break;
                }
        }
}

Comment pourrait-on améliorer le programme pour ne pas perdre ces 3 ms qui sont trop pénalisantes pour notre système?

Nous vous remercions d'avance pour l'intérêt que vous voudrez bien porter à ce post et pour les solutions que vous pourrez y apporter.

PhDt

mat.M · 20/09/2003, 12h08

Comment pourrait-on améliorer le programme pour ne pas perdre ces 3 ms qui sont trop pénalisantes pour notre système?

Si vous recherchez vraiment les performances , il va falloir investir dans de la recherche et développement

Première méthode qui ne coûte pas vraiment grand chose.
Avoir recours à un thread pour l'envoi/réception de données avc la classe TThread. Voir dans l'aide de C++ Builder sinon il ya un exemple d'utilisation des TThread sur le CD d'installation ( sinon peut-être qu'ici sur developpez.com aussi )
L'avantage de l'utilisation d'un thread est qu'on puisse lui attribuer une priorité plus élevée qu'à un autre processus.
Donc l'OS accorde plus de tranches CPU/système qu'un autre programme

outrepasser le composant tout fait.
Le problème avec les composants tout-fait c'est que si on est pointilleux sur les performances ( ce qui est le cas ici ) on arrive vite à leurs limites ...
Donc développer éventuellement un Device Driver personnalisé avec le DDK car un Device Driver est exécuté dans une couche en-dessous de l'OS ou utiliser des API bas-niveau.

Ou sinon......prendre un autre OS

car un temps de réponse 1ms à atteindre avec MS Windows je sais pas si c'est toujours faisable.
Peut-être Windows XP Embedded , Linux, QNX ?????......

**Greybird** · 20/09/2003, 12h44

Bonjour,

Pour le thread, le composant TComPort est déjà basé sur un thread. Donc je ne penses pas que ce soit le point à mettre en oeuvre.

Cordialement,

Arnaud

**DjmSoftware** · 20/09/2003, 20h55

Salut
est tu bien sur de tes mesures
à 19200 Bauds ,le temps moyen de transmission d'un caractère dans ston cas de figure est de 9* (1/19200) = ~'0.5ms
le temps de transmission doit donc être de 2 fois cette valeur
ton programme ou composant prendrait donc 2 ms pour le traitement
cela me paraît beaucoup

place dans ton code des appels à GetTickCount() pour voir ou le programme
prend un maximum de temps

tu peux les placer par exemple dans l'apppel à Envoi et Recoit
et créer une méthode appelée avec un PostMessage qui de calcule le temps entre les 2 appel donce entre l'émission et la réception du caaractère

Cordialement

mat.M · 20/09/2003, 21h41

Merci à Arnaud pour la précision ( concernant l'utilisation des threads)

En complément à l'utilisation de GetTickCount proposée par DjmSoftware,
l'utilisation d'un "profiler" ne serait peut-être pas superflue...

**PhDt76** · 20/09/2003, 23h35

Bonjour à tous et un grand merçi pour vos réponses,

Avant toute chose, je dois vous dire que le projet que nous développons doit gérer en temps reel des mobiles qui sont détectés par des cartes munies de mC (Au total 100 cartes soit 100 esclaves reliés à un PC maître par la liaison série).

Je vais essayer de faire le point de nos recherches suite au post de mat.M.

1) les Thread
Nous avons essayé de donner une priorité supérieure au dialogue de 3 façons:

1.1) TComPort implémant lui-même des thread, nous avons essayé de donner en priorité supérieure aux thread du composant en utilisant
ComPort1->EventThreadPriority=tpTimeCritical;

1.2) Nous avons créer un thread (Priority tpTimeCritical) utilisant le TComPort

1.3) Nous avons aussi créer un thread sans le TComPort mais un HANDLE en utilisant CreateFile(...),ReadFile(...),WriteFile(...)

Pour ces 3 méthodes, les mesures à l'ossilloscope sont les mêmes, nous constatons le temps de réponse de 3ms ce qui tend donner raison à la remarque de Greybird.

2)Changer d'OS
Le projet que nous développons fonctionne actuellement sous DOS et je dois dire qu'effectivement nous avons du travailler (détournement et reecriture de la fonction d'interrution).

Les mesures faites sous DOS font apparaitre un temps de réponse de 0,8ms maxi compte tenu de la précision de notre appareil de mesure ce qui s'approche de la théorie exposée par DjmSoftware mais le constat est que nous passons quasiment 4 fois plus de temps dans les dialogues.
Cette lenteur ne semble pas due à TComPort mais à windows.

En fait nous souhaitons passer sous windows pour moderniser l'interface utilisateur et surtout pour bénéficier une exploitation en réseau.

3)Ecrire un driver spécifique
C'est une solution tentante mais là nous sommes un peu court ...
Un petit coup de pouce nous serait utile pour démarrer.

Merçi encore à tous, ce forum est une reelle mine d'or pour nous.

PhDt

**gandf** · 21/09/2003, 22h49

N'est ce pas plutôt un problème avec les "timeouts".
C'est les temps entre les lectures écritures. Pour plus de renseignement, regarder l'aide du composant et il y a quelques spécialiste de comport sur le forum.
Il n'y a aucun problème de rapidité avec ce composant sous windows normalement s'il est bien paramètré.

**PhDt76** · 21/09/2003, 23h38

Bonjour,

Merçi pour ta réponse gandf, nous allons chercher.
Mais ce qui m'étonne, c'est qu'avec des ReadFile et des WriteFile, nous obtenons exactement les mêmes résultats.

Cordialement,

PhDt

**gandf** · 21/09/2003, 23h47

Parce qu'il y a aussi moyen de les changer ces timeouts mais je ne sais pas faire sans le composant. Mon prof d'élec m'avait vaguement expliqué il y a quelques années mais je n'ai rien compris.

**PhDt76** · 21/09/2003, 23h58

Dans le composant TComPort, il y a des timeouts
-ReadInterval
-ReadTotalConstant
-ReadTotalMultiplier
-WriteTotalConstant
-WriteTotalMultiplier

J'ai essayé de faire des changement mais cela n'as rien changé.

Cordialement,

PhDt

**gandf** · 22/09/2003, 00h12

Il faut pas faire n'importe quoi sinon ça ne marche pas. Il faut lire la doc (qui est en anglais) pour comprendre à quoi ça sert. Ne met pas tout à 0.

**Bayard** · 22/09/2003, 10h16

Quel est le processeur du PC ?

Quelle est sa fréquence ?

Quel est l'OS ?

Est-ce que le code est compilé avec les directives de compilation "rapides"
avec les symboles ?

Cordaielement

**PhDt76** · 22/09/2003, 12h40

Bonjour,

nous avons essayé l'exe sur un P2 et un Athlon 2000+. Les deux machines tournent sur W2k Pro.
Côté RS232, c'est la même chose.

Quant aux directives de compilation, nous sommes dédutants et nous n'y avons pas touché. Si tu connais un tuto merçi de nous poster un lien.

Cordialement,

PhDt

**gandf** · 22/09/2003, 13h00

http://www.gandfweb.net/logiciels.htm

source de RS232Monitor.
Le programme de fonctionne pas bien mais on peut changer les timeouts (ils ont des valeurs par défaut).
Je l'ai fait quand j'apprenai à programmer et il n'est pas très bien écrit.

**DjmSoftware** · 22/09/2003, 13h56

Hello,
pour faire suite
je ne suis toujours pas convaincu que ce soit windows qui ralentissse ton application
pour l'essayer puis que ton (mC), te renvoie une copie du caractère envoyé utilise un câble modem qui simulera ton mc
place ton câble NULLMODEM entre les 2 Ports Com Standard d'un PC
lanece 2 sessions de ton progrmme une fois avec le port com1 et une fois avec le port COm2
mesure avec ton oscillo les pts TXD et RXD.

en principe sur un port série si le câble n'et pas trop long on peu arriver à une transmission de 256Kbauds avec des cartes d'inerfaces modernes.

je pense dans ton cas que le problème se situe dans le protocole employé
il serait peu-être utile de travailler avec des paquets de données séparée par un STX et un ETX de cette manière tu utilse les buffers internes d'emission et de réception des ports

dans ce cas l'evenemment OnChar se produira moins souvent
tu peux également modifier la priorité de ton process en la positionnant à TimeCritical , si tu choisi cette solution crée de préférence une application de type service

cordialement

**gandf** · 22/09/2003, 18h53

La vitesse de transmittion est relié au temps que dure un bit et les timeouts règle les temps entre 2 octets.

**PhDt76** · 22/09/2003, 20h52

Bonjour DjmSoftware

Nous allons essayer tout cela samedi (Le projet que nous developpons est dans un milieu associatif, je n'ai pas de maquette chez moi ni d'ossillo).
je pense essayer aussi avec un bouchon sur un port.

Quant à la transmission par paquet, le mC que nous utilisons possède un buffer de réception de 2 octets. A voir car nous travaillons aussi sous interruption. A tester entre 2 PC avant car la programmation en assembleur du mC vas être plus compliquée.

Je te tiens au courant de nos résultats à partir de samedi soir.

Cordialement,

PhDt

**PhDt76** · 22/09/2003, 21h13

Bonjour gandf,

Merci pour tes sources (sympa ton site)

Je suis sous BCB6 donc j'accepte la conversion, mais à la compilation il me manque 2 hpp

[C++ Error] Unit2.h(10): E2209 Unable to open include file 'CurrEdit.hpp'
[C++ Error] Unit2.h(11): E2209 Unable to open include file 'ToolEdit.hpp'
...

Sinon l'exe fonctionne je fais des essais samedi et je te tiens au courant.

Cordialement,

PhDt

**Vincent PETIT** · 22/09/2003, 21h32

Je viens de tester la durée de reception entre un PC est une carte bancaire sur un débit de 9600 bps. Le fait de lire 200 octets d'affiler via ce code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
long A = GetTickCount();
 
  do
   {
    ComPort1->Read(ptrs, 1);
    V += (IntToHex((InversProto(ptrs)), 2)+ " ");
   }
  while (ComPort1->InputCount () > 0);
 
 Memo1->Lines->Add (GetTickCount() - A);

dure 9ms

Donc je rejoins l'avis de DjmSoftware, ce n'est peut être pas dut à l'OS. Moi je pencherai plus sur tes cartes micros ???

**gandf** · 22/09/2003, 22h01

C'est parce que j'ai utilisé des composants qui ne sont pas livré en standard avec C++Builder et le programme a des bugs.
C'est quoi le microcontrôleur de ta carte? Tu es sur que le programme de ta carte est bien écrit?

[Débutant] Lenteur avec TComPort

C++Builder

Discussions similaires

Partager

Partager