Názory k článku
Sériový port RS-232C

Opet musim pochvalit - skvele napsane

Taktéž se připojuji. Velmi děkuji za skvělý článek. Díky Vám, jako amatér v elektrotechnice o trošku víc rozumím tomu co se na portech a jiných částech počítače děje. Děkuji a těším se na další díl.

Hodnotil som za dva. Clanok je technicky dobre rozpisany, ale chyba mi tu jedna vec, ktora si uz zo zamerania tohoto servera ziada a tou je aj opis nastavení v Linuxe pomocou setserial, aspon sa trosku zmienit + nejake tie zaklady.

Ja tedy nevim, ale cetl jste zaver? Predpokladam, ze to bude uvedeno priste, minimalne u paralelniho portu se na nastavovani take dostala rada.

Fúha, necítal som :-) Vidím, ze som ho prehliadol, lebo odkazy na stranky ma nezaujimali a povazoval som ich za koniec clanku... Tak sorry.

Příště se skutečně nastavením a programování sériového portu budeme zabývat. Nejedná se totiž "jen" o vlastní sériový přenos - RS-232 jde totiž použít i v režimu, kdy se programově ovládají některé výstupní piny a naopak se z dalších pinů v případě potřeby čtou logické hodnoty. Toto řešení jsem v minulosti použil pro připojení jednoduché klávesničky k počítači - obešlo se to zcela bez použití jakýchkoli součástek, k počítači se prostě přímo připojilo několik vhodně zapojených tlačítek.

do odkazů bys měl určitě přidat i http://rs232.hw.cz/

díky za upozornění, nechám ten odkaz přidat.

ale to je vazne pekne, vzdy som pouzival iba http://www.hardwarebook.info/ - ale hw.cz vyzera dost dobre

Pěkně popsáno. Jen škoda,že toto rozhraní z dnešních počítačů (hlavně NB) mizí a musíme si pomáhat nespolehlivými udělátky typu převodníku USB-RS232.

...a proc ne USB-USB? Jednocipu, co umijou USB, uz je dost.

Protoze prumysl. USB je pro blbecky, co nevylezou z kancelare. :))

(Prosim berte s humorem.)

Presne. Jenze jim to nevysvetlite. Holt frikulini :)

Ne vždy tu možnost máte. Například u výkonových fázových měničů (docela drahé a šikovné hračky) se RS-232 používá zcela standardně. Nehledě na to, že samotný řadič USB je mnohdy složitější než vlastní jednočip, kterým se má něco ovládat :-)

Freescale ma v nabidce jednocip s USB za 1.5 dolaru. Osmibit s osmi kilama flashky. Myslim, ze slozitost radice nebo protokolu USB tedy zrejme nebude ta hlavni prekazka v sirsim pouziti USB.

:))

A uz jste nekdy vylezl z te kancelare?

USB je podle mych zkusenosti dobre leda tak na propojeni nekolika zarizeni, ktere vam lezi na stole. Dal s tim nemuzete.

Zakladni funkcnost komunikace po RS232 si v terenu hrave zkontrolujete voltmetrem. Potrebne tri draty na konektor priletujete i potme v garazi u dieselagregatu (ano i ten muze mit RS232). Navzdory nejakym normam muzete z tohodle kabelu udelat jeste odbocku pro odposlech. (Obcas dojde i na figle, ze TxD od stroje 1 se pripoji na RxD stroje 2 a 3, TxD z 2 na RxD do 1 a TxD z 3 nekam uplne pryc.) Kdyz pouzijete vic nez ty tri draty, tak muzete prenaset i dalsi binarni stavy. (Ale to se uz moc nenosi. Melo to vyhodu, ze to slo spatne odpalit.) Dosahnete o par metru dal nez s USB. (V pripade potreby i po rozvodech domovniho telefonu.)

A dalsi vyborna vlastnost je, ze RS232 muzete pomerne snadno prekroutit na RS422 nebo RS485 (princip prenosu dat vicemene stejny, jenom jine napeti/proud) a mate sbernici funkcni a kilometr dlouhou a na ni navesene ruzne regulatory.

USB opravdu ne.

Kdyz potrebuju velkou rychlost na vetsi vzdalenosti (kilometry), tak optiku nebo ethernet. Kdyz potrebuju, aby to "jenom" komunikovalo (ne moc rychle, ne moc daleko), tak RS232/485.

mate pravdu, z kancelare jsem nevylezl - ale zajimavy veci se daji udelat i tam (i s rs232) ;-)
samozrejme, neni problem najit aplikaci kde se usb nehodi. ja jen moc nechpu to vzyvani rs232 a proc nepouzit novejsi technologie - usb, lin, can, flexray, ethernet - sbernice rychlejsi, odolnejsi proti ruseni, v mnoha parametrech predci tyhle rsXXX dinosaury [pravda, tezko je odladite jenom s voltmetrem ;) ]... je to dneska v kazdym druhym uC, reference designy od vyrobce chipu ke stazeni - brnkacka neco takovyho rozchodit

:)

Tak pak uz me napada posledni vysvetleni okoukane z praxe: "Nevylepsuj nic co funguje"

1) Prumyslova technika, tam USB nema co delat

2) USB blok MCU je pomerne draha zalezitost, mnohem slozitejsi nez UART (USART). Navic firmware k USB MCU je neskutecne slozity, jen resit enumeraci je otazka par tisic radek. Ovladani UARTu je otazka desitek radek.

3) Delaji se USB-UART obvody (napr. FT232), ale ty vetsinou uz maji trosku jine parametry a pri opravdu casove kriticke komunikaci jsou nepouzitelne. Napriklad v automobilove diagnostice jsem nevidel snad zadny program pouzivajici K-Line prevodnik na seriovou linku fungovat s USB-UART prvodnikem.

Myslim, ze by autor mel do clanku tucnym pismem napsat, ze "USB-UART/RS232 prevodniky maji jine parametry nez puvodni obvod 16550 a to snad ve vsech ohledech: latence, baudrate generator, funkcionalita". Funguje-li neco na 16550, neni zadna zaruka, ze bude fungovat i na FT232 ci necem obdobnem (dela to spousta firem, National, Texas, atd.).

ad 3) ono to je problem spis navrhare daneho interfejsu, protoze neni problem pouzit malicke mcu ktere se postara o buffering a casove kriticke operace a pak to pripojit na seriovy port ktery bude a la "command line".

Urcite si vzpomenete na zmetek pro prijem IR dalkoveho ovladani.. v prvni verzi mcu, v dalsu uz primo pripojeny ir prijimac na seriovy port.. a kazde stlaceni dalkace zaseklo film na chvilku :)

Jenom malé upřesnění. Dle TIA-574 se ten malý devítipinový konektor označuje DE-9, nikoliv DB-9. Jinak bezva počtení. Díky.

taky se pripojuji a chvali velice pekne napsany a zajimavy clanek. tesim se na pokracovani!

diky,
ludek

článek jsem nečetl, tak nevím zda to tam už někde není.

Malé upozornění, USB RS232 (často s deriváty FTDI obvodů) převodníky většinou dokáží nastavovat jenom vybrané rychlosti, např. 9600, 14400, 19200... (mají pevně nastavený krystal a děličku).
Při použití těchto převodníků není možné nastavit nestandardní rychlosti. Takže chcete-li třeba připojit autodiagnostiku OBD, která komunikuje 10400b/s, tak se to nepodaří, protože převodník si dále vysílá 9600 a jeden pulz pak trvá 104us místo 96us.

řešením je použití HW portů v PC a nebo speciálních PCMCIA karet, které umožňují nastavit frekvenci krystalu a poměr děličky v širokém rozsahu a pak vykouzlit "skoro" všechny rychlosti.

Já používám http://www.sourcingmap.com/rs232-pcmcia-serial-9pin-expresscard-express-p-15323.html. Je to trochu porod nastavit, ale maká to
další výou je, že karta nepotřebuje USB driver a chová se jako reálný HW port, funguje tedy všude (Linux, DOS...) bez problémů

Ano, to je dost obecný problém, například u velkého množství jednočipů, které mají jeden krystal a z jeho frekvence dělením odvozují mj. i synchro signál pro sériový port. Příště se o této problematice zmíním. Onen rozdíl 10400 bps a 9600 bps je už velký, teoreticky by snad šlo (pokud to obě zařízení umožňují) přenést start bit + 5 bitů dat + stop bit, žádná parita (záleží na tom, jak přesně zachytíte začátek start bitu), u osmi datových bitů se to již rozsynchronizuje.

Ne, nejde to :). Verte mi.

Ale puvodni prispevek (od Martina) v sobe ma par chyb. Na FTDI obvodech rychlost jde nastavit bez nejmensich problemu. Tam jsou potize spis v latenci, nebo pouziti VCP driveru misto D2XX.

Dale je potiz s generovanim opravdu hodne nizkych baudrate typu 5bps, ale ty jdou delat ciste softwarove.

Treba takovy program KWP2000, ktery dneska krade uz kdekdo prave pouziva FT232 ... a funguje dobre. Opravdu jediny problem tam je s casovanim. Treba takova K-CAN gateway z Fabie/Roomstera pozaduje odpoved' na inicializaci tusim za 10-20ms, coz ve Windows je docela problem.

jj, s tím časováním tomu docela věřím. Podobný problém jsem řešil taky - zpracovat signál z několika kamer svým Windowsovským programem a ještě řídit spouštění dalších snímků na základě nějaké události (ve stroji už je výrobek atd.). Nakonec se vícevláknový program musel přepsat s ručním řízením typu round-robin + vlastní driver, protože přepnutí vláken někdy dosahovalo právě těch 10 ms i při nastavení realtime priority.

S USB<->RS232 prevodnikom ma problem asi vacsina sw, ktory chce pouzit RS232 na nieco ine nez len "slusne" znakove I/O cez prislusne high-level API.

Napr. PonyProg programuje 2kB MCU cez USB<->RS232 prevodnik asi 2 minuty (ak vobec). Cez PCMCIA RS232 radic to trva cca 10s...

Ja som pri výbere notebooku bohužiaľ na sériový port zabudol, takže som si potom zaobstaral USB-RS232, a to kvôli jednému dôvodu - updatovanie fw a nastavení satelitného prijímača OpenBox. :-) Na moje počudovanie to aj naozaj funguje.

Dobry den, nevite jestli se da nekde koupit neco podobneho jao bylo v tomto clanku uvedene ovladani rele pres seriovy port (nebo jakykoliv jiny)? Vim ze se to velice jednoduse zbastlit ale to nechci. Takze prosim jen odpovedi ktery vi o necem. Nechci si nic sam stavet, chci koupit. Nebo jestli je treba nejakej pes pripojeny do usb pricemz muzu ovladat jednotlive zasuvky....a melo by to umet komunikovat s linuxem.Diky moc

Ja to pouzivam treba od fy Papouch http://papouch.com/shop/scripts/_list.asp?pages=1&kat=2&v1=3 a myslim ze neco podoneho najdete i na www.hw.cz

Skvely diky moc, to je presne to co potrebuju!

Za kolik s ethernetem? A s jakými relé?

"komerčně dostupné krystaly, běžně považované za velmi přesné, by již po několika sekundách přenosu měly takovou odchylku, že by přesáhla dobu trvání přenosu jednoho bitu"

Myslím, že krystaly jsou poněkud o hodně přesnější.

Je tomu tak. Uvažujme bitový tok nesynchronizovaného signálu 115 000 bps, což je dnes spíše podprůměrná hodnota. Po deseti sekundách se přenese cca 1 milión bitů a kvůli vzorkování v půlce bitu je tedy nutné, aby každá strana (vysílač i přijímač) měl přesnost 1/(2 000 000), celkově tedy (chyby se sčítají) je požadována přesnost 1/(4 000 000), jinak již po deseti sekundách bude docházet k chybám - posuneme se o polovinu bitu.

Dnešní krystaly AT standardu jsou tak na hranici (spíš pod ní) této přesnosti, zvláště když se vezmou do úvahy další věci, především vliv napájecího napětí, zatěžovací impedance, změny teploty a závislost dlouhodobé stability (stárnutí).

Souhlasím s tím, že synchronizovat se absolutně nemá smysl. V tomhle asi jsou krystaly nepoužitelné. A určitě to není šikovné jako řešení. Nicméně relativně tu přesnost mají.

Já bych se vůbec divil, kdyby se dva nezávislé oscilátory (ať už na jakémkoli principu, který by byl rozumně levně vyrobitelný) vůbec sešly byť na krátkou dobu - myslím v absolutní frekvenci - bez vzájemné synchronizace.

Pane Ponkrác, já vím, že vy jste odborník na všechno včetně astrologie, ale do elektroniky se prosím raději nepouštějte. Děkuji.

Tyhle odpovědi miluju. Neřeknou vůbec nic, raději neuvedou žádný argument, aby pisatel na sebe neprozradil, že je blbý jako punštok, a kdyby kromě špíny na druhého otevřel pusu, tak by prozradil na sebe, že se mu nedostává ani iq, ani argumentů.

Jsem dostatečně otrlý, aby mi pomluvy bez důvodu byly u zadnice - jak si mnoho lidí už mohlo všimnout, takže jenom zbytečně ztrácíte čas.

Ale, ale...
Kdopak tady pronesl "informacemi nabitou" větu: "Myslím, že krystaly jsou poněkud o hodně přesnější." Co myslíte? Byl jsem to snad já?
Na váš blud reagoval naprosto věcně a správně pan Tišnovský, tak si to, prosím, přečtěte.

Není mojí vinou že v někom vyvoláváte nějaký(nepříznivý) dojem. Schválně si po sobě zkuste přečíst své příspěvky do diskusí s několikaletým odstupem. Pravděpodobně na sebe získáte podobný názor, pokud si to přiznáte.

hele mm, jestli se chceš jenom hádat a urážet, tak běž na novinky nebo idnes, tam jsou diskuze pro takové jako ty a tady neotravuj slušné lidi

a copak děláš v elektronice ty?
máš dva příspěvky v diskuzi a jeden blbější než druhý

Pred 10Mbps Ronjou byla seriova Ronja 115 Loopipe. Fungovalo to na principu modulace IrDA. Modulace IrDA se vubec nehodi na opticky prenos vzduchem takze to byl hrozny shit.

Vadila tam 16x vetsi nosna a kratke pulsy? :) Holt to bylo vymyslene na kratky dosah a agresivni low-power pozadavkou..

Ahoj autore, dekuji za clanek. Jenom prosim o vysvetleni (tohle jsem nikdy nemohl pochopit), jak pozna receiver, kdy ma cist ten start bit. Jako ze predstavuji si, ze se napichnu na linku, kde nekdo vysila, tak jak mam poznat, KTERY prechod z vysoke urovne na nizkou je ten zacatek a kdy je to jenom jedna z nul uprostred normalnich jednicek.

na zacatku se zasynchronizuje tak, ze pocka az bude (8data+xx+1stop) bitu ticho (log 1). prvni hrana potom patri k start bitu dalsiho byte.

Furt to jeste nechapu. Co je to ticho? Vzdyt je to jenom dvoustavove, vysoka a nizka uroven. Jak se pozna "ticho" od treba dvou az trech jednicek po sobe? Kdyz se podivam na obrazek z clanku
(http://i.iinfo.cz/urs/pc_39_09-122765291441251.png)
a predstavcim si tu sekvenci na nem zobrazenou opakovane za sebou, bez toho, ze by k tomu byla popiska :-), tak netusim, jak bych poznal, ze zrovna TED je start bit a ne jenom jedna z nul.

z toho obrazku to nepoznate. "ticho" je na UART-u logicka 1.
kdyz mate nepretrzitej tok dat, tak jednou za 10 bitu (nejjednodussi pripad), je prechod 1->0 (stopbit->startbit), jakmile takovou vec po dobu 10 bitu neuvidite, tak vite, ze se nevysila a je jasny, ze dalsi hrana bude patrit startbitu.

Takže chápu to správně tak, že když se nepřetržitě vysílá - stále se nepravidelně střídají nuly a jedničky - tak čerstvě se připojený přijímač nemá šanci zachytit začátek bytu, tedy že v nepřerušeném vysílná nelze rozpoznat start bit? Jinými slovy, synchronizovat se dá jedině poté, co byl chvíli (po čas potřebný při dané rychlosti k odeslání deseti bitů) úplný klid? A potom, když už jsem se jednou chytil, se nesmím "splést", tedy musím si odpočítávat další začátky, aby se mi nepopletly s nějakýma normálníma nulama?

Chapete to spravne. V praxi se totiz nestava, ze by vysilac vysilal neustale. Obvykle se komunikuje stylem dotaz-odpoved, takze tam nejaka mezera vznikne. Navic nekde o uroven vys obvykle dochazi k tomu, ze kdyz do urcite doby nedojde srozumitelna odpoved, tak se posle novy dotaz.

Děkuji ID a bnmmb za odpovědi. Tuto věc jsem nechápal asi tak dvacet let :-) Vždycky jsem si představoval, že vysílání je nepřetržité a že přijímač nějak je schopný najít začátek, což mi ale z popisu protokolu nebylo jasné, jak to udělá. Takže moc díky za vysvětlení!

Na mezeru se opravdu nespoleha, vzdyt ten protokol je tak uzasne jednoduchy a samosynchronizacni ze to az bije do oci :)

na mezeru se opravdu spoleha. schema synchronizace, ktere jste popsal v jinem svem prispevku je sice duvtipne, ale nedokaze *zarucit*, ze se prijimac zasynchronizuje na libovolnych datech - k tomu by bylo nutne vkladat do dat spec. znaky jako napr. 0 nebo 255 apod.

Pokud je pocet stop bitu rovny nebo vetsi 1, tak se lze "pomerne" rychle nasynchronizovat i do neustale probihaji komunikace, ono proto tam ten stop bit je.

Proste prijimac ma OKNO (posuvny registr) o delce 10 bitu ktery se posouva komunikacni rychlosti od doby nez se zachytil prvni start (muze byt i falesny - pripojeno uprostred bajtu). Pokud sedi podminka pro start a stop bit, tak se znak prijme. Pak se okno zacina plnit od pocatku, do te doby nez se nenaplni uplne a bud sedi start/stop (=prijmout+restart), nebo nesedi (=shift).

Pokud by to bylo s tim 10bitovym registrem a s vyhodnocovanim stopbitu tak, jak rikate, tak by to asi fungovat mohlo. Nicmene i tak me napada teoreticka moznost, ze se prijimac chytne v takovem miste, ze na miste stopbitu bude bit s hodnotou, ktera vypada jako stopbit a za nim bude zase bit, co vypada jako startbit.

Ale stejne si myslim (nejsem to schopen dokazat), ze se stopbit nevyhodnocuje. Ze v okamziku, kdy prijimac chytne startbit, tak se zasynchronizuje, pak se chytnou datove bity (a parita) a jakmile je pochytano, tak se cely bajt strka nekam do fronty, zatimco vysilac vysila prave ten stopbit. Mam za to, ze ten stopbit tam je prave proto, aby se stihla zpracovat prijata data, ne kvuli vyhodnoceni jejich spravnosti. Kvuli kontrole spravnosti prece je (nebo spise muze byt) parita.

Mimochodem, anketni otazka, zazil jste nekdo v poslednich peti letech aplikaci na RS232, ktera by pouzivala paritu?

stopbit je tam proto,aby byla zarucena existence hrany v kazdem bajtu (tou hranou stop->start se resynchronizuji hodiny prijimace)

Ahoj všem..

Prvně musím autorovi poděkovat za pěkný článek. Se sériovým portem teprve začínám, tak jsem rád mj. i za upřesněné názvosloví (například termín UART)

Nicméně mám doplňující otázku. Když z počítače pošlu do nějakého zařízení po sériové lince příkaz a očekávám odpověď, tak co se s tím příkazem děje? Ten se v tom zařízení uloží do fronty a to zařízení příkazy z fronty čte? A když mi pak zařízení odpovídá, tak mi zpátky vyšle odpověď a ta se uloží ve frontě v počítači? Takže pokud pošlu 2 příkazy rychle po sobě, tak se nejprve vykoná první a potom druhý a následně mi přijdou 2 odpovědi v rychlém sledu? (Vycházím z příkladu o Telegrafu)

Nyní to dělám tak, že pošlu příkaz z PC do zařízení a pak ve smyčce WHILE čtu patřičný COM a čekám, až načtu ukončovací znak, který má ono zařízení poslat na konci odpovědi. Používám správný princip?

Často se mi stává, že zařízení né a né odpovědět a WHILE běží a běží a počítač nereaguje. Jak jsem se dozvěděl na webu, je u RS-232 časté, že se informace ztrácí, takže příkaz do zařízení vůbec nemusí dorazit. Řeším to tak, že ten samý dotaz pošlu 2x rychle po sobě. A bojím se, abych připojené zařízení nezahltil, nebo, aby se mi v PC nehromadily odpovědi, kterých je v podstatě 2x více, než chci. (Protože každý příkaz posílám 2x, ale pak ho jen jednu čtu - a čtením se nejspíš zmenšuje ta fronta, od které se ukládají odpovědi)

Může mi to někdo okomentovat? Dík..

PS: o nespolehlivosti RS-232 jsem četl zde:
http://roboti­ka.cz/guide/pc-robot-control/cs