Si vous utilisez un protocole asynchrone ordinaire (UART), avec un bit de début au début de chaque octet, une méthode simple consiste à utiliser un multivibrateur monostable (même le redouté 555) réglé sur la durée d'un octet plus le bit de début et environ la moitié du bit d'arrêt, et utilisez-le pour activer le pilote de transmission.

Si le multivibrateur est redéclenchable, vous devez attendre jusqu'à un octet complet à partir de la fin d'une transmission avant que quiconque else peut transmettre, car le multivibrateur peut avoir été redéclenché par le dernier bit de données s'il s'agissait d'un zéro.

Sinon, il devrait s'éteindre au milieu de chaque bit d'arrêt, puis se déclencher à nouveau le prochain bit de départ.

Eh bien, "bien" est un terme vague, mais vous avez dit "bon marché" ...

La solution la plus simple à cela que j'ai vue et testée moi-même est d'utiliser un transistor PNP et un réseau RC . L'exemple suivant est destiné à 9600 bauds, donc une résistance de 22k et un condensateur 1n5 sont utilisés. Ces valeurs seraient modifiées pour différents débits en bauds.

Ce n'est en aucun cas une solution élégante, mais elle est simple et peut être construite à partir du bac de pièces.

Voici le schéma:

^{simuler ce circuit - Schéma créé à l'aide de CircuitLab}

Votre meilleur pari serait probablement d'utiliser un petit microcontrôleur (probablement avec un UART, bien que le bit-banging logiciel puisse suffire) qui prend un signal "data in" et génère à la fois "data out" et "transmission enable". Vous devriez probablement avoir une interruption déclenchée par un front sur la broche "data in" qui affirme votre signal "data out" avant même qu'un octet n'ait été entièrement reçu, de sorte que dès que l'octet complet est reçu, vous pouvez commencer à le transmettre (c'est normalement une bonne idée pour affirmer la validation de transmission un peu avant que la transmission ne commence réellement). Après un certain temps sans front descendant ni caractère complètement reçu, désactivez la broche d'activation de transmission.

L'approche ci-dessus introduirait un délai d'un temps de caractère complet entre le moment où le processeur reçoit données et quand il sort le fil. Dans certains cas, il peut être souhaitable de réduire ce temps. Pour ce faire, il faudrait utiliser un logiciel bit-bang UART au lieu d'un matériel UART. Obtenir la synchronisation correcte à des débits binaires plus élevés serait difficile, mais on pourrait avoir un contrôle beaucoup plus fin sur la synchronisation des données entrantes et sortantes.

J'ai vu un circuit qui a probablement résolu ce problème. Le CPU était un esclave sur le RS485 et était donc normalement en mode réception en attente du message d'identification correct, après quoi il transmettrait sa réponse. La puce RS485 a été activée pour la transmission par le front avant du 1er bit dans la réponse de données provenant du CPU lors de la réponse. Une diode, un condensateur et une résistance agencés pour activer rapidement la puce en mode émission, et des transitions de données successives la maintiennent en mode émission. À la fin de la transmission, le capuchon se déchargerait à travers la résistance et après quelques dizaines de millisecondes, la puce revenait en mode réception.

Il y a deux problèmes avec cela - le premier bit transmis était légèrement court d'environ 10% et cela peut vous causer des problèmes. Je suis sûr qu'un meilleur circuit pourrait être développé, mais il y aura toujours un raccourcissement du 1er bit car celui-ci est utilisé pour "détecter" un signal de transmission et permettre au RS485 de transmettre. Le deuxième problème est que le circuit de validation de transmission est resté actif pendant quelques dizaines de millisecondes après la fin de la transmission depuis l'esclave et cela empêche bien sûr le maître d'interroger un autre esclave pendant cette période.

Si ces "issues" c'est OK alors pas de problème, ça fonctionnera

Je cherchais une solution similaire mais j'avais besoin d'un timing très précis car le bus fonctionne à 90% de sa capacité. Je ne pouvais pas me permettre d'avoir plus d'un demi-peu de longueur de dépassement. Je dois désactiver de manière fiable le Tx dans les 2uS de la fin du bit d'arrêt.

Ma solution consistait à utiliser une bascule de type S / RD pour verrouiller le bit de démarrage, puis l'enfoncer dans une puce de synchronisation LTC ( LTC6994), ceux-ci fournissent une précision de 3% au débit en bauds dont j'avais besoin de 230 kbps. La sortie de la puce de synchronisation entraîne la réinitialisation sur le type D.