Comment trouver la ligne UART est gratuit pour envoyer des données

J'ai plusieurs cartes qui communiquent avec Rs485. Ils ont des ATMegamicrocontrôleurs en série tels que atmega168pou atmega8. Chaque carte est libre d'envoyer des données à tout moment et j'ai des limitations qui conduisent à ne pas utiliser Modbus . Le nombre de cartes peut varier de 5 à 10.

Mon problème est le suivant: comment une carte peut-elle déterminer si la ligne UART est libre d'envoyer des données et si elle détecte que le bus est occupé, attendre que le bus soit libre , puis envoyer ses propres données?

Y a-t-il un drapeau ou un registre spécial qui pourrait le changer automatiquement ou manuellement et laisser l'autre carte trouver que la ligne est occupée ?

Bienvenue dans le plus grand défi des systèmes de communication semi-duplex.

RS-485 n'est pas un protocole, c'est une norme qui définit les propriétés électriques d'une liaison différentielle semi-duplex (*). Il n'y a rien dans la spécification sur la façon dont les données doivent être envoyées sur ce lien, ou en fait sur la façon dont le lien est utilisé.

Comme ces émetteurs-récepteurs RS-485 n'ont pas de signal / indicateur / "ligne occupée" automatique, ni les microcontrôleurs qui ont des pilotes RS-485 intégrés, ni ceux qui utilisent un noyau UART connecté à un émetteur-récepteur externe.

Toute implémentation du contrôle de flux et du contrôle de direction est laissée au protocole que vous utilisez. Il existe plusieurs protocoles bien connus qui utilisent des pilotes RS-485, tels que Modbus. Vous pouvez également implémenter n'importe quel protocole auquel vous pouvez penser.

Pour vous aider, voici quelques idées de protocoles:

1. Vous avez un protocole de type maître-esclave. En cela, il y a un nœud maître qui coordonne le bus et des nœuds esclaves qui ont chacun un identifiant unique.

   Les nœuds esclaves ne sont pas autorisés à envoyer de données tant que le nœud maître n'envoie pas spécifiquement les commandes qui leur sont adressées. Une fois qu'un esclave est adressé, il peut alors répondre à n'importe quelle commande d'une manière prédéfinie - par exemple, un paquet de réponse de longueur fixe.

   Dans ce cas, vous évitez les problèmes de plusieurs appareils voulant parler en même temps car le maître est là pour tout coordonner.

2. Vous pouvez utiliser une forme de planification selon laquelle chaque périphérique sur le bus dispose d'un emplacement fixe dans lequel envoyer des données à tout autre périphérique. Une fois que son emplacement est épuisé, il doit arrêter d'envoyer et permettre au prochain appareil de parler.

   L'ordonnancement pourrait être fait par les appareils eux-mêmes sans coordination externe. Le premier appareil parle, puis envoie un message disant que c'est fait. Le prochain appareil (par exemple, celui avec le prochain ID supérieur) saurait alors qu'il pourrait fonctionner. Dans le cas où un appareil ne répond pas, vous pourriez avoir un certain délai pendant lequel chaque appareil suivant dans le calendrier pourrait dire - eh bien, je n'ai pas entendu parler de l'appareil avant moi depuis un moment, donc ce doit être mon tour.

(*) Je crois qu'il définit également une version full-duplex utilisant deux liaisons différentielles.

C'est très similaire à la communication radio de l'armée ou de la police. Un protocole est requis. Le maître esclave est facile et bon dans la plupart des cas. Mais une autre option est de le faire comme le font les humains:

1. Ecoutez.
2. Si quelqu'un parle, attendez.
3. Si vous pensez que personne ne parle, vous pouvez parler.
4. Attendez la confirmation.
5. Si aucune confirmation n'a été reçue, parlez à nouveau.
6. Si vous souhaitez diffuser, demandez à toutes les stations de confirmer l'écoute.
7. Si vous voulez parler à quelqu'un qui ne vous entend pas, demandez s'il y a quelqu'un d'autre qui peut relayer.

Etc. Peut être très intéressant à mettre en œuvre. Bonne chance!

Voici quelques possibilités pour résoudre votre dilemme.

1. Implémentez un système de passage de jetons. Lorsqu'un appareil possède le jeton, il est autorisé à transmettre pendant une période de temps limitée. Il transmet ensuite le jeton au périphérique suivant. Des dispositions doivent être prises pour les nœuds manquants qui ne peuvent pas recevoir et transmettre le jeton.
2. Regardez la ligne de réception. S'il est occupé, générez un retard aléatoire et réessayez. Le retard aléatoire permet de garantir qu'aucun nœud ne peut monopoliser les fenêtres de transmission. Des collisions peuvent toujours se produire mais une fonction de somme de contrôle peut déterminer si le paquet reçu est intact. S'il n'est pas intact, le récepteur peut demander une retransmission.

Comment une carte peut-elle trouver si la ligne UART est libre d'envoyer des données,

la réponse générale est que sans une sorte de protocole, il ne peut pas le faire de manière fiable. vous comptez généralement sur un contrôleur ou un arbitre pour voir si une ligne est occupée ou non. Un simple serait une broche OD tirant une ligne d'indicateur vers le bas avant la transmission et la relâchant ensuite. En lisant cette ligne, un émetteur peut déterminer si le bus est disponible ou non.

un système moins fiable mais plus simple consiste à intégrer la tension du bus (via le réseau ar / c par exemple).

et s'il détecte que le bus est occupé, attendez que le bus soit libre puis envoyez ses propres données?

l'approche générale consiste à attendre une période de temps aléatoire et à réessayer.

Je résous ce problème avec mes conceptions comme celle-ci:

à la place, en utilisant 2 broches pour la communication, j'utilise 3 broches. Sur de courtes distances, cela fonctionne. La troisième broche est l'indicateur de ligne occupée. Cette broche est tirée du côté maître. Quand quelqu'un (MCU ou autre) veut parler:

• vérifie cet état de broche (INPUT).
• si la broche est ÉLEVÉE, la broche devient basse (SORTIE)
• et des discussions.
• Lorsque le message est transféré, la broche (INPUT) (haute impédance) est relâchée, puis la broche passe à l'état haut.
• Si la broche est basse, elle attend un certain temps puis revient pour vérifier le cycle de la broche.

Ceci est une implémentation de la réponse de Gregory Kornblum.

Vous pouvez utiliser la pile de protocoles BACnet open source pour la communication du microcontrôleur sur RS485 si vous ne souhaitez pas utiliser le modbus. Essentiellement, il transmet simplement un jeton qui indique à chaque périphérique quand il peut envoyer, similaire à la topologie en anneau à jeton et Ethernet. Voici quelques liens pour vous aider à démarrer:

http://www.chipkin.com/bacnet-mstp-installation-rs485-and-cables/ http://bacnet.sourceforge.net/

Contrôle de flux logiciel

Le contrôle de flux logiciel et matériel nécessite un logiciel pour effectuer la tâche de négociation. Cela rend le terme contrôle de flux logiciel quelque peu trompeur. Cela signifie qu'avec le contrôle de flux matériel, des lignes supplémentaires sont présentes dans le câble de communication qui signalent les conditions de l'établissement de liaison. Avec le contrôle de flux logiciel, également connu sous le nom de contrôle de flux XON-XOFF, les octets sont envoyés à l'expéditeur via les lignes de communication standard.

L'utilisation du contrôle de flux matériel implique que davantage de lignes doivent être présentes entre l'expéditeur et le récepteur, ce qui conduit à un câble plus épais et plus cher. Par conséquent, le contrôle de flux logiciel est une bonne alternative s'il n'est pas nécessaire pour obtenir des performances maximales dans les communications. Le contrôle de flux logiciel utilise le canal de données entre les deux appareils, ce qui réduit la bande passante. La réduction de la bande passante n'est cependant pas si étonnante dans la plupart des cas que c'est une raison pour ne pas l'utiliser.

Deux octets ont été prédéfinis dans le jeu de caractères ASCII à utiliser avec le contrôle de flux logiciel. Ces octets sont nommés XOFF et XON, car ils peuvent arrêter et redémarrer la transmission. La valeur d'octet de XOFF est 19, elle peut être simulée en appuyant sur Ctrl-S sur le clavier. XON a la valeur 17 attribuée qui est équivalente à Ctrl-Q.

L'utilisation du contrôle de flux logiciel est facile. Si l'envoi de caractères doit être différé, le caractère XOFF est envoyé sur la ligne, pour relancer la communication, XON est utilisé. L'envoi du caractère XOFF arrête uniquement la communication en direction de l'appareil qui a émis le XOFF.

Cette méthode présente quelques inconvénients. L'un est déjà discuté: l'utilisation d'octets sur le canal de communication occupe une certaine bande passante. Une autre raison est plus grave.

La négociation est principalement utilisée pour empêcher un dépassement de la mémoire tampon du récepteur, la mémoire tampon utilisée pour stocker les octets récemment reçus. Si un dépassement se produit, cela affecte la façon dont les nouveaux personnages sur le canal de communication sont traités. Dans le pire des cas où le logiciel a été mal conçu, ces personnages sont jetés sans les vérifier. Si un tel caractère est XOFF ou XON, le flux de communication peut être gravement endommagé. L'expéditeur fournira en continu de nouvelles informations si le XOFF est perdu, ou n'enverra jamais de nouvelles informations si aucun XON n'a été reçu.

Cela vaut également pour les lignes de communication où la qualité du signal est mauvaise. Que se passe-t-il si le message XOFF ou XON n'est pas reçu clairement à cause du bruit sur la ligne? Une précaution particulière est également nécessaire pour que les informations envoyées ne contiennent pas les caractères XON ou XOFF comme octets d'information.

Par conséquent, la communication série utilisant le contrôle de flux logiciel n'est acceptable que lorsque les vitesses de communication ne sont pas trop élevées et que la probabilité de dépassements de tampon ou de dommages aux données est minime.

CSMA haute vitesse

Pour la détection de porteuse CSMA à haute vitesse comme Ethernet , l'accès multiple, la détection / évitement des collisions, avec des temporisateurs de coupure aléatoire ont été analysés pour déterminer le débit de probabilité stochastique d'optimisation.