Communication RS232 PIC16F877A

[lost]

bonjours,

j'essaye désespérement de faire recevoir, sur la broche RX de mon PIC16F877A, une série d'octet repésentant des caractères envoyés par une caméra. J'ai déjà posté précédemment mais n'ai eu aucune réponse. J'ai continué à réfléchir sur mon problème et j'ai une nouvelle question à laquelle peut-être vous pourrez enfin répondre.

Avec le programme flowcode V4 ci-joint, j'arrive à envoyer le message souhaité, le composant connecté me répond bien sur RX, mais je recois toujours 255, on dirait que le PIC n'arrive pas à lire les octets (ceux-ci étant envoyés toutes les 33ms).

A quoi cela est-il du? le timeout de la macro receive char, le débit (ici19200 Bauds), l'horloge (ici 19,6Mhz) ou autre chose... ???

merci d'avance pour votre aide.

Xav

[Dan81]

Bonjour Xavier

Peux tu preciser ton materiel et les connections.

Si c'est une camera il doit y a voir un debit permanent donc peut etre un pb d'affichage.

As tu donné un coup d'oscillo sur la broche Rx du Pic, y a t il le signal ?

Daniel

[Enamul]

Salut
Votre programme at envoyer des données ok? Il n'a pas ou envoyer ou de recevoir quoi que ce soit. Si c'est le cas, vous devriez vérifier la connexion et voir aussi spec caméra sur le niveau de tension que ce soit 5V/0V ou non?

[Benj]

Bonjour,

Sont les caractères de votre envoi sur la broche TX venir à travers ok?

Si oui, alors votre vitesse d'horloge et les paramètres de configuration doivent tous être corrects.

J'ai modded votre programme légèrement afin qu'il envoie uniquement les données à l'écran LCD lorsque des données valides ont été reçues. Si vous avez besoin d'être en mesure de recevoir la valeur 255 alors basculer sur la valeur de retour de type INT dans les propriétés du composant RS232.


Hello,

Are the characters your sending out on the TX pin coming through ok?

If so then your clock speed and configuration settings should all be correct.

I have modded your program slightly so that it only sends data to the LCD when valid data has been received. If you need to be able to receive the value 255 then switch on the INT type return value in the RS232 component properties.

[lost]

bonjour et d'abord merci de vous intéresser à mon pb,

j'ai bien vérifier à l'oscillo si je recevais bien ma trame sur RX et c'est bien le cas (mon matériel étant la caméra CMUCAM4 (niveau 0-3V) reliée sur à l'EB006 avec un PIC16F877A et l'EB005 (LCD) pour visualiser les octets reçus)
ces trames durent ~10 à 15ms et sont envoyée toute les 33ms par la caméra. A l'intérieur de la trame un nombre d'octet variable réprésentant la position, dans le champ de vision de la cam, d'une couleur par exemple ( de la forme : T 0 0 0 0 0 0 0 0/r si je la cam ne recois pas la couleur et T 85 46 52 42 155 120 130 140/r par exemple si la couleur est détectée ci-joint la doc de la cam (commande track color (page 49))).
NB:/r étant le caractère carriage return

voila pour les explications mais depuis hier j'ai un peu avancé. En effet, je me suis rendu compte d'une erreur toute bète, j'avais le caractère reçu sous forme d'un entier au lieu d'un octet , tout de suite cela marche un peu mieu (c'est ce que vous disiez benj si j'ai bien compris, merci).

maintenant, les caractères ne sont plus 255 à chaque fois mais, resemblent plus à la forme souhaitée. Mais un pb subsiste, dans les programmes ci-joints l'affichage des caractères met enormément de temps car le programme doit "trier" les caractères entrelassés du caractère de valeur 255. Je me demande si la vitesse utilisée ou la platine utilisée est suffisantes (ou alors le timeout??? de la macro RS232). Pour info, j'utilise dans mon programme une horloge de 19.6Mhz (or l'Ebloock EB006 à un quarz de 4MhZ, je ne suis pas sur???) cela viendrait peut-être de cela, ou alors la vitesse des bits (ici 19.2Mb/s). Bref je ne sais trop dans quelle direction partir pour corriger mon pb.

dernière chose, dans les programmes ci-joins j'ai testé soit de recevoir un caractère par un caractère (test char recu), soit de recevoir les caractères et de les stocker dans une chaine (test chaine recu qui fonctionne le mieux), la macro receive string de la RS232 ne fonctionnant pas bien.

Si vous avez des idées, merci d'avance.

Xav

[Dan81]

bonjour Xavier

la broche RX (C7) est une entree triggée d'apres la doc le minimumpour l'etat haut est 0.8*VDD.

si tu utilises le EB006 , la tension est 5V (si je ne dis pas de betises !) .
Ta camera est en 3V , il est possible qu'il y ait un probleme de compatibilité.
Plusieurs possibilités :
- est il possible d'alimenter la camera en 5v (je n'ai pas regadé la doc)
- baisser l'alim du EB006 (pas evident)
- tenter de mettre une resitance (10k) de tirage à 5v coté Pic (verifier si la camera l'accepte , evenetuellment ajouter une R (1k) en serie entre la camera et le pic)

Le fait d'utiliser un integer en valeur de retour est utile si tu es susceptible de recevoir la valeur 255.
Cela semble etre le cas

Pour ce qui est de la reception, je travaillerai par interruption.
Si tu ecris en "direct" sur le LCD cela prend un peu de temps et tu risques de louper des octets.
Remplis un tableau et affiche apres.

La camera envoie-t-elle l'info 30 fois par seconde apres 1 seule demande ?
si oui : affiche sur les 2 ou 4 lignes du Lcd , les 2 ou 4 infos, puis stoppe ton programme.

tu affiches le caractere ASCII de la valeur recue : quelle interet ?



Daniel

PS : le quartz du EB006 est de 19.6MHz

[lost]

merci pour ces réponses, je teste et je reviens vers vous.

[lost]

Bonjour,

suite à vos différentes remarques j'ai vérifié mes trames les lignes TX et RX de mon montage.

Sur la ligne TX, c'est bien du 5V (normale c'est la trame envoyée par mon PIC) et sur la ligne RX c'est bien du 3V (normalement cela devrait être 3,3V). J'ai vérifié sur le schéma ci-joint de la carte comportant la caméra, le composant qui recoit la trame provenant de mon PIC est un P8X32A-Q44. Dans sa documentation, il est mentionné 3.3Vmax donc premier point, je ne suis pas sur que lui envoyer une trame 0-5V lui soit très conseillé dans la durée mème si l'info passe bien car la caméra détecte bien la couleur désirée et renvoie sur RX la trame correspondante. J'ai testé plusieur petits programmes pour la reception et il s'est avéré que par moment le PIC arrivait à lire les informations sur RX, mais seulement si je branchais l'oscillo pour visualiser. Cela confirmerait l'hypothèse selon laquelle le PIC ne comprend pas ce qu'il recoit sur sa broche RX parce que le signal est tout simplement trop faible (en effet, si on prend 0.7VDD=0.7x5=3.5V donc 3V ne suffisent pas... merci Daniel...)

Donc avant de parler programmation il faudrait que je règle ce Pb de niveau de tension. Du coup j'ai réfléchis à vos 3 propositions Daniel, et :
-il n'a pas l'air d'être possible d'alimenter la carte Caméra sous 5V (cf PJ, différents régulateurs 3,3V dans la carte, Vddmax composant =3.3V...)
-je ne sais pas comment (et si c'est possible) alimenter sous 3,3V l'EB006 et ce que cela provoquerait sur mon LCD.
-j'ai un peu peur de mettre seulement des resistances pull-up, car je ne suis pas sur que composent P8X32A-Q44 l'accepte mais peut-être que je me trompe...

du coup je me demandais si utiliser une adaptateur de niveau ne serait pas une solution. Alors j'ai vu qu'il était possible de réaliser ce petit montage en utilisant différentes solutions mais je ne sais pas qu'elle est la plus fiable sachant que les trames envoyées sont à 19.2Kb/s:

-J'ai vu une solution assez simple utilisant des MOS avec des Resistances Pull-up:
ics.nxp.com/support/documents/interface/pdf/an97055.pdf
(ici appliqué à une liaison I2C mais pourquoi ne pas l'utiliser pour ma liaison série?)

-J'ai aussi lu qu'il était possible d'utiliser tout simplement un buffer type 74HCT (porte AND) mais je ne sais pas si ils peuvent fonctionner dans les deux sens (3V-->5V pour la broche RX du PIC et 5V-->3V pour TX du PIC)?

-ou carrément utiliser un bidirecionnal level translator...

Qu'en pensez vous, j'avoue que je ne suis pas un grand électronicien, désolé...

PS: pour répondre à votre intérrogation, j'affiche sur mon programme les caractères car la trame renvoyé est une série d'octet représentant des caractères indiquant la position de la couleur cherchée, cela me permettra de suivre des objets colorés si j'arrive à concrétiser ce projet.

Merci d'avance

Xavier

[Dan81]

Bonjour Xavier

mais seulement si je branchais l'oscillo pour visualiser
surprenant (tu n'aurais pas oublié la masse sur la liaison serie)

si tu veux mettre l'EB006 en 3.3V il suffit de changer le regulateur (attention la garantie sera annulée)
Par contre le 16F risque de ne plus fonctionner à 19MHz. (il faudrait passer en 18F)
version compliquée, il vaut mieux adapter.

Pour l'adaptation toutes les solutions sont bonnes , seul detail ca fait un peu encombrant pour si peu.
Tu peux aussi rajouter un R (1k) en serie sur le Tx et voir si la camera reagit tjs.
Si la camera a supporté le Tx en 5v,
elle devrait pouvoir supporter le pull up (10k , coté Pic) avec une R (1k) en serie entre le 2 composants.
Mais là c'est ton materiel, je ne peux rien garantir.
regarde sur google (ou autre) si ce probleme n'a pas deja ete résolu simplment.


Daniel

[lost]

merci pour cette réponse,

J'ai bien cablé la masse et je fonctionne avec une sonde différentielle afin d'isoler l'oscillo de la carte.

je vais essayer votre solution avec les résistances sur TX. Et sur le RX (pour le passage du 3.3 à 5V) vous me conseillez la mème solution ou plutot une porte logique toute simple pour l'adaptation?

bonne journée

Xavier

[Dan81]

Bonjour Xavier

Apres le test sur Tx.
Personnellement, j'essaierai la version avec les 2 resistances sur Rx en visualisant la tension à l'oscillo, il faudra peut etre mettre la meme valeur pour les 2 R (10k ou 1k). C'est pour moi la solution (si elle fonctionne) la plus simple.
Sinon la version HCT convient (pour le RX seulement) mais il faut rajouter ce circuit qq part !!

bon courage
Daniel

[lost]

merci pour tout,

xav

[lost]

Bonjour,

j'ai pu tester une des solutions de Daniel, en locurrence l'utilisation d'une porte logique 74HC pour mettre en forme le signal envoyé sur le RX de mon PIC et cela marche très bien. Le programme fonctionne maintenant correctement.

Merci encore pour toutes vos contributions

Cordialement

Xavier