Názory k článku
Komunikace pomocí sériového portu RS-232C podruhé

Mám pocit že na RS-232C je již troch pozdě...

rozhodne neni,
usb na 50m? :-D
rs232 na 50m? pohoda

SW reseni rs232? umi maly dite
usb ovladani ? pokud je sw emulovany rs232 -da se,ale jinak?....ups od APC :-D HID- ani jsem se radi nezajimal jak ovladat HID -proste ke kazdemu zarizeni co se da do usb googlit jen jaky ovladace musi clovek nainstalovat aby se spojily natoz se ucit protokol.....

RS232 jen tak nevymre - pro pripojeni modemu umrelo s polecne s modemem,ale pro profesionalni nasazeni zije spolecne s RS485 a RS422 a dlouho zit bude

Opticky oddelovac nepomuze? ;-)

Není to zcela pravda. délka kabelu u RS-232C je (vcelku logicky) určena maximální kapacitou vedení a ne délkou. Těch 50 metrů není problém, stačí vést RxD tak 5 cm od TxD a zem úplně jinudy :-) Ztráty na vedení prakticky nemá smysl uvažovat, RS-232C je dost "silový" - pokud je na výstupu max. 12 V, na vstupu se již detekuje od 3 V, to stejné pro záporná napětí. Proto není problém RS-232C propojit i pomocí zvonkových drátů.

My jsme jako kluci provozovali RS232 na 200 metrů při rychlostech 19200 Bd. Propojení klasickou "lustrovou" dvoulinkou, uzemnění pomocí ústředního topení. Posílali jsme si soubory přes protokol ZMODEM, kecali přes terminálový program, pařili Tycoona apod. Problém byl, že takto řešené uzemnění nebylo úplně ideální a tak jste při sáhnutí na datové vodiče na druhém konci drátu mohli dostat celkem slušnou pecku :-) Pravda - čas od času tu pecku dostal řadič... Ale ten se dal naštěstí tenkrát ještě snadno vyměnit :-)

Taky se připojím... Ukaž mi nějaký SoC, nebo jednoduchej mikročip, kterej by RS232 neměl :) Ikdyž fatk je ten, že obvykle se používají klasické logické úrovně, nikoliv "true RS232"...

R.

Pozdě rozhodně není.
Např. pokud děláte něco s mikrokontroléry Atmel AVR (ATMega), je tam UART naprosto standardním rozhraním. Není divu. Je to jednoduché a funkční, jako servisní rozhraní pro mnohá zařízení ideální - stačí pak na PC obecný emulátor terminálu.
Se sériovým portem se běžně potkáte např. i na dnes hromadně prodávaných DVB-T a DVB-S přijímačích(settopbox) - je použit jako rozhraní pro updatování firmwaru, někteří výrobci k takovému updatu ani nepotřebují speciální software - stačí emulátor terminálu, který podporuje Xmodem.
Mnohdy používáte nevědomky sériovou komunikaci i v případě, že máte zařízení, připojené přes USB. Je v něm převodník USB<->serial a ovladač v PC se jeví vlastně jako další sériový port.

k obr7. "...napájecí vodiče s poměrně velkým příkonem,..."
napajcie vodice NENAJU ZIADNY prikon, ale USB port vie dodat velky vykon.

Polemizuji s obsahem kapitol 3 a 4 a tvrzenim, ze lze pouzivat jednu ci druhou dvojici ze signalu RTS/CTS a DTR/DSR, protoze kazda z nich ridi prave opacny smer komunikace. Takze RTS/CTS zajistuje otevreni vysilaci cesty od terminalu dal pres modem (osetruje prodlevu nutnou pro prepnuti modemu na vysilani). V pozdejsich dobach, pri prime komunikaci bez ucasti modemu, se pak na konektoru prislusne piny propojovaly nakratko kapkou cinu, protoze komu by se chtelo zapojovat vsechny zily v kabelu... Matne vzpominam i na konektory DB25 s dalsimi signaly pro synchonni provoz tak, jak je to citovanem zdroji http://hw-server.com. Na tom serveru je i ta "spravna" telekomunikacni terminologie DTE/DCE, signal 103, 104 atd. Jestli se mi podari behem dne vyhrabat nejakou historickou dokumentaci, tak to sem jeste doplnim.

Původně tomu tak opravdu bylo, máte pravdu.

Ovšem například při přímé komunikaci dvou počítačí přes RS-232C, nebo při připojení nějakého zařízení (mimo klasického stařičkého modemu s baudrate<=2400) skutečně dostačuje pouze jedna dvojice vodičů (která, to závisí na nastavení SW na obou stranách). Tam totiž dělení na DTE/DCE postrádá smysl, obě strany jsou si rovnocenné, viz například http://en.wikipedia.org/wiki/RS-232#RTS.2FCTS_handshaking.

Ahoj,

mám problém - řada laptopů už nemá RS232 a většina zakoupených USB to RS232 převodníků nezvládá správné časování signálů - často obsahují různé cache a místo aby skutečně posílaly to co dostanou v reálném čase, různě to brzdí a pak to pošlou najednou.

Zná někdo nějaký osvědčený převodník, který se blíží opravdovému HW RS232 portu?

Znám jeden starší kousek, ale ten není do USB ale do PCMCIA. To by ale na laptopech pořád mělo být ne? Typové označení bych kdyžtak dohledal. Používá to známý pro konfiguraci zařízení CISCO z novějšího noťasu (se stařičkým Telixem), které jsou u některých zákazníků někdy tak "mrtvé" že u nich nejede ani základní Ethernet :-)

Dvojitý sériák na PCMCIA kartě (po novu se tomu snad říká PC Card...) používám, ale pouze pod windows, pod linuxem se mi ho nepodařilo rozběhnout, asi jsem se málo snažil.

Ty "nej" notebooky již PCMCIA nemají, je nahrazeno ExpressCard.
http://en.wikipedia.org/wiki/ExpressCard
To má interně dvě rozhraní a sice USB a PCI Express.
ExpressCard se sériovými porty sice existuje, ale všechny, které jsem našel, se připojovaly právě přes to interní USB, takže jsme tam, kde jsme byli... f prdely

Kvalitni USB - RS232 prevodnik neexistuje. Je to dano USB komunikaci, ktera neni realtime, ale v paketech. Pak je problem presne v tom casovani, o kterem pises. Tzn. jedine reseni je pravy seriovy port. Ve svem notebooku (HP6710) to resim pres dokovaci stanici, HP jde v tomto smeru dobrou cestou. S notebooku port vyhodi (normalni uzivatel nepotrebuje), ale porad je mozne pripojit pravy seriovy port pres tu dokovaci stanici.

> většina zakoupených USB to RS232 převodníků nezvládá správné časování signálů

Problem AFAIK neni ani tak v prevodnikach USB na RS232, ale v tom, ze nektere aplikace RS232 jsou bastly, ktere pouzivaji RS232 jinak, nez jak bylo zamysleno. Pokud se seriove rozhrani pouziva tak, jak ma, tak tyto prevodniky nemaji problem.

Zajímavé a poučné, díky. Trošku mě to připomíná minulost, kdy se při nahrávání programu z kazeťáku na osmibitové Atárko (ale i třeba na Speccyho) dalo již z tónu přenášených dat poznat, zda se program nahraje nebo vyjede klasická hláška "BOOT ERROR" :-) Taky se dalo poznat, kdy se nahrávají programová data a kdy spíše obrázek, hlavně na Speccym - má typickou strukturu Video RAM.

My jsme měli ještě jednodušší metodu - jelikož jsme na stejném vedení provozovali i telefon, stačilo po přepnutí na RS232 zvednout sluchátko a stražit uši, protože v hovorovém transformátoru uvnitř se vždycky něco naindukovalo a datový provoz byl docela zřetelně, i když slabě, rozpoznatelný ve sluchátku.

CTS původně mělo úplně jiný význam a sice spolu se signálem RTS řídilo komunikaci terminál→modem. (terminál nastavil REQUEST-TO-SEND, modem odpovědel CLEAR-TO-SEND a teprve potom se mohlo komunikovat)... Teprve později bylo CTS přeznačeno, ale tenhle debilní název zůstal...

To, co je v článku o DTR/DSR je blbost! DTR/DSR slouží k indikaci, že protistrana je „zapnutá“/„připojená“, ovšem nemusí být ještě momentálně schopna přijímat příkazy (to zajistí až RTS/CTS). Například takto může zařízení vísící na RS232 poznat, kdy ukončíme program na straně PC (třeba minicom) a např. zresetovat nastavení. Nebo naopak, pokud máme na RS232 viset nějaký MCU, pak pomocí DSR můžeme „ukončit“ třeba příkaz „cat /dev/ttySx“ (linux to interpretuje jako EOF).

Taky DCD je skoro stejné, jako DSR, akorát se jedná o „vzdálenou stranu“ (je myšleno modem na druhé straně). Jinak ve většině aplikací funguje DCD a DSR stejně.

RTS/CTS oproti čistě zajišťuje, aby nedošlo ke ztrátě dat (tj. aby se nevysílalo ve chvíli, kdy protistrana „nestíhá“ - i když je „připojená“...)

IMHO to blbost není, viděl jsem pár funkčních zapojení bez RTS/CTS, kde se HW tok řídil jen pomocí DTR/DSR. Například sériové plottery, konrkétně perové od HP. I komunikační programy nabízí pouze DTR/DSR řízení, třeba terminál v DOS Navigatoru.

Což může být šikovná věcička, protože se tím občas dá probudit počítač (WAKE-ON-RING) :-p.

Blbý je, že na "křížených" kabelech většinou(?) není RI propojený. Nechápu proč, protože na DB-25 samozřejmě RI bylo, i na DE-9 je vyvedený. Samozřejmě po propojení dvou PC je to jedno, ale některé modemy by to snad ještě mohly podporovat (ovšem asi ne s pulsní volbou :-)

S pulzní volbou to nemá co do činění, modemy to běžně podporují; prostě při příchozím hovoru to hodí tenhle signál...

Velmi se pozastavuji nad zapojenim pro poloduplexni prenos dat. To je prasarna! Nebo jste cerpal z nejakeho seriozniho zdroje?

Proc je zapojeni spatne? Protoze proti sobe zapojujete dva vysilace, dva TxD signaly. Sice chapu, ze se neocekava ze v poloduplexu budou oba vysilat soucasne, ale TxD signaly jsou stale aktivni i kdyz se nevysila, nelze je privest do "odpojeneho stavu" (anebo snad ano??), jako je to mozno napriklad na budicich pro RS-485 sbernici, kde existuje signal pro povoleni vysilace.

Pevne verim, ze i pro poloduplexni prenos pres RS-232 seriovy port by se meli pouzit tri vodice, propojovat jen RxD s TxD. Mozna by sla kolize signalu nejak vyresit, mozna by pomohli nejake diody, ale v zadnem pripade by jsem nespojoval dva TxD signaly primo tak, jak je nakresleno.

Dva vodice lze pozit jen v pripade, ze komunikace bude probihat jen jednim smerem, bez zpetne odezvy. Ani v tomto pripade by se nemeli vzajmene propojit TxD signaly.

Taky me zarazilo, jak je mozne natvrdo propojit TxD na obou stranach. Mel by k tomu nekdo prosim nejake vysvetleni? Zkousel to nekdo nekdy?

Zdravim,
shodou okolnosti jsem se zabyval komunikaci dvou zarizeni po RS232 (musel jsem realizovat jedno z nich reverznim inzenyringem protokolu). Protistrana se se mnou stale odmitala bavit, az jsem za pomoci ioctl() pro cteni stavu modemovych dratu a notne davky intuice prisel na to, jaky druh handshake je ode mne ocekavan. Vypada takto:
- Klid: RTS i CTS neaktivni.
- Pozadavek na vysilani z jedne strany: Aktivace RTS
- Potvrzeni pozadavku druhou stranou: Aktivace CTS
- Vlastni prenos dat jednim smerem (prenasi se vzdy cely binarni paket naraz)
- Ukonceni pozadavku na prenos (z vysilaci strany): Deaktivace RTS
- Potvrzeni ukonceni: Deaktivace CTS
Ta strana, jenz chce neco poslat (paket), aktivuje sve RTS, coz se na druhe strane projevi jako aktivace CTS a je nutno do cca 100ms potvrdit svym RTS, jinak to druha strana vzda a rekne, ze protistrana chybi :-). A pokud chci odpovedet na paket z druhe strany, musim po uvedeni obou signalu do klidu po prvnim (prichozim) paketu vyckat se svym RTS nejmene 20 ms, aby si protistrana vsimla, ze uz jsem potvrdil ukonceni predchoziho prenosu... Ladil jsem to celkem dlouho, ale uz to celkem dobre slape...
Toz jsem se chtel zeptat, zda je tento druh handshake nejak standardne oznacovan, nebot jsem se s tim nikde nesetkal (setkal, u telefonnich ustreden na rozhrani pro prenos hlasu, tam tomu rikame E&M, ale ne u RS232).

Tento druh potvrzovani je bezny. Lze se a to divat tak, ze aktivaci RTS pijimac signalizuje ze ma v bufferu misto pro nova data.

Zdravím,

nebylo by dobré před skokem na "složité" rozhraní jako USB vzpomenout na v průmyslu hojně používané RS485 a jeho odnože (Modbus, Profibus, CAN)

Pokud bude zájem, tak proč ne.

Bylo by to docela dobré, sice se to téma netýká běžných kancelářských PC, ale v průmyslu se s těmito rozhraními člověk docela často setká, takže je dobré znát alespoň základní parametry a vlastnosti.

taky jsem pro...

V clanku jsem to nezahledl, tak to zminuji zde, protoze to je dulezita drobnost. U IBM-PC je potreba mit nahozeny pin OUT2, aby bylo doopravdy povoleno preruseni od seriove linky. Cetl jsem to kdysi v Sysmanu, videl jsem to v jednom zdrojaku a pak jsem to jeste cetl nekde u Papoucha.

Ano nejaky ten OUTx je potreba nahodit. Kdysi jsem se s tim dost dlouho trapil.
A nezspina se tim druhym interni loopback? Toto bez zaruky, bylo to davno

To platí jen u konektoru DB-25? Protože u DE-9 tento pin vyveden není.

Plati pro oba konektory, bez rozdilu. OUT2 signal nema s konektorem nic spolecneho, na PC stejne neni na DB25 vyveden.