Visualiser les datas d'un capteur sur un PC

[invite5b7deb33]

Bonjour à tous,
Je suis actuellement en train de tester un capteur PIR (présence via infrarouge).
Ce capteur est de type numérique (il intègre dejà un DAC dans son boitier).
Je voudrai voir en temps réel sur mon PC, les datas transmises par le capteur à mon microcontrôleur (ATmega328P).
Je comptais utiliser un programme déjà développé par Atmel : Atmel Data Visualizer. Mais il semblerai que ce logiciel ne puisse fonctionner qu'avec un protocole USB.
J'ai essayer avec un cordon FTDI (USB <--> UART), mais le programme plante immédiatement à la réception de data.
Je suppose donc qu'il ne comprend pas les signaux venant du câble FTDI.
Mon MCU ne gérant pas l'USB, je dois donc abandonner l'idée d'utiliser ce programme.

Question : Quelqu'un à t'il déjà visualiser des datas d'un MCU depuis son PC (via UART par exemple) ?
Si oui, peut-il me briffer ?

Merci d'avance.
-----

[DAUDET78]

Question : Quelqu'un à t'il déjà visualiser des datas d'un MCU depuis son PC (via UART par exemple) ?

Beaucoup de gens ... mais de plus en plus rare !

• Il suffit que l'UART de ton MCU passe ses données par un MAX232
• Il suffit d'un câble blindé (2 conducteurs + tresse si tu veux aussi du PC vers MCU )
• Il suffit d'un PC avec un port COM (ou un port COM virtuel sur USB)
• Il suffit d'avoir (ou d'écrire) un logiciel qui affiche tes datas sur l'écran .

[invite1d577638]

Si la communication passe par un port série, teste déjà la reception avec Hyperterminal (fourni avec windows) ou bien un soft léger, genre Putty.

[invite5b7deb33]

Il suffit d'avoir (ou d'écrire) un logiciel qui affiche tes datas sur l'écran

Oui en effet, c'est là que je suis intéressée. Je n'est pas ce logiciel. Et cela me prendrai beaucoup de temps de le faire.
Auriez vous un nom de logiciel à me proposer ?
Pour ce qui est du reste de la configuration : un simple cordon FTDI remplace un MAX232 avec la fameuse paire de fils blindé et des connectiques DB9 qui se font de plus en plus rares sur les PC portable.

Pour ce qui est de l'hyperterminal, c'est deja testé. Et la communication se passe très bien.
Je cherche aujourd'hui soit à réussir de paramétrer Atmel Data Visualiseur ou un autre soft compatible RS232.

Merci

[A voir en vidéo sur Futura]

[DAUDET78]

Oui en effet, c'est là que je suis intéressée. Je n'est pas ce logiciel.i

Il me semble qu'on pourrait le faire avec Excel et du VBA (mais je ne sais pas faire) . Moi, je fais ça en VB6 . C'est vieux, c'est obsolète ...mais je sais faire !

[luc_1049]

bonjour

J'ai vu cela sur www
http://www.atmel.com/webdoc/dv/ch01s01.html

Si on parle bien de la même chose vous devriez pouvoir utiliser la laision série de la carte.

Mais comme dit précédemment vous n'avez pas besoin de ce logiciel qui apporte un peu de convivialité car dans une fenêtre windows.

Vous codez une liaison série et reliez votre carte au pc via une adaptation via des circuits maxim type max232... Ou éventuellement un adaptateur ttl <=> rs232 tout fait type ftdi quelques euros tout fait.
Et vous aurez un affichage plus ou moins différé sur le pc en fonction de votre code dans un soft équivalent à l'hyperterminal.
ET vous gagnerez en plus en portabilité si vous devez sortir ces informations sur un système rs232 qui ne fonctionne pas sous windows, très vieille console vt220...

cdlt luc_1049

[invite5b7deb33]

Merci pour ce commentaire luc_1049.
En effet, je n'avait pas vu ce schéma de principe, qui viendrai alors confirmer qu'il est possible d'envoyer les infos via RS-232.
Maintenant je ne comprend pas pourquoi il n'y a aucun paramétrage dans Atmel Data Visualiser à propos de débit baud, parité etc..
Le seul paramétrage disponible est l'adresse COM du port USB. Pour mon cas : COM5

ADV s'adapte tout seul à la vitesse de transmission ? Étrange...

Je cherche à comprendre.

[invite5b7deb33]

Il me semble qu'on pourrait le faire avec Excel et du VBA (mais je ne sais pas faire) . Moi, je fais ça en VB6 . C'est vieux, c'est obsolète ...mais je sais faire !

DAUDET78, pensez vous que le VB6 puisse tenir la lecture d'un débit de 115200 bauds, via la RS-232 ?
Car j'ai tenté avec LabView, mais impossible, ça rame de trop il tiens pas le coup. Il faut un programme léger et efficace.

[invite1d577638]

DAUDET78, pensez vous que le VB6 puisse tenir la lecture d'un débit de 115200 bauds, via la RS-232 ?

Il me semble l'avoir déjà fait. Si le traitement des infos est rapide, ça devrait passer !

[invite5b7deb33]

Je veux bien le programme alors

[DAUDET78]

DAUDET78, pensez vous que le VB6 puisse tenir la lecture d'un débit de 115200 bauds, via la RS-232 ?

C'est des trames à 115200 ? qui durent combien de temps ? tous les combien ?

[invite5b7deb33]

Une trame toutes les 2 ms

[invite1d577638]

Je veux bien le programme alors

Arff, d'ici que je retrouve ça, tu as plus vite fait de demander des exemples de code à google !

[DAUDET78]

Une trame toutes les 2 ms

Et qui contient combien d'octets ?

[invite5b7deb33]

6 octets pour chaque trame.

[DAUDET78]

Donc 3000 octets par seconde, ça devrait le faire .
Par contre , 3000 octets pour détecter une présence, cela me semble beaucoup !

Je suis actuellement en train de tester un capteur PIR (présence via infrarouge).

Tu as un lien WEB sur la notice de ce capteur ?

[PA5CAL]

Bonjour

Maintenant je ne comprend pas pourquoi il n'y a aucun paramétrage dans Atmel Data Visualiser à propos de débit baud, parité etc..
Le seul paramétrage disponible est l'adresse COM du port USB. Pour mon cas : COM5

Le choix d'une liaison parmi celles disponibles est bien du ressort du programme de visualisation.

En revanche, le paramétrage de cette liaison est souvent laissé aux soins d'autres logiciels, comme par exemple le panneau de configuration du système d'exploitation ou les commandes en ligne idoines ("mode com..." sous Windows, "stty ..." sous Linux ou Mac OS X).

S'agissant d'une liaison RS232 virtuelle émulée par une liaison USB, la communication entre le PC et l'appareil peut déjà fonctionner même si aucun paramétrage de la liaison RS232 virtuelle n'a pas été effectué.

En revanche, il est possible que le paramétrage soit quand même nécessaire, notamment s'il est utilisé pour modifier la configuration de l'appareil connecté. C'est par exemple souvent le cas lorsque, dans l'appareil, la liaison USB est prolongée par une liaison de type RS232 : le paramétrage de l'interface série virtuelle sur le PC réalise en fait le paramétrage de l'interface série matérielle sur l'appareil, et fixer la vitesse de transmission ou le nombre de bits prend alors tout son sens.

[invite5b7deb33]

Par contre , 3000 octets pour détecter une présence, cela me semble beaucoup !

En fait, c'est mon choix que de prendre un échantillon toute les 2ms. Pour pouvoir filtrer et détecter.
Le but est d'avoir le plus d'échantillons possible, afin d'avoir la meilleur interprétation possible du signal.
Si après étude du comportement du capteur, j'en conclut que toute les 100 ms une acquisition sera suffisante alors parfait. Mais il me faut deja le déduire.
Et pour le déduire, j'ai besoin de visualiser en temps réel le comportement de mon capteur

Tu as un lien WEB sur la notice de ce capteur ?

Je n'est pas de lien web pour une datasheet.
Mais il s'agit d'un capteur de chez Excelitas. Le PYD5790 de type digipyro

[invite5b7deb33]

PA5CAL, pour moi une liaison RS-232 est une liaison asynchrone. Seul les paramètres bauds, parité, bit stop etc. permettent de se synchroniser avec le signal pour en comprendre les données.
Mais dans mon cas, je me suis aperçu que Atmel proposait 2 sortes de Visualiseur. Un prévu pour une liaison de type USB associé à un µC gérant lui aussi ce protocole.
Et un autre ADV (Atemel Data Visualizer) plus généraliste, avec cette fois-ci, des réglages série permettant le dialogue avec n'importe quel µC.
Seul problème dans cette dernière, trop peut d'information de la part de Atmel pour mettre en oeuvre convenablement un dialogue fiable et efficace.
Pas de note d'application, juste une petite aide en ligne succincte.
Décevant.

[PA5CAL]

PA5CAL, pour moi une liaison RS-232 est une liaison asynchrone. Seul les paramètres bauds, parité, bit stop etc. permettent de se synchroniser avec le signal pour en comprendre les données.

Depuis l'avénement de USB, et surtout depuis la disparition officiellement de l'interface RS232 matérielle sur les PC (même si en pratique on peut encore en équiper certains ordinateurs), on utilise des interfaces série virtuelles émulées par des interfaces USB, ce qui permet de continuer à utiliser sur des matériels récents des logiciels initialement prévus pour communiquer au travers des anciens ports série standards.

Quand une application logicielle utilise les ports standards au travers du système d'exploitation (i.e. utilisation de COM sous Windows, sans accès direct au matériel du PC), elle n'a pas de moyen de savoir si ce qu'il y a derrière est une véritable carte RS232 matérielle ou bien une liaison USB vers un device CDC (interface FTDI, port USB d'un µC Atmel ou autre). C'est très certainement le cas du logiciel de visualisation "généraliste" d'Atmel.

Mais alors comme le fonctionnement correct de l'interface repose sur la configuration du PC et sur son paramétrage, on peut comprendre qu'Atmel n'entre pas trop en détail dans ce type de considérations et ne fournisse que le minimum standard, vu qu'ils sont dans l'incapacité de garantir le comportement effectif des logiciels (drivers) et des matériels a priori inconnus qui sont installés, ni de prévoir les choix de l'utilisateur en terme de conception de son application électronique pour tout ce qui sort de l'horizon du protocole de transmission des données à visualiser (pour lequel, j'imagine, ils fournissent une bibliothèque logicielle).

Ce qu'ils peuvent garantir en revanche, c'est qu'une fois que la liaison établie par les soins de l'utilisateur permet d'échanger correctement des octets, leur protocole de communication de plus haut niveau fonctionnera.


Tout ça pour dire que :
- le fonctionnement de la liaison entre ton µC et ton PC reste ton affaire,
- même si tu souhaites changer de logiciel de visualisation (voire en développer un par toi-même), il faudra quand même que tu règles cette question, sans disposer de plus d'informations qu'actuellement.

[invite5b7deb33]

Je comprend tout à fait.

Ce qu'ils peuvent garantir en revanche, c'est qu'une fois que la liaison établie par les soins de l'utilisateur permet d'échanger correctement des octets, leur protocole de communication de plus haut niveau fonctionnera.

En effet, je pense que leur protocole doit bien fonctionner si sont contenu était plus détaillé et plus explicite.