Full Circle Magazine FR

In the last issue, I showed you how to dim an LED with a potentiometer. In this issue, we will read the values of the potentiometer using the analog-to-digital conversion (ADC), and send these values to a serial console. This time, we need additional hardware – a USB-to-serial adapter (it is advised not to use the serial port on your computer as damage may occur to the microcontroller because of high voltage from the computer serial port). Many USB-to-serial adapters will work. Common chipsets are CH340, CP210x, FTDI, PL2303, but any other chipset will work as well. Importantly, they must provide voltages at 3V or 5V, and a Linux driver. It would also be useful if the USB-to-serial adapter is ‘breadboard friendly’, which means it has pins to connect to it, whether directly or through cables, to the breadboard. You could use an Arduino as a usb-serial adapter, see https://oscarliang.com/use-arduino-as-usb-serial-adapter-converter/ for more information.

Dans le dernier numéro, je vous montrais comment faire varier la luminosité d'une LED avec un potentiomètre. Dans ce numéro, nous lirons les valeurs du potentiomètre en utilisant une conversion analogique/digitale (ADC), et enverrons ces valeurs à une console série. Cette fois-ci, nous avons besoin d'un matériel supplémentaire : un adaptateur USB-vers-série (il est conseillé de ne pas utiliser le port série de votre ordinateur car des dommages peuvent affecter le microcontrôleur à cause de la tension élevée sur le port série de l'ordinateur).

Beaucoup d'adaptateurs USB-vers-série conviendront. Les circuits classiques sont les CH340, CP210x, FTDI, PL2303, mais beaucoup d'autres fonctionneront aussi. Il est important qu'ils puissent fournir une tension de 3 V ou de 5 V et disposent d'un pilote pour Linux. Il serait bien aussi que l'adaptateur USB-vers-série soit fait pour une plaque d'essai, ce qui signifie qu'il doit avoir des picots pour les connexions à la plaque d'essai, soit directement, soit avec des fils. Vous pouvez utiliser l'Arduino comme adaptateur USB-vers-série ; regardez https://oscarliang.com/use-arduino-as-usb-serial-adapter-converter/ pour plus d'information.

Serial communication and hardware A serial communication means that a byte of data is sent bit-by-bit through a dedicated receiving and transmitting line. See the end of this article for more basics of serial communications. For the program flow, it is further important if the communication is blocking (the program must halt until the data is fully received or transmitted) or non-blocking (the data is buffered and the program need not halt until data is transmitted or received, then the data would be processed). Some microcontrollers have a Universal Synchronous and Asynchronous Receiver-Transmitter (USART) implemented. The ATmega328p (the one on the Arduino UNO R3) for example has a USART on PIN2 for receiving and PIN3 for sending serial data.

Communication série et matériel

Dans une communication série, les octets de données sont envoyés bit par bit sur une ligne dédiée de réception et de transmission. Voyez en fin d'article d'autres informations de base sur les communications série.

Pour le déroulement du programme, il est important de savoir, pour la suite, si la communication est bloquante (le programme s'arrête jusqu'à ce toutes les données soient reçues ou émises) ou non bloquante (les données sont en mémoire tampon et le programme n'a pas besoin de s'arrêter jusqu'à la bonne fin de réception ou d'émission des données ; ensuite, les données seront traitées). Un émetteur-récepteur universel synchrone et asynchrone (USART - Universal Synchronous and Asynchronous Receiver-Transmitter) est implémenté sur certains microcontrôleurs. Le ATmega328p (celui de l'Arduino UNO R3), par exemple, a un USART sur PIN2 en réception et PIN3 en émission des données série.

Great Cow BASIC has a solution to get the hardware USART to work with a few lines of code. Additionally, Great Cow BASIC supports some functions to send and receive data in different data types. See the Great Cow BASIC help for more information, but, to use the USART in the ATmega328p, and send some data, you would start with the following lines. (In real life you would, of course, send more meaningful data): Setup the Hardware USART for Serial operations An example of using the hardware USART in the ATmega328p is shown on the previous page.

Great Cow BASIC a une solution pour faire fonctionner l'USART matériel avec quelques lignes de code. De plus, il dispose de fonctions pour envoyer et recevoir différents types de données. Voyez l'aide de Great Cow BASIC pour plus d'information, mais, pour utiliser l'USART du ATmega328p et envoyer quelques données, vous commenceriez avec les quelques lignes qui suivent. (Dans la vraie vie, vous enverriez, bien sûr, des données plus significatives).

Paramétrer l'USART matériel pour des opérations série

Un exemple de l'utilisation de l'USART matériel du ATmega328p est présenté sur la page précédente.

Setup for Serial operations using Software Some microcontrollers do not have a hardware USART; which is true for the ATtiny13a I am using for these examples. Another reason could be the need of an additional serial connection without changing the microcontroller. In order to receive and send data, the serial communication could be achieved in software as well. For me, this would be quite a hard task to program, but, luckily, Great Cow BASIC has two methods for serial communication. For comparison, I will provide an example for each, and observe the differences in the two methods. Great Cow BASIC also has two methods for Serial operations using software, and these are both shown below. For simplicity, I provide the examples for sending values over the serial line. If you want to receive data, go right ahead and add the few missing lines of code.

Paramétrer des opérations série en utilisant le logiciel

Certains microcontrôleurs n'ont pas d'USART matériel, ce qui est le cas du ATtiny13a que j'utilise pour ces exemples. Une autre raison pourrait être le besoin d'une liaison série supplémentaire sans changer de microcontrôleur. De façon à recevoir et envoyer des données, la communication série peut aussi être réalisée par logiciel. Pour moi, la programmer serait un gros travail, mais, par chance, Great Cow BASIC a deux méthodes pour les communications série. Pour comparer, j'ai fourni un exemple de chaque, et observé les différences des deux méthodes. Great Cow BASIC a aussi deux méthodes pour les liaisons séries par logiciel et les deux sont présentées ci-dessous. Pour la simplicité, je fournis les exemples pour l'envoi des valeurs par la liaison série. Si vous voulez recevoir des données, poursuivez en ajoutant les quelques lignes de code manquantes.

Option 1 - ‘Legacy Software Serial Method’: This legacy method was implemented in 2007 - and is a popular method for software serial operations. This method (top right) can handle up to three different serial lines, with baud rates between 300 and 19,200.

Option 1 - « Méthode série par logiciel hérité »

Cette méthode héritée a été implémentée en 2007, et c'est une méthode populaire pour les opérations série par logiciel. Cette méthode (en haut à droite) peut gérer jusqu'à trois lignes séries différentes, avec des vitesses de transmission entre 300 et 19 200.

Option 2 - ‘Optimised Method’: This method (bottom right) uses an additional library for Great Cow BASIC from Frank Steinberg, and is an optimised software serial driver written in portable assembler. Portable assembler means this optimised method supports AVR and PIC microcontrollers. This method provides higher baud rates (eg: an AVR clocked at 1 MHz can handle up tp 28.800 baud), and the program generated is small enough to fit on the tiny13a microcontroller. If you compare the code examples, keep in mind that the ATMega328p on the Arduino comes with a 16 MHz Resonator, so the system clock is at 16 MHz. The ATtiny13a comes with a 9.6 MHz integrated systems clock; but, by default, the clock is divided (read: limited) by 8 to a mere 1.2 MHz. To change that, it would be necessary to change the fuses, which I did not want to do in this set of articles – I wanted to keep things simple.

Option 2 - « Méthode optimisée »

Cette méthode (en bas à droite) utilise une bibliothèque complémentaire pour Great Cow BASIC, de Frank Steinberg, et c'est un pilote logiciel série optimisé écrit en assembleur portable. « Assembleur portable » signifie que cette méthode optimisée supporte les microcontrôleurs AVR et PIC. Cette méthode fournit une vitesse de transmission plus élevée (par ex., un AVR tournant à 1 MHz peut gérer jusqu'à 28 800 bauds) et le programme généré est assez petit pour tenir dans le microcontrôleur tiny13a.

Si vous comparez les exemples de code, gardez en tête que l'ATMega328p sur l'Arduino vient avec un résonateur de 16 MHz ; aussi, l'horloge système est de 16 MHz. Le ATtiny13a vient avec une horloge système intégrée de 9,6 MHz ; mais, par défaut, l'horloge est divisée ((lire : limitée) par 8 à un pauvre 1,2 MHz. Pour la changer, il est nécessaire de remplacer les fusibles, ce que je ne veux pas faire dans cette série d'articles ; je veux garder les choses simples.

Software prerequisites to work with the serial adapter If you did not have to use a serial adapter, nor serial terminal software, on your computer, here are some brief explanations to get the serial communication to work. The chances are good that your computer has the necessary drivers right out-of-the-box: Plug in your serial adapter to your USB-Port, and type: dmesg | grep tty You should see a line like this: […] usb 6-2: cp210x converter now attached to ttyUSB0 Now, you know the chipset of your adapter is supported (in my case it is a cp210x), and it was assigned as device ttyUSB0. Then give your Linux user the permission to use this device. Type: sudo chmod 666 /dev/ttyUSB0

Prérequis logiciels pour travailler avec un adaptateur série

Si vous ne devez utiliser ni un adaptateur série, ni du logiciel pour terminal série, sur votre ordinateur, voici quelques brèves explications pour faire fonctionner une communication série. Il y a de bonnes chances que votre ordinateur ait les pilotes nécessaires intégrés :

Branchez votre adaptateur série au port USB et tapez :

dmesg | grep tty

Vous devriez voir une ligne de ce genre :

[…] usb 6-2: cp210x converter now attached to ttyUSB0 (…convertisseur cp210x maintenant branché sur ttyUSB0)

Maintenant vous savez que le circuit de votre adaptateur est supporté (dans mon cas c'est un cp210x) et qu'il est assigné à ttyUSB0. Ensuite, donnez à votre utilisateur Linux l'autorisation d'utiliser ce dispositif. Tapez :

sudo chmod 666 /dev/ttyUSB0

Give your superuser password if prompted. Then, if you do not have a serial terminal installed, I suggest putty, as it is easy to use and easily installed. A sudo apt install putty is all you need to do. Then start putty and change the serial line to /dev/ttyUSB0, the baud rate according to your chosen one in the microcontroller program (I chose 9600 baud for the examples). Make sure the other parameters of the serial line are correct, scroll down the category tab and look for the entry Serial. Make sure the data, stop, and parity bit settings are correct. The entry flow control is not important for the time being - leave it as is. Then, click ‘Open’ - and you should see the awaited data scrolling along the terminal.

Saisissez votre mot de passe de super-utilisateur, s'il vous est demandé

Ensuite, si aucun terminal série n'est installé, je suggère putty, car il est facile à utiliser et facilement installé. Vous n'avez qu'à faire un sudo apt install putty. Ensuite, lancez putty et modifiez la ligne série pour /dev/ttyUSB0 et la vitesse de transmission pour celle que vous avez choisie dans le programme du microcontrôleur (j'ai choisi 9 600 bauds pour les exemples). Assurez-vous que les autres paramètres de la ligne série sont corrects, descendez jusqu'à l'onglet des catégories et regardez l'entrée Serial (série). Assurez-vous que les paramètres des bits de données, de stop et de parité sont corrects. Le contrôle du flux entrant n'est pas important pour le moment, laissez-le tel quel. Ensuite, cliquez sur « Open », et vous devriez voir les données attendues défilant dans le terminal.

Breadboard circuitry Compile the program and flash it to the ATtiny13a with your hardware programmer of choice. The USB-to-serial adapter should have +5V or +3V, and GND, to power up the microcontroller. Then, hook up the receiving line from the adapter to the sending PIN (PB1) of the ATtiny13a. Hook up the Poti to +5V or +3V, and GND as well, and the middle pin to the PIN ADC2 (PB4).

Circuit de la plaque d'essai

Compilez le programme et flashez-le dans le ATtiny13a avec le programmeur matériel de votre choix. Pour alimenter le microcontrôleur, l'adaptateur USB-vers-série doit avoir du + 5 V ou + 3 V et la masse. Ensuite, reliez la ligne de réception de l'adaptateur au picot d'émission (PB1) du ATtiny13a. Reliez aussi le potar au + 5 V ou + 3 V et à la masse, et le curseur au picot ADC2 (PB4).

Conclusion After some experimentation, it shows that the legacy software serial method produces a program that is large - too large for the tiny13a; The version of my code shown above compiles to 1.016 Bytes. Why is this a problem? First, you have no more program space left for anything else. Second, and more importantly, the readings on the terminal were not human readable as we are limited to the raw values being displayed. I would suggest, if using the legacy serial method, to utilise a microcontroller which has more program flash memory, eg, the ATtiny85.

Conclusion

Après quelques essais, il apparaît que la méthode série du logiciel hérité produit un programme trop gros - trop gros pour le ATtiny13a. Ma version de code présentée au-dessus se compile sur 1 016 octets. Pourquoi est-ce un problème ? D'abord, il ne vous reste plus de place de programme pour autre chose. Ensuite, et c'est plus important, les affichages sur le terminal ne sont pas compréhensibles par l'homme, car nous nous sommes limités à l'affichage des valeurs brutes. Je vous suggère, si vous utilisez la méthode héritée, d'utiliser un microcontrôleur qui a plus de mémoire flash, par ex., le ATtiny85.

But, all is not lost! Serial communication on the ATtiny13a is still feasible. The optimized serial software compiled to around 368 bytes and worked like a charm. With the optimised software, we have a working solution to get serial I/O to work; even with the small program memory device like the ATtiny13a!! Serial communications is an important method for exchanging data. Great Cow BASIC makes the configuration and use very simple. Serial communications is easy - it is useful for debugging and to communicate key messages to the users. It can also be used for inter-microcontroller communications, albeit there are better methods like I2C and SPI.

Mais tout n'est pas perdu ! La communication série avec le ATtiny13a est toujours réalisable. Le logiciel série optimisé est compilé sur environ 360 octets et fonctionne à merveille. Avec le logiciel optimisé, nous avons une solution fonctionnelle pour faire marcher les entrées/sorties série ; même avec un dispositif comme le ATtiny13a et son petit espace mémoire programme !

Les communications série sont une importante méthode d'échange de données. Great Cow BASIC rend très simple leurs configuration et utilisation. Les communications série sont faciles, elles sont utiles pour déboguer et pour communiquer des messages clés aux utilisateurs. Elles peuvent aussi être utilisées pour les communications inter-contrôleurs, bien qu'il y ait de meilleures méthodes comme I2C et SPI.

GitHub Repo Evan Venn (Anobium…my mentor with respect to these articles) suggested to open a GitHub repository for the source code, and, I must admit, this was a good idea. If you want to download the sources instead of copy-pasting it, you can now check it out with git or an SVN client. See https://github.com/Anobium/Great-Cow-BASIC-Demonstration-Sources/tree/master/Publication%20Solutions/Full%20Circle for more information.

Le dépôt Github

Evan Venn (Anobium… mon mentor pour ce qui concerne ces articles) me suggérait d'ouvrir un dépôt Github pour le code source et, je dois l'admettre, c'était une bonne idée. Si vous voulez télécharger les sources plutôt que faire des copier/coller, vous pouvez maintenant le faire avec git ou un client SVN. Pour plus d'information, voyez https://github.com/Anobium/Great-Cow-BASIC-Demonstration-Sources/tree/master/Publication%20Solutions/Full%20Circle

References serial communication https://www.teachmemicro.com/microcontroller-serial-communication/ Acknowledgement I wish to thank Evan Venn (Anobium) from the Great Cow BASIC Team for his insights and valuable hints.

Références

Communications série : https://www.teachmemicro.com/microcontroller-serial-communication/

Remerciements

Je souhaite remercier Evan Venn (Anobium) de l'équipe de Great Cow BASIC pour ses renseignements et ses conseils.

Corrections In the last issue a formula got lost, for completeness:

Corrections

Dans l'article précédent, une formule a été oubliée ; pour être complet :

Serial Comms - A Few Definitions and Notes: by Michael Kennedy and Gord Campbell These notes focus on some of the main features of the common RS-232 implementations, but a few other variations are also mentioned. They’re intended to supplement the story in FCM #130 (etc) on Great Cow BASIC, by Boris. “RS-232” (Recommended Standard 232) is a popular communications system. Originally (1960), it was used for connections with old-style telephone/terminal/typewriter systems. The simplest RS-232 implementations handle two-way communications between just two devices (say, Dev-A and Dev-B). The cabling has just three wires: ground, data pulses going from Dev-A to Dev-B, and data pulses from Dev-B to Dev-A. The cable is normally up to about 15-20 metres, but could be up to a few hundred metres, max. The hardware at both ends could be microcomputers, or dedicated, relatively smart, RS-232 chips, or just suitable line drivers - where the entire implementation is handled in software.

Communications série - Quelques définitions et notes :

par Michael Kennedy et Gord Campbell

Ces notes se concentrent sur quelques fonctionnalités principales des implémentations classiques du RS-232, mais quelques autres variantes sont aussi mentionnées. Elles ont pour but de compléter l'article du FCM n° 130 (etc.) sur Great Cow BASIC, écrit par Boris.

« RS-232 » (Recommended Standard 232 - norme recommandée n° 232) est un système de communication populaire. À l'origine (1960), il était utilisé pour des connexions entre systèmes téléphone/terminal/télétype désuets.

Les implémentations les plus simples du RS-232 gèrent des communications bidirectionnelles entre uniquement deux appareils (disons, DEV-A et Dev-B). Le câblage n'a que trois fils : une masse, des impulsions de données de Dev-A vers Dev-B, et des impulsions de données de Dev-B vers Dev-A. Le câble a normalement une longueur jusqu'à environ 15-20 mètres, mais ça peut aller jusqu'à quelques centaines de mètres, au maximum. Les matériels aux deux extrémités peuvent être des micro-ordinateurs, ou des puces RS-232 dédiées, relativement puissantes, ou juste des pilotes de ligne adaptés, où toute l'implémentation est traitée par logiciel.

The speed of the data-pulses must normally be set, in advance, on both devices, and must be based on how quickly both devices can transmit and receive the pulses, on the cable length and quality, the overall electrical environment, etc. Typically, it might be set at 300 baud, 1,200 baud, 2,400, 4,800, 9,600, 14,400, 19,200, or maybe even up to 115,200 baud and beyond. A “baud” refers to the width of each “bit/pulse” on the cable, so 4,800 baud is 4,800 bits per second. To send a single “byte” from Dev-A to Dev-B: • Dev-B must be ready to accept the byte (obviously!). • Dev-A sends out one “Warning” pulse, called a Start-Bit, to wake up Dev-B! • Dev-A then sends the byte’s bits. Usually eight, but sometimes maybe as few as five are adequate. • Dev-A might send a single Parity bit (Odd/Even/None). • Dev-A sends one, or one-and-half, or two, “Stop”-bits.

La vitesse des impulsions de données doit être pré-positionnée sur les deux dispositifs et doit être basée sur la vélocité de ces deux appareils pour émettre et recevoir des impulsions, sur la longueur et la qualité du câble, l'environnement électrique, etc. Typiquement, elle peut être réglée à 300 bauds, 1 200 bauds, 2 400, 4 800, 9 600, 14 400, 19 200, ou peut-être même jusqu'à 115 200 bauds et au-delà. Un « baud » fait référence à la largeur de chaque « bit/impulsion » sur le câble ; ainsi, 4 800 bauds correspondent à 4 800 bits par seconde.

Pour envoyer un seul octet de DEv-A vers Dev-B : • Dev-B doit être prêt à accepter l'octet (évidemment !) • Dev-A émet une impulsion d'« avertissement », appelé Start-bit (bit de début), pour réveiller Dev-B ! • Ensuite, Dev-A émet les bits de l'octet. Généralement 8, mais parfois aussi peu que cinq sont adéquats. • Dev-A peut envoyer un unique Parity bit (bit de parité - pair, impair, aucun). • Dev-A envoie un, ou un et demi, ou deux, Stop-bits (bits d'arrêt).

So, typically, a single byte might involve the transfer of about 10-12 bits/pulses. And in that case, a speed of 4,800 baud might result in a maximum transfer of about 400-480 bytes per second - assuming there’s no wasted time between each “byte” - which would never be reached in reality! UART: The above approach is termed “Asynchronous”, because there can be an indeterminate amount of time between bytes. The devices are termed UARTs (Universal Asynchronous Receiver and Transmitter). SIMPLEX/DUPLEX: Where data pulses are allowed on only one of the two data-wires at any one time, this is defined as Half-Duplex. If Dev-A may send data to Dev-B, and Dev-B may send data to Dev-A, at the same time, this is Full-Duplex. There’s also a “Simplex” approach, where only one device does all the sending, and the other all the receiving - with just a single “data”-wire, for example, a wireservice sending stories to a newsroom.

Ainsi, typiquement, un simple octet peut correspondre au tranfert de 10-12 bits/implusions. Et dans ce cas, une vitesse de 4 800 bauds permettra un transfert maximum d'environ 400-480 octets par seconde - en supposant qu'il n'y ait pas de temps perdu entre chaque « octet » ce qui ne sera jamais atteint en réalité !

UART : l'approche ci-dessus est qualifiée d'« Asynchrone », car il peut exister un temps indéterminé entre les octets. Les dispositifs sont appelés UART (Universal Asynchronous Receiver and Transmitter - Émetteur/récepteur asynchrone universel).

SIMPLEX/DUPLEX : quand les impulsions de données ne sont autorisées que sur un seul des deux fils de données à tout moment, ceci définit le Half-Duplex. Si Dev-A peut envoyer des données à Dev-B, et Dev-B à Dev-A, en même temps, c'est du Full-Duplex. Il a aussi l'approche « Simplex », où un seul des dispositifs réalise tous les envois, et l'autre, toutes les réceptions avec un seul fil de données, par exemple, un service par câble envoyant des articles à une rédaction de journal.

Further, less common, variations on RS-232… USARTs: Two wires could be used to send data-bits from Dev-A to Dev-B, and two more wires for the data-bits from Dev-B to Dev-A. The second wire (of each pair) contains clock pulses - that match the data-bits on the first wire. Then, the extra Start/Stop bits may not be needed for each byte, and it may not be necessary to “lock” the two devices into matching speeds - because the clock pulses determine the widths of the data-pulses. This approach should result is slightly higher communications speeds and higher quality. The devices at both ends are termed USARTs (Universal Synchronous and Asynchronous Receiver and Transmitter); they can handle both protocols. Additional Control wires: In some implementations, extra wires are used ([D]CD Carrier Detect, RTS Request to Send, CTS Clear to Send, DTR Data Terminal Ready, DSR Data Set Ready, RI Ring Indicator, RTR Ready To Receive, etc), which are used by each device to tell the other device that they are Busy, Ready, Unavailable, etc. Often called “Handshaking” or “Flow-Control” signals.

D'autres variantes, moins courantes, du RS-232

USART : deux fils peuvent être utilisés pour envoyer les bits de données de Dev-A à Dev-B et deux autres pour les bits de données Dev-B vers Dev-A. Le second fil de chaque paire contient des impulsions d'horloge, qui correspondent aux bits de données du premier fil. Ensuite, les bits supplémentaires de début et de fin ne sont pas nécessaires à chaque octet et il n'est sans doute pas nécessaire de bloquer les deux dispositifs sur une même vitesse, car les impulsions d'horloge déterminent la largeur des impulsions de données. Cette approche permet des vitesses de communication légèrement plus élevées et de meilleure qualité. Les dispositifs aux deux bouts sont appelés USART (Universal Synchronous and Asynchronous Receiver and Transmitter - Émetteur/récepteur synchrone et asynchrone universel) ; ils peuvent gérer les deux protocoles.

Fils de contrôle additionnels : dans certaines implémentations, des fils supplémentaires sont utilisés ([D]CD Carrier Detect, RTS Request to Send, CTS Clear to Send, DTR Data Terminal Ready, DSR Data Set Ready, RI Ring Indicator, RTR Ready To Receive, etc.), dont se sert chaque dispositif pour dire à l'autre qu'il est Busy, Ready, Unavailable, etc. (Occupé, Prêt, Indisponible). Ils sont souvent appelés signaux de « Handshaking » (accord manuel) ou de « Flow-Control » (contrôle de flux).

RS-422, Longer cables: Slightly different devices and cabling arrangements can be adopted where longer cable runs, and/or higher speeds, are needed. The cable contains two wires for each of the data-pulses runs, and two more wires for each of the clock-pulses - like standard twisted-pair LAN cables. RS-485, Multiple devices: Different ICs can be deployed where, for example, more than two (maybe 10, 20, 30…) devices can share the same cable(s), and, for example, all of them can talk with a single “server/master” device. Error Handling!: If you’re writing “serial” software, and/or taming serial hardware, for private educational or entertainment purposes, then you probably won’t be over-worried if a few errors arise now-and-then. For example, if you’re sending data, serially, to a display, or controlling a few LEDs, etc, you might chose to not bother if the device is present or not, or powered on, or fully “reset” after a power-on, or ready to send/receive serial data, or that its serial configuration matches ours, or that it’s faulty, or has a hundred other issues….

RS-422, des câbles plus longs : des dispositifs et un arrangement du câblage légèrement différents peuvent être adoptés là où de plus grandes distances de câblage et/ou de plus grandes vitesses sont nécessaires. Le câble contient deux fils pour chaque liaison d'impulsions de données et deux câbles supplémentaires pour chacune des impulsions d'horloge, comme les câbles normaux des réseaux locaux, à paires torsadées.

RS-485, des dispositifs multiples : différents CI peuvent être déployés là où, par exemple, plus de deux dispositifs (voire 10, 20, 30…) peuvent partager le(s) même(s) câble(s) et où, par exemple, ils dialoguent tous avec un dispositif « serveur/maître ».

Gestion des erreurs ! : Si vous écrivez du logiciel « série » et/ou apprivoisez un matériel série, pour des besoins éducatifs ou ludiques, vous n'êtes probablement pas très inquiet si quelques erreurs apparaissent de temps en temps. Par exemple, si vous envoyez des données par liaison série à un afficheur, ou pilotez quelques LED , etc., vous pouvez choisir de ne pas vous préoccuper de savoir si le dispositif est présent ou pas, ou allumé, ou complètement « reseté » après la mise sous tension, ou prêt pour une émission/réception série de données, ou que sa configuration série correspond à la vôtre, s'il est défectueux, ou s'il a une centaine d'autres problèmes…

However, if your RS-232 app is used in an MRI/CAT-scanner, and it’s controlling doses of radiation, positions of motors, etc, and you’re the patient, then you’ll definitely have to handle all of the above conditions! Then, you’ll probably have to use some of the additional hand-shaking signals/wires that I mentioned above, and you’ll probably have to introduce a whole “protocol” and timings to control all your comms. Eg, when a sender/transmitter wishes to send some data to a receiver, then, minimally: • Both devices would use the available control-wires to ensure that both are ready-and-willing to communicate. • Dev-A says: “Hello, I wish to send you an alert/reading… Are you ready, and can you take it now?”. • Dev-B: Yes, send it on. • Dev-A: Here it is….. xxxxx…. • Dev-B: Got that, 123 bytes in total, checksum=xxx, thank you. • Dev-A: Excellent – thank you, over-and-out.

Cependant, si votre appli RS-232 est utilisée dans un scanner à résonance magnétique nucléaire ou un tomographe, et qu'il contrôle les doses de radiation, les positions et les moteurs, etc., et que vous êtes le malade, alors vous devrez réellement gérer toutes les conditions ci-dessus ! Ensuite, vous devrez probablement utiliser certains signaux/câbles d'accord (“hand-shaking”) dont j'ai parlé plus haut et vous devrez probablement définir un « protocole » complet et des séquences temporelles pour maîtriser toutes vos communications. Par ex., quand un émetteur/transmetteur souhaite envoyer des données à un récepteur, alors, au minimum : • Les deux dispositifs devront utiliser les fils de contrôle pour s'assurer que les deux sont prêts et disposés à communiquer. • Dev-A dit : « Hello, je veux vous envoyer une alerte/lecture… Êtes-vous prêt, et pouvez vous recevoir maintenant ? » • Dev-B : « Oui, envoyez-le. » • Dev-A : Le voici, …. xxxxx….. • Dev-B : Bien reçu, 123 octet au total, somme de contrôle = xxxx, merci. • Dev-A : Excellent - merci, terminé.

At all of the above stages: • The sender of each packet might have timeouts running, to check if the transmission choked… • The receiver would have timeouts running, to ensure that the packet arrived on time, and fully… • All those hand-shaking lines would be continually checked, at both ends, to ensure that nobody cut a cable, or switched the power off… • If minor errors arose, retries would probably be attempted, automatically, for a while… • The handling of all major/catastrophic errors would have to be very carefully designed, and implemented, and tested. So, to ring that bell, or turn on that emergency light, or rotate that stepper motor, a single “Print…..” statement might evolve into a very complicated 500-line “LED_On()” function!

À toutes les étapes précédentes : • L'émetteur du paquet doit avoir des limiteurs de temps (timeout) enclenchés, pour vérifier si les transmissions se seraient bloquées… • Le récepteur devrait avoir des timeouts qui tournent, pour s'assurer que le paquet est arrivé dans les temps et complètement… • Toutes les lignes de handshaking devraient être vérifiées continuellement, aux deux bouts, pour s'assurer que personne n'a coupé le câble ou l'alimentation… • Si des erreurs mineures se produisent, des renvois devraient être tentés probablement, automatiquement, pendant un moment… • La gestion des erreurs majeures/catastrophiques devrait être conçue, implémentée et testée.

Ainsi, pour sonner l'alerte, ou allumer une lampe de danger, ou faire tourner un certain moteur pas-à-pas, un simple « Print… » devrait être remplacé par une fonction « LED-On() » de 500 lignes !

Finally: For lots of good, general, details, see: https://en.wikipedia.org/wiki/RS-232. And do check all the other 18,000,000 websites If you’re implementing RS-232 comms on a specific device (UART, uP, CPU, etc), then look up the details in the manufacturer’s datasheets of those devices. Normally, the devices will work exactly as per the specs. However, if you’re stressing the devices, and/or writing low-level drivers, etc, you might sometimes observe “inexplicable” results. When stressed, some of these devices have nasty bugs, so you should run some web searches, and, hopefully, others will have posted explanations and suggestions. Good Luck! Michael Kennedy and Gord Campbell

Pour terminer : voyez de nombreux et bons détails généraux sur : https://fr.wikipedia.org/wiki/RS-232. Et jetez un œil aussi aux 18 000 000 d'autres sites Web

Si vous implémentez des communications RS-232 sur un dispositif particulier (UART, uP, CPU, etc), alors regardez les détails des datasheets des constructeurs des matériels. Normalement, les dispositifs fonctionnent exactement comme les spécifs. Cependant, si vous contraignez les dispositifs, ou si vous écrivez des pilotes de bas niveau, etc., vous pourriez observer parfois des résultats « inexplicables ». Quand on contraint les dispositifs, certains défauts désagréables peuvent apparaître ; aussi, vous devrez pratiquer quelques recherches sur le Web où - on peut l'espérer - d'autres gens auront posté des explications et des suggestions.

Bonne chance !

Michael Kennedy et Gord Campbell