Communication RS 232 logiciel

[pkj]

Bonjour,

Je cherche à communiquer avec ma voiture de 1991. La voiture envoie en permanence des trames en RS232 à une vitesse de 62500 bauds,
J'ai réalisé un adaptateur qui me permet de récupérer les trames sur Terminal. Trame 232 lue par Terminal.png

J'ai trouvé un logiciel sur internent, XR25pc, qui permet d'interpréter les trames et qui fonctionnent avec plusieurs autres utilisateurs.
Cependant quand je l'utilise le logiciel (XR25pc)Interface XR25pc.jpg, les trames ne s'actualisent pas, le logiciel garde la première trame reçue lors de l'ouverture du logiciel. Je dois le fermer et le rouvrit pour actualiser la trame.

Le problème semble venir du logiciel. Quel pourrait être le problème ?
-----

[ArchoZaure]

Bonjour.

Pas facile à dire mais j'ai trouvé un cas similaire au votre sur un forum dédié.
Il paraitrait (même si je ne vois pas en quoi ça changerai quoique ce soi, mais bon l'informatique c'est pas toujours logique...) qu'il faille télécharger une police (une font) sur windows.
C'est dit ici, en fin de page : https://www.passion-espace-club.com/...1072&start=150

[pkj]

Bonjour,

Oui, en effet, j'ai eu le problème similaire. Mais ça règle problème de police. Sinon les caractères ne sont pas lisibles comme sur la photo

[gienas]

Bonjour pkj et tout le groupe

… La voiture envoie en permanence des trames en RS232 à une vitesse de 62500 bauds …
J'ai réalisé un adaptateur qui me permet de récupérer les trames sur Terminal …

Ce que je comprends, c’est que ton adaptateur est "transparent"; il ne fait que converti les niveaux RS232 en niveaux logiques tels que TTL par exemple.

Je suppose aussi que les séquences sont toujours émises, quoi qu’il arrive.

… Cependant quand je l'utilise le logiciel (XR25pc) … les trames ne s'actualisent pas, le logiciel garde la première trame reçue lors de l'ouverture du logiciel. Je dois le fermer et le rouvrit pour actualiser la trame …

Je ne connais pas ton logiciel, mais je crois comprendre que c’est l’invocation de ton programme qui lit la première séquence qui se présente, éventuellement en attendant un entête spécifique (puis une chaîne finale de clôture).

La séquence étant transmises, il se met en attente de la prochaine invocation.

Tu n’as pas précisé ce que tu souhaitais faire de la réception de ces séquences.

Il me semble que c’est un programme qu’il t’appartient de développer, pour en faire ce que tu souhaites.

Il me semble aussi que ton adaptateur "fait son job": tu pourrais brancher sa sortie sur un afficheur (terminal) qui afficherait les caractères reçus. Que demander de plus?

[A voir en vidéo sur Futura]

[pkj]

Bonjour Gienas,

Merci pour votre message, oui c'est un montage pour adapter les trames générées par la voiture de 12V à 5V et un FTDI FT232RL pour l'usb.

J'ai utilisé le terminal pour vérifier si les trames étaient bien reçues en continu ce qui est le cas ! En effet, l'adaptateur fait bien son travail.

La finalité est d'avoir les trames en continu sur le logiciel.
Que dois-je faire pour le logiciel actualise ces trames ? Où pourrait-être le problème ?

[gienas]

... La finalité est d'avoir les trames en continu sur le logiciel ...

D’après ta description c'est bien le cas: le logiciel reçoit bien ses trames.

... Que dois-je faire pour le logiciel actualise ces trames ? Où pourrait-être le problème?

Comme annoncé, j'ignore complètement à quoi sert le dit logiciel et ce qu'il est supposé faire. Tu es toi supposé le savoir puisque tu l'as choisi.

Je comprends, par le comportement que tu décris, que le logiciel est un one shot: il ne sort qu'une fois et, probablement, sort du programme en attente du prochain coup.

[Henrix]

Bonjour,
@: "pkj": ce qui serait bien:
C'est que tu donne le schéma de ton adaptateur (en cadeau de Noël ou en étrennes de nouvel an).
Que tu dise dans quel langage tu veut traiter les données.

[ArchoZaure]

Un truc à vérifier peut-être.

La connectique du câblage (prise incompatible avec le protocole).
Mais aussi le protocole

Protocoles d'échange des données
Ce type de liaison peut utiliser un protocole pour contrôler l'échange des données. Ce contrôle du flux de données est
nécessaire à débit important, ou lorsque l'équipement récepteur n'est pas assez rapide pour traiter toutes les données
qui lui sont transmises.

Le protocole logiciel XOn XOff consiste à envoyer à l'émetteur des codes de contrôle afin de ralentir l'envoi des
caractères. Envoi de XOff (caractère 17 de la table ASCII) vers l'émetteur pour arrêter la transmission, puis de Xon
(caractère 19 de la table ASCII) pour reprendre la transmission.

Le protocole matériel RTSCTS nécessite l'utilisation de deux fils supplémentaires dans le câble (liaison 5 fils). La
broche RTS (Ready To Send) du premier équipement doit être reliée à la broche CTS (Clear To Send) du deuxième
équipement et vice versa. Ces connexions permettent à l'émetteur de signaler qu'il est prêt à émettre et au récepteur
de signaler qu'il n'est plus apte à recevoir d'autres données.

Le protocole matériel DTR (Data Terminal Ready) DSR (Data Send Ready) était utilisé pour la communication
sur ligne téléphonique via deux modem RTC avant l'ADSL

https://euler.ac-versailles.fr/IMG/p...tion_rs232.pdf

[pkj]

Bonjour,

Je ne sais pas si le logiciel de diag XR25 reçoit bien les trames mais l'ordi oui comme le montre le logiciel Terminal.
Je sais effectivement ce que fait le logiciel XR25, mon seul problème est pourquoi les valeurs affichées ne s'actualisent pas en temps réel.

Je comprends, par le comportement que tu décris, que le logiciel est un one shot: il ne sort qu'une fois et, probablement, sort du programme en attente du prochain coup.

Exactement pourquoi et comment résoudre le problème ? J'ai qu'une trame de 43 bits alors que sur Terminal je les reçois en continu.

@: "pkj": ce qui serait bien:
C'est que tu donne le schéma de ton adaptateur (en cadeau de Noël ou en étrennes de nouvel an).
Que tu dise dans quel langage tu veut traiter les données.

Ce sera tir groupé ! Le montage est basique, la PIN 9 correspond à la pin data de la prise OBD de la voiture et la PIN la masse de la prise OBD.
Un FTDI FT232RL reçoit les données. J'ai replacé la LED par un fil.



Archozaure, je pense que c'est plutôt un problème de ce genre, ne connaissant pas très bien la communication série, je sèche un peu. je vais regarder cet aspect.

[gienas]

Bonjour à tous

… Exactement pourquoi et comment résoudre le problème ? J'ai qu'une trame de 43 bits alors que sur Terminal je les reçois en continu …

Donc le programme est conçu pour ne fonctionner qu’une fois et sortir, après avoir affiché le résultat. Il fait le travail qu’on lui a demandé de faire.

Tu n’as pas expliqué (comme demandé plusieurs fois) ce que tu cherches à faire, et pourquoi tu as choisi ce programme qui ne fait pas ce que tu veux.

Si le résultat que tu cherches à obtenir est de faire tourner en boucle ton programme (qui n’est pas modifiable), c’est à toi de créer une boucle qui invoque ton programme indéfiniment, tant que tu n’appies pas sur une touche convenue qui fera sortir de la boucle.

[Henrix]

@: "pkj":
Si tu es sous Windows, et que ton logiciel se lance par un ".exe", je peux te faire un "Lanceur"
Qui lancera l'exe toutes les X millisecondes pour un nombre N de boucles.
Par contre le lanceur ne saura pas fermer les instances du logiciel
Et si le logiciel recouvre le lanceur, tu n'aura pas accès au bouton "Stop".
Si tu le eux, y a qu'à demander.

[umfred]

Tu as fouillé dans les menus du logiciel si il y avait moyen de forcer l'écoute des trames ? ou de les lire en continu ? (par exemple, peut-être le menu "Scan")

[ArchoZaure]

Tout est détaillé ici (traduit par google, je ne parle pas le chinois ), si ça peut intéresser :
https://www-renault--bg-com.translat...fr&_x_tr_hl=fr

[umfred]

c'est du bulgare, c'est mis dans la bulle de traduction
Après, je me demandais aussi si tu avais choisi la bonne "cible" qui doit adapter la lecture du protocole (on voit sur ta capture interface qu'à la fin on retrouve les mêmes octets qu'au début, donc je soupçonne une désynchro de lecture dû à un "mauvais" nombre d'octets lus)

[pkj]

Bonjour,

Le programme est fait pour lire les trames en continu vis à vis d'un nombre de bits reçu. Le programme permet d'interpréter les trames émises par la voiture (régime moteur, vitesse, tension batterie, défauts...). Cela permet de faire des graphes en continu. Le calculateur émet un N° d'identification de la voiture. Toutes les trames démarrent par FF 00

J'ai l'impression que le logiciel ne détecte pas le bon modèle de voiture. La trame affichée dans le logiciel finie par FF 00.

Le site en bulgare pourrait bien m'aider. Il faut que je me renseigne sur la longueur et la valeur du bit d'identification de mon calculateur.

Merci pour votre aide.

[Henrix]

@: pkj: J'ai cherché le logiciel dont tu parles, pour voir de quo il s'agit.
Je ne l'ai pas trouvé

[pkj]

Voici un lien Youtube montrant l'interface

http://https://www.youtube.com/watch...82%D1%8B%D1%85

La première page de ce forum présente également le logiciel :
http://https://www.passion-espace-cl...ic.php?t=31072

[umfred]

il y a un petit souci avec tes liens (il manque le ":" derrière le https dans les adresses cibles)

[Henrix]

@: pkj: Ce n'est pas l'interface ni la description qui m'intéresse, c'est le contenu, le code.

[umfred]

je n'ai pas l'impression que le code soit en open source, mais tu as pas mal d'info sur la page du forum du lien de ArchoZaure #13 => http://www.renault-bg.com/smf/index.php?topic=106958.0 (page à faire traduire)

[Henrix]

@: umfred: Quand ce n'est que pour visiter, consulter, étudier, je pense qu'on a le droit de désassembler.
Reste à trouver le logiciel...

[umfred]

lien direct de téléchargement vers les installeurs et doc https://turborenault.co.uk/upload/xr25-pc.zip

[Henrix]

Merci umfred voilà du grain à moudre.

[pkj]

J'ai également le logiciel, est-il possible de le désassembler pour obtenir le code source ?
Cela me permettra me permettrait d'y voir. Notamment s'il y a des conditions sur la longueur des trames, association suivant les bits lus...

[Ikhar84]

Bonjour,

Non il n'y aura pas ici de conseils ou d'informations permettant de désassembler ou de retrouver le code source d'un logiciel propriétaire, non tombé dans le domaine publique !

[Henrix]

! pkj: Désassembler ne donne pas le code source, ,on obtient de l'assembleur et de l'hexadécimal (qu'il faut décoder).
Très difficile à suivre et à comprendre (renvois de renvois de renvois...ect multiples et nombreux).
Il faut avoir du temps à perdre (beaucoup de temps).
Quand à recompiler, c'est même pas la peine d'y penser

[umfred]

@pkj: il me semble que sur le forum renault-bg (cf les liens donnés plus haut message #20), il est expliqué que la trame dépend effectivement de la cible choisi, et c'est un fichier à part (si je me rappelle bien, je n'ai pas été revérifié) qui définit ces trames. Je te laisse relire le forum renault-bg