Port série

[Ollivier]

@Olivier

J'ai tenter le crayon directement dans le port USB mais le PC ne s'allume plus et mon médecin me dit que j'ai un teint fluo

Il faut se contenter d'un tuto du samedi soir avec une cape haute phosphorescente !

@Marc56

Pardon Marc... Je me suis égaré... MetalOS parle de symboles bizarres. Souvent les périphériques série ont deux modes de communication : un mode "chaîne" et un mode "caractère". C'est sûrement ça sa difficulté désormais.

[Marc56]

Pardon Marc... Je me suis égaré... MetalOS parle de symboles bizarres. Souvent les périphériques série ont deux modes de communication : un mode "chaîne" et un mode "caractère". C'est sûrement ça sa difficulté désormais.

Ollivier, j'ai pris l'habitude de devoir te relire plusieurs fois pour comprendre la subtilité de tes réponses Effectivement il y a le mode chaine et caractère. Tu as bien fait de préciser.
De plus, s'agissant d'un périphérique qui envoie des données en continu (je pense), il va falloir gérer gérer la vidange du buffer en entrée et les éventuels encodage.
Déjà ça communique, c'est bien. Reste à décoder proprement.
Intéressant ce topic, j'ai ressorti un vieux modem RTC (sans le connecter à la prise) pour tester le commandes série de PB en utilisant les commandes Hayes. C'est plus facile que d'écrire un programme simulateur de dialogue série pour la carte Arduino.

[Ollivier]

Ok, ça se résume ainsi :

- mode "chaîne" : suite de codes caractères terminés par un code terminal (souvent code13 puis code10).
- mode "caractère" : un code ou plusieurs codes suivis d'une séquence terminale de codes, avec parfois un code de checksum.

Il reste à savoir si le compte Geiger de MetalOS a une doc (même en anglais), sinon ça va être à tâtons

[MetalOS]

La seul Doc dispo que j'ai trouvé c'est le protocole de communication

Code : Tout sélectionner

https://github.com/stilldavid/gmc-300-python/blob/master/GQ-RFC1201.txt

Sinon un code sur github que j'ai mis plus haut dans le file de discussion. Je vais envoyer un mail au constructeur pour lui demander si il a une Doc. Ils semblent assez ouvert pour que les gens développe leurs propres logiciels. En tout cas encore merci pour votre aide.

Le seul truc de bizarre c'est que la commande GETVER me retourne bien la version du boîtier et du numéro de firmware en claire mais toute les autres commandes me retourne des caractères bizarre.

[Bmld76]

bonjour,

je te conseille de vérifier le bon fonctionnement de ton compteur et de ta liaison avec un logiciel de com avant de programmer. Tu sépares les pb. Après avoir validé le coté hard, tu peut travailler sur le soft. Ton pb ressemble fort à un pb de réglage de la liaison, j'ai beaucoup travaillé dans ce domaine. As tu fait des essais avec un logiciel genre Coolterm (je te le conseille) ?

[case]

La seul Doc dispo que j'ai trouvé c'est le protocole de communication

Code : Tout sélectionner

https://github.com/stilldavid/gmc-300-python/blob/master/GQ-RFC1201.txt

Sinon un code sur github que j'ai mis plus haut dans le file de discussion. Je vais envoyer un mail au constructeur pour lui demander si il a une Doc. Ils semblent assez ouvert pour que les gens développe leurs propres logiciels. En tout cas encore merci pour votre aide.

Le seul truc de bizarre c'est que la commande GETVER me retourne bien la version du boîtier et du numéro de firmware en claire mais toute les autres commandes me retourne des caractères bizarre.

salut, d’après la RFC que tu as mis en lien, seul <GETVER>> semble renvoyer un string. toute les autres commandes renvoient des valeurs numériques, c'est donc plutôt normal que si tu affiche en string tu aie des caractères bizarres.

[MetalOS]

@Bmld76

J'utilise le soft fournit par le constructeur pour faire mes testes comme je sais que ça fonctionne. Je ne connais pas coolterm je vais regarder. Merci.

@Case

Effectivement j'avais pas vue dans la doc que seul cette commande renvoie un string. Je vais donc faire d'autre testes. Merci.

[MetalOS]

En attendant une réponse du constructeur je travail sur l'interface.

[SPH]

Waouw, c'est toi qui fait ce logiciel ?
Très beau (Question bête : codé en PB ?)

[MetalOS]

Merci oui tous en PB en récupérant des bout de code à droite et à gauche.

[MetalOS]

Grace à vous j'arrive à récupérer les données de mon compteur Geiger ou j'arrive à incrémenter mon graphique. J'utilise cette procédure

Code : Tout sélectionner

Procedure Read_CPM() 
   Resultat2 = WriteSerialPortString(#hPort, "<GETCPM>>")  
If Resultat2 
     While AvailableSerialPortInput(#hPort)
          If ReadSerialPortData(#hPort, @Buffer, 1)
               ; Debug Buffer
            Text1$ = Str(Buffer)
            cpm.q = Val(Text1$)
            EndIf
     Wend
     Debug Text1$
  EndIf
EndProcedure

Que j'appel avec cette commande

Code : Tout sélectionner

SetTimer_(WindowID(#Window_Form2), 1,1000, @Read_CPM())

Ca fonctionne pas mal. Il ne me reste plus qu'à exploiter les autres données dont j'ai besoin et de générer par la suite des rapports qui peuvent être consultés plus tard. Merci encore pour votre aide.

[case]

Grace à vous j'arrive à récupérer les données de mon compteur Geiger ou j'arrive à incrémenter mon graphique. J'utilise cette procédure

Code : Tout sélectionner

Procedure Read_CPM() 
   Resultat2 = WriteSerialPortString(#hPort, "<GETCPM>>")  
If Resultat2 
     While AvailableSerialPortInput(#hPort)
          If ReadSerialPortData(#hPort, @Buffer, 1)
               ; Debug Buffer
            Text1$ = Str(Buffer)
            cpm.q = Val(Text1$)
            EndIf
     Wend
     Debug Text1$
  EndIf
EndProcedure

Que j'appel avec cette commande

Code : Tout sélectionner

SetTimer_(WindowID(#Window_Form2), 1,1000, @Read_CPM())

Ca fonctionne pas mal. Il ne me reste plus qu'à exploiter les autres données dont j'ai besoin et de générer par la suite des rapports qui peuvent être consultés plus tard. Merci encore pour votre aide.

Command: <GETCPM>>
Return: A 16 bit unsigned integer is returned. In total 2 bytes data return from GQ GMC unit. The first byte is MSB byte data and second byte is LSB byte data.
e.g.: 00 1C the returned CPM is 28.
Firmware supported: GMC-280, GMC-300 Re.2.0x, Re.2.10 or later

commande :<GETCPM>>
Renvoie : un nombre non signé sur 16 bits est retourné. au total 2 octets de données renvoyés depuis l’unité GQ GMC. le premier octet est l'octet de poids fort le second est l'octet de poids faible.
exemple: 00 1C le CPM retourné est 28.

tu devrais plutôt utiliser quelque chose comme ça car je pense que ta méthode n'est pas la bonne pour lire les valeurs

Code : Tout sélectionner

Procedure Read_CPM() 
   Resultat2 = WriteSerialPortString(#hPort, "<GETCPM>>")  
If Resultat2 
     While AvailableSerialPortInput(#hPort)
          If ReadSerialPortData(#hPort, @Buffer, 2) ; 2 octets la valeur renvoyée étant de 16 bits
          cpm.u=PeekW(@buffer); unsigned 16bit                
          endif
    Wend
  EndIf
EndProcedure

[MetalOS]

Ça semble fonctionner comme j'ai fait mais si ta version engendre moins d'erreur je prend. Merci case

PS: en plus ça m'a permis de découvrir la commande PeekW que je n'avais jamais utilisé.

[case]

non ca semble fonctionner mais ce qui semble n'est pas forcement ce qui se passe et ta méthode ne fonctionne absolument pas

je vais t'expliquer pourquoi et comment faire ca te servira pour la suite j'en suis sur ^^

dans la RFC il est indiqué que ta commande renvoi un nombre sur 16 bits 1 bit de poids fort puis un bit de poids faible.
ce qui sous entend quee ton compteur renvoi des valeurs entre 0 et 65535 (maximum) ou en tout cas plus grandes que 255.

Code : Tout sélectionner

; explication octet de poids fort et octet de poids faible.
; pour comprendre il faut se representer la memoire de l'ordinateur
; un octet contien 8 bit qui peuvent n'avoir qu'une valeur de 0 ou de 1
; si je veux representer le nombre 1 soit en binaire 00000001 je remplis la case la plus a gauche avec un 1
;                
;    +-+-+-+-+-+-+-+-+
;    |0|0|0|0|0|0|0|1|
;    +-+-+-+-+-+-+-+-+
; si je veux une valeur de 255 11111111 je vais tout remplir  avec des 1
;
;    +-+-+-+-+-+-+-+-+
;    |1|1|1|1|1|1|1|1|
;    +-+-+-+-+-+-+-+-+
; mais si je veux une valeur plus grande que 255 je ne peux pas avec un octet 
; c'est la qu'apparait les bits de poids fort et les bits de poids faible 
; on prend 2 octets un qui aura les bits de poids faible qui permettent de compter jusqu'a 255
;
; et un autre qui aura des bits de poids forts chacun des bits aura une valeur 2 fois plus importante que le precedente le premier bit valant 256
; soit en binaire 100000000
;       FORT                FAIBLE
; +-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+
; |0|0|0|0|0|0|0|1|   |0|0|0|0|0|0|0|0|
; +-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+
;
; si je veux ecrire une valeur de 512
;
;       FORT                FAIBLE
; +-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+
; |0|0|0|0|0|0|1|0|   |0|0|0|0|0|0|0|0|
; +-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+
;
; jusqua un maximum de 65535 1111111111111111
;
;       FORT                FAIBLE
; +-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+
; |1|1|1|1|1|1|1|1|   |1|1|1|1|1|1|1|1|
; +-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+

dans ton code tu lis ton interface serie tant qu'il y a des octets en attente un seul octet a la foi.

Code : Tout sélectionner

 ReadSerialPortData(#hPort, @Buffer, 1)

et tu ecrit le resultat au meme endroit (@buffer)
donc ton nombre sur 2 octets (16bit) sera lu en 2 fois.
donc tu lira 2 valeurs avec 255 en max a chaque fois.
et lorsque tu aura tout lu ce qu'il y a sur le port serie , normalement 2 octets tu n'aura recupere que l'octet de poids faible.

ensuite cette commande

Code : Tout sélectionner

Text1$ = Str(Buffer)

converti en string la valeur de buffer mais pas le contenu de buffer
or la valeur de buffer dépend de ce que c'est. dans tout les cas tu n'aura pas la donnée que tu recherche.
lorsque tu converti ensuite en utilisant val()
tu n’aura pas non plus la valeur que tu recherche voici pourquoi
même si on part du principe que ta string contiens bien les 2 octets renvoyés ce qui n'est pas du tout le cas comme explique plus haut
la commande val() converti un "caractère" en valeur numérique ce qui signifie que seul les valeurs de 48 a 57 seront converties en chiffres
en gros val prend par exemple "2"+"0" et converti cela en 20 mais "2" c'est la valeur 49 et "0" la valeur 48 dans la table des caractères.

[MetalOS]

@case

Je comprend plus ou moins, mais si j'utilise ton exemple

Code : Tout sélectionner

Procedure Read_CPM() 
   Resultat2 = WriteSerialPortString(#hPort, "<GETCPM>>")  
If Resultat2 
     While AvailableSerialPortInput(#hPort)
          If ReadSerialPortData(#hPort, @Buffer, 2) ; 2 octets la valeur renvoyée étant de 16 bits
          cpm.u=PeekW(@buffer); unsigned 16bit                
          endif
    Wend
  EndIf
EndProcedure

J'ai des valeurs qui dépasse les 3000CPM ce qui est faux par rapport à ce qui est affiché sur l'écran LCD du boitier. Si j'utilise mon code j'ai des valeurs identique à ce qui est affiché sur l'écran LCD du boitier.