Bonsoir
Je cherche depuis un petit moment a faire du codage type manchester.
Pour ce qui est de la théorie je pense avoir compris mais dans la pratique j'ai du mal a trouver des infos.
Je voulais utiliser l'oscillateur interne de mon PIC pour la synchronisation d'horloge, mais comment faire le codage/décodage en langage C ?
Bonsoir
Le codage et le décodage sont deux choses bien distinctes.
Le codage est généralement réalisé à la cadence de l'horloge locale et consiste juste à émettre deux niveaux successifs L et H pour un bit à 0 ou deux niveaux successifs H et L pour un bit à 1. Mais contrairement à un codage en assembleur qui permet de maîtriser la chronologie du programme, l'emploi du langage C (qui produit un code a priori inconnu) nécessite de synchroniser l'exécution du programme sur une horloge interne.
Sauf si une partie du travail est réalisée par des circuits externes, le décodage nécessite de mesurer la durée des niveaux L et H reçus à l'aide d'une horloge interne :
- d'une part pour retrouver la chronologie du signal afin de s'y adapter et de compenser les éventuelles variations entre la fréquence de l'émetteur et celle du récepteur ;
- d'autre part pour transformer les séquences de niveaux en bits 0 ou 1. On peut effectuer la transcription par paires de niveaux d'entrée successifs sur la base de leur durée théorique (LH=0 et HL=1), ou attendre la survenue d'un changement de niveau avant de produire le ou les bits reconnus (LHHL=01, HLLH=11, etc.). Une détection et une prise en charge des erreurs et des violations du protocole de transmission peuvent être nécessaires, surtout si cela a été rendu conventionnellement significatif (synchronisation de trames, notamment).
Bonsoir,
j'ai récemment publié ici un truc sur le sujet :https://forums.futura-sciences.com/e...anchester.html
Mais c'est pour AVR je ne sais pas si c'est transposable au PIC,mais à survoler la doc cela semble faisable.
Le codeur et le décodeur utilisent l'USART en mode synchrone cela fonctionne très bien.
Il faut juste rajouter un XOR (74xx86) coté émetteur et le petit circuit (© jiherve ) décrit dans mon lien.
JR
l'électronique c'est pas du vaudou!
Salut,
Il est aussi possible de se passer de circuits externes en utilisant des PIC qui ont des cellules logiques programmables intégrées (CLC).
Cette note d'application montre comment utiliser des périphériques particuliers pour faire un encodeur manchester.
a+
Bonjour,
je ne connaissais pas cette fonctionnalité mais cela ne remplace que le xor (cependant il suffit de 2 transistor pour en faire 1) rien pour la démodulation.
JR
l'électronique c'est pas du vaudou!
Bonjour,
En fait ce que je voulais faire c'est mettre ma sortie à l'état haut et regarder le prochain bit a coder si le bit est 1 on appelle une fonction qui met la sortie a zéro puis une demi période plus tard la met a 1 ce qui permet de coder le 1 comme une transition a l'état haut(même principe pour le zéro) puis on regarde le prochain bit a coder et ainsi de suite avec des interruptions chaque demi période, en principe est ce que un programme de ce genre peux fonctionner
bonsoir,
oui mais c'est gaspiller les ressources du µC alors qu'une simple porte logique le fera bien mieux et bien plus vite.
JR
l'électronique c'est pas du vaudou!
BonjourC'est un point de vue qui doit être évalué au cas par cas.Envoyé par jiherve
D'une part, le fait de rajouter des circuits extérieurs complique le montage et représente des coûts supplémentaires.
D'autre part, a priori rien ne dit que le µc ne dispose pas des ressources nécessaires pour faire tout le travail. Et il n'est pas non plus forcément interdit de choisir un µC un peu plus puissant.
Merci de mettre de la ponctuation, ça sera plus simple à lire.
Commencer par mettre la sortie à 1 n'est pertinent qu'au tout début de la transmission. Pour la suite, l'état de la sortie doit être changé sur interruptions périodique s'il n'est pas possible de contrôler finement la chronologie du programme. Toutefois, il faut également récupérer les octets à transmettre puis en extraire un à un les bits à tester, et cela doit, d'une manière ou d'une autre, être réalisé au même rythme que ces interruptions.
Selon l'organisation du code, ces opérations peuvent être menées dans des fonctions appelées suffisamment souvent depuis le programme principal (polling), ou bien dans la même routine d'interruption.
Si la source des octets à transmettre ne peut pas être synchronisée avec l'émission, il faudra intercaler un tampon d'une taille suffisante entre elle et le système de transmission décrit ici.
A quelle vitesse tu souhaites émettre ? ... ça permettra déjà de filtrer les solutions
<< L'histoire nous apprend que l'on apprend rien de l'histoire. >>
Bonsoir,
En effet mais si la solution soft est peut être pertinente à 2400 bds mais elle ne l'est sans doute plus à 115200 bds donc entre du soft(qui merdera après trois ou 4 évolutions du projet) et le rajout d'une 1G86 il n'y a pas photo!
Avec un AtXXX en émission c'est basique car en mode synchrone l'USART sort data et clock parametrable , interruption tous les octets au lieu de 2 fois par bit.
JR
l'électronique c'est pas du vaudou!
Je ne trouve pas pertinent de partir du principe que les développeurs soft ne sont pas suffisamment compétents, que l'application est trop exigeante et que le µC choisi est sous-dimensionné.
Pour ma part, j'ai déjà développé des circuits de codage et décodage Manchester à base de µC tournant à seulement 8 MHz, de façon indépendante (avec des solutions logicielles différentes) pour des transmissions jusqu'à 250 kbit/s sur des applications légères et pour des transmissions à 1200 bits/s sur des applications lourdes. Ces applications ont connu des évolutions ou des variantes sans que cela pose de problème anormalement complexe ni insurmontable. Certaines utilisaient le seul USART disponible pour un autre usage.
Il n'y a donc pas de raison de rejeter a priori les différentes solutions purement logicielles. Ce que je dis, c'est qu'il faut voir : dans tout projet, on doit d'abord évaluer les besoins et les moyens avant de faire des choix techniques.
Bonsoir,
J'ai fais çà pendant plus de 40 ans et au final le hard c'est plus sur car totalement "idiot proof".
JR
l'électronique c'est pas du vaudou!
Bonjour,
Hard contre soft ? Il y a bien des manières pour tondre un œuf. Considérer a priori qu'il n'y a qu'une seule solution qui convienne c'est oublier le problème. Si le micro contrôleur permet de le faire en hard sans se priver de fonctionnalités nécessaires, c'est vraisemblablement la meilleure solution (au moins sur l'aspect économique). Une solution pleinement logicielle peut être envisagée aussi mais elle présentera des contraintes de régularité qui s'imposeront aux autres actions programmées (je suppose que la finalité ne s'arrête pas à la seule gestion du code Manchester). La solution hard externalisée libère le uC ce qui peut être intéressant si celui-ci a beaucoup à faire (si le codage hard est très simple le décodage n'est pas aussi facile car nous n'avons plus l'horloge qu'il faut récupérer dans le signal - Manchester garde heureusement une raie).
En résumé, la solution optimale sera choisie selon le contexte global du projet (que nous ne connaissons pas) et non la seule gestion du code.
Salutations
