RS232 flow control en handshaking
Flow control, inleiding
Ga er eens vanuit, dat je samen met iemand appels plukt. Jouw helper is in de boom geklommen en gooit de appels naar je toe. Je vangt ze op en legt ze in een emmer. In de normale situatie kun je gemakkelijk alle appels vangen, maar wanneer een emmer vol raakt moet die worden verwisseld voor een leeg exemplaar. Dat kost meer tijd dan er tussen twee appels zit die vanuit de boom naar beneden worden geworpen.
Er kunnen nu twee dingen gebeuren. Je helper stopt tijdelijk tot er een nieuwe emmer is, of een aantal appels raakt beschadigd omdat ze op de grond vallen in de korte periode dat je niet in staat bent ze op te vangen.
Ongetwijfeld gaat de voorkeur uit naar de eerste methode waarbij de helper voor een korte periode stopt met toewerpen van nieuwe appels. Om hiervoor te zorgen is er een bepaalde vorm van communicatie, oog contact, een schreeuw, of iets dergelijks om hem te laten stoppen met het werpen van nieuwe appels. Hoe eenvoudig, maar is het altijd zo eenvoudig? Beschouw nu de situatie waarbij een computer informatie verzendt naar een ander apparaat via een seriële verbinding. Zo nu en dan moet de ontvanger bepaalde acties uitvoeren, zoals bijvoorbeeld het wegschrijven van zijn ontvangstbuffer naar disk. Tijdens deze periode kan geen nieuwe informatie worden ontvangen. Enige communicatie terug naar de zender is noodzakelijk om de stroom van bytes op de lijn tijdelijk te stoppen. Een methode moet aanwezig zijn om de zender te laten pauzeren. Om dit te kunnen doen zijn zowel software- als hardware protocollen gedefiniëerd.
Software flow control
Zowel software als hardware flow control hebben software nodig om de handshaking taak uit te voeren. Hierdoor is de term software flow control misleidend. Wat bedoeld wordt is, dat bij hardware flow control extra lijnen in de kabel aanwezig moeten zijn voor het doorgeven van handshaking condities. Met software flow control dat ook bekend staat onder de term XON-XOFF flow control gebeurt het signaleren door bytes te zenden over het standaard communicatie kanaal.
Het gebruik van hardware flow control impliceert, dat meer lijnen aanwezig moeten zijn tussen de zender en ontvanger, waardoor een dikkere en dus duurdere kabel noodzakelijk is. Daarom is software flow control een goed alternatief als niet het uiterste in performance wordt geeist. Software flow control maakt gebruik van het standaard communicatie kanaal tussen de beide apparaten waardoor de bandbreedte enigszins wordt gereduceerd. De reductie in bandbreedte valt in de meeste situaties echter wel mee en meestal is het geen reden om daarom software flow control niet te gebruiken.
Twee bytes zijn voorgedefiniëerd in de ASCII karakter set om gebruikt te worden voor software flow control. Deze bytes hebben de namen XOFF en XON meegekregen, omdat ze in staat zijn het versturen van informatie af te schakelen, respectievelijk weer te activeren. De byte waarde voor XOFF is 19. Dit karakter kan gesimuleerd worden door Ctrl-S te drukken op het toetsenbord. XON heeft de waarde 17 toegewezen gekregen wat equivalent is aan Ctrl-Q.
Het gebruik van software flow control is eenvoudig. Als het verzenden van karakters door het andere apparaat moet worden uitgesteld wordt het karakter XOFF verzonden over de lijn, terwijl voor het herstarten het karakter XON wordt gebruikt. Het versturen van het XOFF karakter stopt alleen de communicatie in de richting van het apparaat dat het XOFF commando geinitiëerd heeft.
Deze methode heeft enkele nadelen. Een daarvan is al genoemd: het gebruik van bytes in het communicatiekanaal neemt bandbreedte in beslag. Een andere reden is ingrijpender. Flow control wordt meestal gebruikt om overloop van ontvangstbuffers te voorkomen, de ontvangstbuffer is het stuk geheugen in het ontvangende apparaat dat tijdelijk wordt gebruikt voor opslag van serieel binnenkomende gegevens. Als een overloop optreedt beïnvloedt dit de wijze waarop nieuw binnenkomende karakters worden behandeld. In het slechtste geval, als de software slecht ontworpen is, worden nieuwe karakters eenvoudig weggegooid zonder de waarde te controleren. Als een dergelijk karakter een XOFF of XON is, kan de stroom van informatie behoorlijk worden beschadigd. De zender zal continu nieuwe informatie sturen als een XOFF karakter verloren is gegaan, of nooit meer starten met zenden als een XON niet is ontvangen.
Dit geldt ook voor communicatie verbindingen waarbij de signaal kwaliteit slecht is. Wat gebeurt er als een XOFF of XON melding niet ontvangen wordt omdat er storing op de lijn aanwezig is? Speciale voorzorgen zijn bovendien ook noodzakelijk als de te versturen informatie van nature al de XON en XOFF karakters bevat.
Daarom is seriële communicatie met software flow control alleen acceptabel wanneer de communicatie snelheden niet te hoog zijn en de kans dat buffers overlopen of signaal verstoring optreedt minimaal is.
Hardware flow control
Hardware flow control is superieur in vergelijking met software flow control dat gebruik maakt van de XON en XOFF karakters. Het grote probleem is, dat een extra investering noodzakelijk is. Extra lijnen zijn noodzakelijk in de communicatiekabel om de handshaking informatie over te transporteren.
Hardware flow control wordt soms ook RTS / CTS flow control genoemd. Deze term slaat op de extra input en outputs die gebruikt worden op de seriële poort om voor deze vorm van handshaking te zorgen. RTS / CTS handshaking wordt in zijn originele vorm gebruikt tussen een computer en een daarop aangesloten apparaat zoals een modem.
Als eerste zet de computer zijn RTS lijn om aan te geven aan het aangesloten apparaat dat er informatie gereed staat voor verzending. Het apparaat controleert of er bufferruimte is, en als dat zo is wordt de CTS lijn gezet om de communicatie te starten. Bij een nulmodem configuratie is dit iets anders. Er zijn in die situatie twee soorten handshaking mogelijk.
Bij één methode wordt de RTS van elke zijde verbonden met de CTS van de andere zijde. In dat geval wordt het communicatie protocol iets anders dan bij de originele opzet. De RTS output op computer A signaleert nu namelijk dat A toestaat dat er gegevens toegezonden worden, terwijl het in de oude configuratie betekende dat A iets te verzenden had. Dit type communicatie kan worden uitgevoerd met een nulmodem kabel geschikt voor volledige handshaking. Hoewel het gebruik van deze kabel niet volledig compatible is met de originele manier waarop hardware flow control is ontworpen geeft het de hoogst mogelijke snelheid mits de software goed ontworpen is omdat het vraag antwoordspel van de RTS en CTS lijn ontbreekt.
In de tweede situatie van nulmodem communicatie met hardware flow control lijkt de software kant grotendeels op de software voor de oorspronkelijke definitie. De CTS en RTS lijnen zijn nu op elke poort naar zichzelf teruggelust. Dit betekent, dat een apparaat zijn eigen RTS signaal beantwoordt op de CTS ingang. Zo gauw de RTS uitgang hoog wordt komt ook de CTS ingang op dezelfde poort op. Dit impliceert dat er altijd informatie zal worden verzonden, zogauw er door een poort een verzoek tot zenden wordt gedaan, mits er geen verdere controle plaatsvindt. Om te voorkomen dat dit optreeft worden ook twee andere pinnen op de connector gebruikt, namelijk de data set ready DSR en data terminal ready DTR. Deze twee lijnen geven aan of het betreffende apparaat goed werkt en bereid is data te ontvangen. Wanneer deze lijnen kruislings zijn aangesloten (zoals in de meeste nulmodem kabels) kan flow control worden uitgevoerd met deze lijnen. Een DTR output wordt gezet door een computer, als die bereid is informatie te ontvangen.
|
If you don't care where you are, you ain't lost.
RUNE'S RULE
|