Bonjour,
Je souhaite réaliser un circuit electronique pour pouvoir modifier les trames d'une liaison RS485 entre un emetteur et un récpeteur. Cette liaison est unidirectionnel et le circuit doit être programmable pour pouvoir modifier le protocol.
Ayant peu de connaissance en électronique je cherche des pistes pour avancer.
D'avance merci
Bonjour ashen59 et bienvenue sur FUTURAAucun problème .....Envoyé par ashen59
Donc c'est du RS422Cette liaison est unidirectionnelLà, c'est plus délicatet le circuit doit être programmable pour pouvoir modifier le protocol.Là c'est mal parti !Ayant peu de connaissance en électronique je cherche des pistes pour avancer.
En gros, il te faut un microcalculateur avec un UART et le programmer pour qu'il analyse l'octet (la trame ?) reçu et retourne un octet (une trame ?) "new look"
Tu as un exemple de trames à convertir ?
C'est entre quoi et quoi ?
Merci pour votre réponse rapide.
En fait ce circuit, dans son fonctionnement quotidien, travaillerai toujours sur le même protocol en entrée en le même protocole en sortie.
J'attends par programmable au sens où je pourrai utiliser le même circuit mais que j'aurai programmé différement pour pouvoir transcrire des protocoles différents.
Les trames sont différentes suivant le protocol mais font jusqu'a 10 octets.
Pour info c'est entre un pupitre et un dome de vidéosurveillance.
Salut !
il te faut un PIC avec 2 UART (ou un seul et tu gères le second port série en soft) + 2 convertisseurs MAX485 ou équivalent.
Le tout monté sur un petit circuit imprimé avec un conncteur ICSP pour injecter facilement différents soft dans le PIC.
Côté programmation, dis nous en quel language tu programmes habituellement.
A+
Laurent
Merci également pour ta réponse
Par contre étant novice je ne sais quel PIC choisir parmis les nombreuses références. JE ne sais pas non plus se que sont des UART (mais je vais chercher).
Pour la programmation j'ai pratiqué plusieurs languages mais orienté informatique (java,vb...) pour les PIC je crois que le C convient, mais je ne demande qu'a apprendre.
Non un seul UART, la conversion de trame est unidirectionnel (on reçoit de la console et on transmet vers la tourelle)
Re !
l'UART est le dispositif intégré au PIC qui te permet la communication série.
Dans ton cas, je te conseille le PIC16F628 qui en possède un (le 628 ... simplement parce qu'il est super courant).
En fait, si tu ne travailles qu'en unidirectionnel, tu utilises l'entrée de l'UART connectée à un max485 (lui même relié au bus venant du pupitre), et la sortie de l'UART à un autre max485 (relié au bus de ta ou tes caméras).
Sinon il faudrait aussi regarder au niveau des drivers de ligne full duplex (pour utiliser la partie réception pour un bus et l'émission pour l'autre, ça fait gagner un circuit intégré).
Si tu veux, je peux te donner le code en CCS d'un petit programme qui reçoit les trames et en renvoie d'autres, il te restera à compléter entre la ligne réception et renvoi. Par contre, je ne pourrai faire ça que mardi (à moins que je ne m'ennuie vraiment très fort ce WE).
A bientôt
Laurent
Mon cher Daudet tu as tout à fait raison, et je pense que le déclic c'est fait dans ma tête au moment où tu l'as écrit ici !
Bon week-end à tous, je laisse tomber les instruments pour le week-end (bien que j'ai du mal de quitter ma nouvelle station à air chaud).
A+
Laurent
Merci encore pour vos réponse ca fait plasirs de se sentir aidé.
je vais donc me pencher sur le pic16F628, et les convertisseurs MAX485.
Laurent si tu pouvais me donner le code pour une partie du programme sa serait super sympa.
Par ailleurs , petite question
Le temps de conversion des trames sera t il perceptible?
Je suppose que la qualité de programmation sera un facteur important.
Re !
j'ai retrouvé la référence d'un driver adéquat pour toi : le SN75179. Avec ce circuit tu n'en n'utilises qu'un seul plutot que 2 max 485.
En travaillant par interruptions, le temps de passage peut être très court.
Si tu peux être un peu patient, je te donnerai un exemple de code.
A+
Laurent
Pour information les trames sont de tailles différentes suivant le protocol.
On peut dissocier les octets d'une trame en 3 catégories:
Les octets fixe associé au protocole souvent les 2 premiers
Les octets variables qui dépendent des actions
enfin le dernier octet qui sert de checksum qui lui aussi dépend de chaque protocol et qui effectue une opération logique sur la trame.
Voici le schéma du circuit, il est composé d'assemblages trouvé ca et la. Pouvez vous m'indiquer les éléments en trop et ceux qu'ils manquent.
Par ailleurs j'ai remplacé le SN75179 par un LTC490 plus répandu.
Pour la trame entrante, est il nécessaire de faire une vérification de la cheksum? Celle-ci n'étant d'aucune utilité dans pour la suite du traitement.
Merci de vos réponse
Dernière modification par Tropique ; 22/02/2010 à 10h57.
ashen59,
Pour être conforme à l'épinglé:
http://forums.futura-sciences.com/el...-sabonner.html
merci de convertir le document en gif, png ou jpg.
Le pdf est réservé aux documents multipages complexes.
Pas de complexes: je suis comme toi. Juste mieux.
Désolé
ci-joint le schéma associé au post précédent
Salut !
Pour ton schéma il te manque un quartz de 4MHz entre les pin 15 et 16 et les I/O série ne sont pas aux bonnes pins :
La pin 7 est le RX du PIC et la 8 le TX.
Je te prépare un petit soft demain au bureau.
A+
Laurent
j'étais pas sur pour le quartz certain en mette un "pour la sécurité" d'autre font confiance à celui du pic.
Pour les eentrées je pensais pouvoir attaqué n'importe quelle entrée en logique pour lire les trames.
Pareil pour la borne Reset faut il la cabler?
voici le nouveau schéma
Salut !
pourquoi une R220ohms en série avec le quartz ?
Sinon tout est ok, mais si tu réalises déjà le print, ajoutes une LED avec une res de 1k vers la masse sur une des sorties inutilisée (par exemple RB0).
Elle sera activée lorsqu'une trame est reçue (et pour la mise au point peut être).
A demain
Laurent
Salut !
Voila un exemple vite fait en CCS :
Il te faut aussi une partie du fichier "INPUT.C" pour la définition de la fonction get_string :Code:#include <16F628.h> #FUSES NOWDT, HS, PUT, NOPROTECT, BROWNOUT, NOLVP, NOCPD #use delay(clock=4000000) #use rs232(baud=9600,parity=N,xmit=PIN_B2,rcv=PIN_B1,bits=8,timeout=100) //Modifier vitesse, bits, parité si nécessaire #include "INPUT.C" #define Test 0 //mettre à un pour vérifier le fonctionnement sur la pin B3 #int_RDA void RDA_isr(void) { char INStr[10],Output[20]; BYTE len; output_bit(PIN_B0,1);//LED ON len = get_string(INStr,10); //reçoit la trame jusqu'au caractère de fin CR //il peut être changé dans "INPUT.C" sprintf(Output,"Recu : %s !!!",INStr); //Transformation de la trame //A adapter en fct des besoins printf ("%s\r\n",Output); //envoi de la trame modifiée output_bit(PIN_B0,0);//LED OFF } void main() { enable_interrupts(INT_RDA); enable_interrupts(GLOBAL); while (TRUE) { if (Test) { output_bit(PIN_B3,1); delay_ms(250); output_bit(PIN_B3,0); delay_ms(250); } } }
A bientôtCode:BYTE get_string(char* s, unsigned int8 max) { unsigned int8 len; char c; --max; len=0; do { c=getc(); if(c==8) { // Backspace if(len>0) { len--; } } else if ((c>=' ')&&(c<='~')) if(len<=max) { s[len++]=c; } } while(c!=13); s[len]=0; return(len); }
Laurent
Je te remercie pour ce prog, que je vais analyser.
Petite question qui est peut etre bete: qu'appel tu le "caractere de fin CR"
Pour les trames d'entrées est il nécessaire de les vérifier avec la checksum avant de les modifier?
Je dois recevoir demain de quoi le tester et le faire évoluer, mais j'ai deja de nombreuses questions.
Je ne comprend pas les dimensions de INStr et output, s'agit il d'octets ou de bit, et pourquoi une différence de taille entre les deux?
Les octets sont bien en binaire?
A quoi sert la variable len dans le programme principal?
Merci d'avance
Salut !
le caractère de fin est le dernier caractère de la trame (souvent CR=carriage return ou LF=line feed, ils possèdent les codes ASCII 13 et 10), mais ça peut être autre chose.
Le mieux c'est que tu donnes une trame type ici.
Pour les dimensions des chaines de caractères, c'est en octets (1octet = 1 caractère = 8 bits), j'ai mis 10 et 20 un peu au pouf, c'est à adapter en fonction de tes trames encore une fois.
len te donne le nombre de caractères reçus, elle peut être utile dans la mise en forme ou pour retrouver le ou les caractères de checksum.
Pour le checksum, c'est mieux de faire la vérification, mais dans ce cas, il faut me dire comment il est calculé (j'ai peut être déja la routine adéquate).
A bientôt
Laurent
Mon premier exemple de convertion:
Trame d'entrée composée de 9 octets (ici en décimal)
octet 1: 160
octet 2: 1
octet 3: No du destinataire
octet 4: une fonction
octet 5: commande 1
octet 6: commande 2
octet 7: vitesse 1
octet 8: vitesse 2
octet 9: checksum ( 255 - somme des octets sauf le 1)
Trame de sortie composée de 7 octets:
octet 1: 255
octet 2: No du destinataire
octet 3: commande 1
octet 4: commande 2
octet 5: vitesse 1
octet 6: vitesse 2
octet 7: checksum (somme des octets sans l'octet 1 modulo 100)
Donc certains octets de la trame d'entrée seront inutile (2 et 4)
certains octets sont a recopier (3, 7 et 8)
et d'autre sont à travailler ensemble (5 et 6) car les infos sont mélangés entre eux
enfin le dernier octet est à créer.
Je vais donc construire une table de conversion, mon souci étant pour les octets 5 et 6 qui doivent être manipulés ensemble. L'interrogation étant de travailler au niveau binaire ou de créer des conditions ex: O32 000 devient 000 032
ou 000 004 devient 000 001
Voila a quoi ca ressemble
petit oubli
Il n'y a donc pas de caractere de fin mais plutot un caractère de début.
Est il possible de commancer la capture de la trame sur un caractère de début clairement identifié 160 et de compter le nombre de caractères jusqu'a la fin de la trame
Hello !
tu travailles en binaire pur et non en ASCII ... berk berk !
Voila un programme modifié pour tes besoins :
A+Code:#include <16F628.h> #FUSES NOWDT, HS, PUT, NOPROTECT, BROWNOUT, NOLVP, NOCPD #use delay(clock=4000000) #use rs232(baud=9600,parity=N,xmit=PIN_B2,rcv=PIN_B1,bits=8,timeout=100) //Modifier vitesse, bits, parité si nécessaire #define Test 0 //mettre à un pour vérifier le fonctionnement sur la pin B3 #int_RDA void RDA_isr(void) { BYTE Adress,Fct,Com1,Com2,Vit1,Vit2,CSIn,CSInCalc,CSOut; output_bit(PIN_B0,1);//LED ON if (getc()==160) //Octet1 { if (getc()==1) //Octet2 { Adress=getc(); //Octet3 Fct=getc(); //Octet4 Com1=getc(); //Octet5 Com2=getc(); //Octet6 Vit1=getc(); //Octet7 Vit2=getc(); //Octet8 CSIn=getc(); //Octet9 //Adaptation des données à ajouter + calcul Checksum CSInCalc = CSIn; //bidon, uniquement pour test, le CSInCalc doit être calculé avec les différents octets reçus CSOut = 123; //bidon, uniquement pour test, le CSOut doit être calculé avec les différents octets à envoyer if (CSIn==CSInCalc) //envoi uniquement si le Checksum est ok { putc(255); //Octet1 putc(Adress); //Octet2 putc(Com1); //Octet3 putc(Com2); //Octet4 putc(Vit1); //Octet5 putc(Vit2); //Octet6 putc(CSOut); //Octet7 } } } output_bit(PIN_B0,0);//LED OFF } void main() { enable_interrupts(INT_RDA); enable_interrupts(GLOBAL); while (TRUE) { if (Test) { output_bit(PIN_B3,1); delay_ms(250); output_bit(PIN_B3,0); delay_ms(250); } } }
Laurent
impeccable, il ne me reste plus qu'a inseret ma table de conversion.
Le format BYTE me renvoie un octet en décimal ou en binaire?
Bonjour,
J'ai programmé le pic avec un module icd3 de microchip par l'intermédiaire de mplab
compilation ok
transfert ok
aucun problème à première vue
Par contre je n'arrive pas a voir si le pic contient bien le programme
mais quand je met mon pic sur le circuit, lorsqu'il recoit une trame il n'ya aucune action (la led ne s'allume pas)
j'ai vérifié le cablage pas de problèmes normalement.
Je vais faire des tests a l'oscillo pour vérifer les sorties du driver 485.
Si des idées vous viennes n'hesitez pas?
Salut !
C'est de ma faute, j'ai oublié d'invalider la fonction de la pin MCLR, donc soit tu la mets à 1 sur ton hardware, soit tu ajoutes NOMCLR à la ligne 2.
Pour la ligne 2, la voici corrigée :
#FUSES NOWDT, XT, PUT, NOPROTECT, NOBROWNOUT, NOMCLR, NOLVP, NOCPD
Le second paramètre de cette ligne doit être XT pour un quartz jusque 4MHz et HS pour des valeurs supérieures.
A bientôt
Laurent
J'avais deja modifié la xt pour le quartz par contre si je met le NOMCLR je n'ai rien en sortie.
J'ai donc des données qui sortent mais d'une mannière completement anarchique avec des trames variant de 3 otets à 15 octets avec beaucoup de trame égales à 000.
En plus des que j'arrete d'injecter des trames il continue à m'envoyer des trames de 000.
JE vais essayer de créer un buffer d'entrée et de sortie pour pouvoir formater les trames
J'ai remarqué autre chose ou bout d'un il m'envoie sans aucune intervention de ma part une série de trames 000.
CE problème ne viendrai il pas d'une erreur sur le circuit?
