Sériová komunikace pod Linuxem - I (diskuse)

[digri]

RS232/RS485 se nepouziva jen v amaterskych aplikacich, nebot USB neni ani zdaleka vseresici rozhrani ke komunikaci. Jednak pri pouziti USB se zarizeni oproti seriove lince prodrazuje a jednak hlavnim problemem je omezeny dosah USB, ktery i se specialnim kabelem cini pouhych 7m (bez pouziti pomerne draheho repeateru). Pritom RS485 je mozne pouzivat i na stovky metru.

Dalsi vyhodou pouziti serioveho portu jsou pomerne nova zarizeni umoznujici vytvorit jakysi most pres GPRS nebo wifi, pricemz zarizeni na obou stranach se pouze pripoji kazde do jedne krabicky a stale se to tvari jako RS232.

Pokud neni treba prenaset velka mnozstvi dat, muze byt mnoha lety provereny seriovy port spravnou volbou.

A jeste bych dodal, ze na novem notebooku casto nenajdete ani /dev/ttyS0 :(, nastesti existuji prevodniky USB<->RS232.

[lev]

... a taky se hojne pouziva pri administraci sitovych prvku, velkych UNIXovych stroju, ... atd.

Ne vsude chce clovek pripojovat permanentni konzolove zarizeni, ne vsechno se da resit vzdalenym pristupem pres SSH

RS232 ruleZ

[Jan Martinek]

Rozhodně jsem neměl na mysli, že se RS232 používá JEN v amatérských aplikacích. U sériového portu je při rychlosti 19200 baudů dosah jen 15 metrů, což také není žádná sláva, viz http://www.hw-server.com/rs232. RS485, kterou zmiňujete, má jinou fyzickou vrstvu, a navíc se do běžných počítačů nemontuje (modem lze zakoupit za cca 2000 Kč). Převodníky USB <-> RS232 nejsou 100% náhradou, např. odezva na změnu stavových linek je celkem pomalá.
Srovnání různých fyzických vrstev či sběrnic by vydalo na spoustu dalších samostatných článků.
Pravdou však zůstává, že sériových portů ubývá.

[Milan]

prakticky dosah je vetsi nez 15m, na jedne aplikaci jsme provizorne provozovali RS232 (nefungoval prevodnik RS232/RS485) na cca 50m bez jakychkoliv problemu

[Jan Martinek]

Při jaké to bylo rychlosti? Ten údaj, který jsem uvedl, platil pro rychlost 19200 baudů. Viz http://www.hw-server.com/rs232. Samozřejmě ještě záleží na kapacitě vodičů, ale nad tím asi každý spíš mávne rukou.

[Milan]

Bylo to propojeni mezi PC s Control Panelem a automatem Omron na rychlosti 19200 a v jedne budove, takze nehrozilo poskozeni portu od bourky apod. Bylo to skutecne jen provizorne do opravy prevodniku. Tech 15 metru je specifikace RS232, ktera je zarucena, ale lze se uspesne pokouset i o vetsi vzdalenosti.

[jard]

no nie vsetci maju take stastie, kamos mal lacnejsiu dosku a prepojil 2 kompy 17metrovym kablom... a uz iba rozmyslal ze kolko bude stat nova doska :( tolko na margo niektorych 'kvalitnych' sikmookych vyrobcov

[Jarda]

Zbytečně nadávat na šikmoočky. Pokud odešel MB, tak to nebylo nekvalitní deskou, ale nekvalitní instalací 230V rozvodu v objektu. Držím se takové, zásady, že když se dva pořítače propojují dále než přes dvě místnosti (a 17 m je už "řádně" daleko (pro RS232)) je potřeba provést galvanické oddělení. Jinak může nastat výše uvedený průšvih (v ethernet kartách už je galvanické oddělení přímo na desce). Doporučení převodníku na RS-485 jen podporuji, protože za pár stovek navíc mívají galvanické oddělení (stačí jen na jedné straně - na druhé může být bez oddělení). Mám několik instalací s RS485 na 1200 m při rychlosti 38400 kB.

[pet]

My taky. Do prvni bourky. A pak jsme menili COMy (nastesti jenom je).

[Michal Sobek]

mám již asi 6 let připojenou sériovou tiskárnu na vzdálenost cca 70m, sice po půl roce odešla zákl. deska, tak jsem tam dal druhou, v bazaru koupil starý řadič na ISA s ne SMD broukem a je klid. Jinak RS-485 používám na vzdálenost cca 1100m rychlost/9600b, jedná se o komunikaci s moduly ADAM od Advantechu. Dík za článek, třeba mě to donutí vyzkoušet komunikaci na RS-485 a přepsat program, který běží v ControlPanelu v DOSu. MS.

[beno]

Bezne sme seriovymi linkami pripajali terminaly a laboratorne pristroje do vzdialenosti 40m rychlostou 38 400. Pri rychlostiach 19 200 bezne do 60 - 70m. Rozvody rovnake ako pre ethernet (cat5). Je ale pravda, ze realizacia dost zavisela na tom, ci sa v blizkosti drotov nenachadzal nejaky zdroj silneho rusenia (typicky - kedze islo o transfuzne stanice - mraziace boxy). Vtedy sme tam dali obycajnu prudovu slucku (na kazdu stranu jeden modul, externe napajanie len na jednej strane, cena cca 1 500,- Sk/kus). So sluckami sme bezne (a pomerne bezpecne) prevadzkovali seriove spoje aj niekolko sto metrov. Tak isto pouzivame RS-485 na ucely komunikacie - je to len o tom, co je v danom pripade lacnejsie (terminalovy koncentrator s portami RS-485 bol dost vynimocne zariadenie).

[digri]

RS232 podle specifikace do vzdálenosti 15 metrů při přenosové rychlosti do 20kb/s, což vyplývá z povolené kapacity kabelu 2500pF. V praxi jsou dosahovány výsledky mnohem lepší (115200kb/s při vzdálenosti až 50 metrů), díky použití kabelů s kapacitou pod 1000 pF. Rozhraní RS232 je relativně málo odolné proti rušení...

http://www.hw.cz/docs/rs485/rs485.html
http://www.hw.cz/products/rs232_konvertory/index.html
http://www.hw.cz/docs/rs485/poucha.html

RS422/RS485 do 1200 metru, pricemz na RS485 lze povesit vice zarizeni. Komunikacni linky jsou galvanicky oddelene, takze vam toho pri nejakych problemech moc neshori.

Prevodnik RS232<->RS485 lze vyrobit i podstatne levneji, ovsem nutnosti byva ovladani vysilace signalem RTS, ale s tim pod linuxem nemam zkusenost a zajimalo by mne, s jakou odezvou je mozne ho ovladat, nebot pod nejmenovanym operacnim systemem se chova dost nevypocitatelne.

[Jan Martinek]

Nechci, aby to vypadalo jako nějaká reklama, ale za 1600 Kč (bez DPH) lze zakoupit převodník RS232<->RS485, který obsahuje autodetekci směru toku dat, takže žádné ovládání přes RTS není potřeba. Kdyby to však přece jen potřeba bylo (např. u HART modemu, modulace BELL 202), tak tam úskalí spočívá v tom, že Linux (nebo UART 16550A) bufferuje, takže před změnou RTS je nutné se přesvědčit, zda jsou data skutečně vyslána. Spočívá to ve sledování bitu TEMT v registru LSR. Rychlost odezvy závisí na jádře, ale myslím, že můžete být bez obav, že by to nestíhalo. Při rychlosti 9600 je doba přenesení jednoho bitu asi milisekundu, takže minimálně tuto dobu se může jádro klidně flákat.

[Jan Martinek]

Zde je rutina, která čeká na vyprázdnění Transmitter Shift Registeru:

  while(1) {   /*Wait for TSR*/
    if(ioctl(fd, TIOCSERGETLSR, &lsr) == -1) {
      printf("ioctl() error %d occured (%s)\n", errno, strerror(errno));
      return -1;
    }
    if(lsr & TIOCSER_TEMT) break;
  }

Pak teprve je možné změnit stav RTS a tím přepnout modem z vysílání na příjem.

[Jozef Vondrák]

Program pro komunikaci linuxu s RS485 zarizenim jsem psal a funguje dodnes (vyzaduje pouze pravidelne narizeni hodin). Na linuxovem stroji je na RS232 pripojen prevodnik a uz to svisti. Odladil jsem to na kernelu 2.2.14 a ovladani signalu byl opravdu opruz. Moc jsem v tech signalech nemel jasno a doufam, ze pokracovani zde mi to vyjasni. Na kernelu 2.4 to nefungovalo - prenesena binarka vzbudila paniku a rekompilace vyrobila vpodstate prenesenou binarku. Nejvetsi problem bylo prepnout se do rezimu prijmu VCAS, coz vzhledem k baudove rychlosti a rychlosti koncovych zarizeni znamenalo pracovat s casovym rozlisenim pod 1 milisekundu - v userspace - to byl problem, ale dalo se to taky.

[Jan Martinek]

Psal jsem o tom ve svém předchozím příspěvku. Zůstává tam ještě stále nějaká nesrovnalost? Tak pro úplnost ještě dodávám, že signál RTS se nastavuje takto

  int iFlags = TIOCM_RTS;
  ioctl(fd, TIOCMBIS, &iFlags);

a deaktivuje takto:

  int iFlags = TIOCM_RTS;
  ioctl(fd, TIOCMBIC, &iFlags);

kde fd je file descriptor daného otevřeného portu.
Jádro 2.2.14 je opravdu dávná historie, domnívám se, že jádro i hardware jsou dnes na takové úrovni, že rozlišení pod jednu milisekundu není problém ani v userspace.

[finn]

Díky za článek, je dobře mít to všechno shrnuté na jednom místě. Jenom drobné doplnění: jednočip s implementovaným RS-232 jsem ještě neviděl, zato většina jich má UART :)

[Jan Martinek]

Máte pravdu, u jednočipů se jedná o UART. Omlouvám se lehký zmatek v pojmech. Podrobnější informace o vzájemné komunikaci jsou uvedeny v článku o jednočipech.

[Martin]

USB se hodí spíše pro komunikaci, kde jsou data prenášena ve větších balících najednou. Pokud se budeme bavit o vezi USB 1.1, tak tam se dají za normálních okolností v režimu Bulk Transfer (asi nejběžnější režim, ostatní jsou používány většinou pro přenos dat v reálném čase) přenášet data pouze jednou za 1ms a to v maximální délce 64Byte. Z toho vyplývá přenosová rychlost maximálně 512kBit/s na jedno zařízení, což je sice více než sériový port. Ale v tomto režimu není zaručeno, že se data budou přenášet každou 1ms a ani není zaručena doba od zadání požadavku k odeslání od doby skutečného odeslání dat. Přidáme-li k tomu to, že si to člověk většinou "neubastlí" bez speciálního "brouka", tak se mě osobně jeví USB pro bastlení jako hodně nepohodlné.

[Kulich]

Zdravim No myslim ze nemate pravdu. Uspesne jsem zkousely prenos v Bulk rezimu pri rychlosti 200kB/s mezi jednocipem a PC. V tomhle rezimu to funguje tak ze se zeptate na nove data. U Windows to frci tak ze funkce co zada data zmrzne dokud nedostane pozadovany pocet dat. V tomhle rezimu je ale vyborna detekce chyb a to ze si ty data predavaji zarizeni inteligentnim protokolem, takze se da minimalizovat ztrata bytu. Treba PC posila data jednocipu a ten prijme jeden bajt a nez ho staci zporacovat je tu dalsi byte z PC a treba se jeden z nekolika ztrati. A protoze mate 4 rezimy vyberete si co vic sedi vasi aplikaci. Ja osobne si myslim ze pokud nemate konkretni priklad aplikace tak bych radsi nesrovnaval USB a seriovy port. Ale shodnu se na tom, ze to bez specialniho brouka nejde, i kdyz pokud vam staci USB Low-Speed verze tak se da obejit bez specialniho brouka. Proste USB je komplexni sbernice a UART je jednoducha v tom je jejich sila.

[Martin]

Jen otázečka 200kB/s je 200kByte/s = 1.6Mbit/s? A tuhle rychlost jste dosáhli s jedním endpointem v Bulk režimu na USB 1.1 tedy ve full-speed režimu? To by znamenalo v jednom frame (1ms) přenést 200Byte. Ptám se protože je mi to divný, když ve specifikaci pro full-speed režim USB1.1 je max 64Byte na jeden frame. S full-speed režimem na USB1.1 nemám zkušenosti, předpokládal jsem, že je to tak, jak jsem napsal. Mám zkušenosti pouze s USB2.0 v izochronním režimu v high-speed. Dělal jsem aplikaci, která přenáší v reálném čase obraz do PC. Mohl byste mi napsal jak jste to udělali, mě by to zajímalo, jaký byl descriptor pro ten endpoint?

[KUlich]

Jo presne jak pisete jeden endpoint, Bulk rezim, Full-Speed, USB 1.1. A prepocteno je to 1.6 Mb/s. Ono to bylo o neco vic asi 250kB/s, ale presnou hodnotou si nejsem moc jist (osobne si mylim, ze to jde jeste vic ale uz je to nad sily toho mikrokontroleru). Specifikaci jsem teda moc nelouskal se priznam, ale byl to takovy poznatek z praxe (navic nekdo to tu popsal detailne takze diky mu). Na webu od Cypresse jsou aplikacni poznamky a tam jsou testy propustnosti v ruznych rezimech pro jejich CPU. Jen tak mimochodem mi to zase pouzivame na prenos obrazu z PC . Ale ta vase aplikace mne docela zajima. Byl byste se ochoten podelit o zkusenosti. Treba jaky procesor jste pouzily atd.? Ale radsi pres email nebo ICQ at neobtezuju ostatni.

P.S. Ten zdrojak se mi bohuzel nepovedlo najit, ale naskrabu to znovu pokud byste mnel zajem. ICQ: 158-434-232 kulich.bulich@worldonline.cz

[j]

Mylite se v jednom zasadnim faktu: Bulk Transfer v USB 1.1 (i jakekoli jine verze) muze mit NEKOLIK transakci v ramci jednoho frame-intervalu (1 ms). Vse je v rezii Host Controlleru, zarizeni typu Function ma dost prisne timeouty na odpoved. Host Controller musi pouze zajistit, aby neposlal pozadavek, na ktery by nestihla prijit odpoved do urciteho limitu pred zacatkem dalsiho ramce (paket SOF). Da se tedy dosahnout rychlosti okolo 1 MByte/s i s jednim endpointem.

[Martin]

Ano, máte pravdu předpokládal jsem, že je možná pouze jedna transakce pro jeden endpoint v jednom rámci. Něvěděl jsem, že je možné pro jeden endpoint provést více transakcí v jednom rámci, takže díky za cennou informaci :) Možná se bude někdy hodit.

[Martin]

V dokumentu Serial Programming Guide for POSIX Operating Systems jsem se dočetl, že "UNIX serial drivers support even, odd, and no parity bit generation." Skutečně nelze nijak nastavit paritu explicitně do 0 nebo 1?

[jirka2]

Brouk 16c550 to neumi. Na 9ti bitovy prenos se opravdu musi pred kazdym vyslanim bytu spocitat paritu a podla pozadovaneho 9. bitu ji nastavit jako sudou nebo lichou. Tim padem ani nejde pouzit buffer, musi se odchytavat vyslani kazdeho bytu.
Pri prijmu se zase hodnota 9. bitu da zjistit jen spocitatim skutecne parity a vyhodnoceni parity error.

[Jan Martinek]

U mě to nejde ani fyzicky, mám čip 16550:
root# setserial /dev/ttyS0
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
Nastavení parity explicitně na 1 lze chápat jako přidání jednoho stopbitu navíc, nicméně dva stopbity by měly stačit, takže snad ani není potřeba to dělat. Nastavit ji na 0 by teoreticky šlo softwarově, kdyby počet bitů ve slovu byl nižší než 8. Paritu lze také při příjmu ignorovat. Ale netuším, v jaké aplikaci je nutné nastavovat paritu na fixní hodnotu.

[Martin]

Tak jsem právě koukal do datasheetu k obvodu 16c550. Ten má tzv. sticky bit, tím lze nastavit explicitně vysílanou paritu na 1 nebo 0. Problém se ovšem v tom (zda-li jsem to pochopil dobře), že při nastavení tohoto bitu je ovlivněna také přijímaná parita, která je tím pádem nastavena také explicitně do 1 nebo 0, takže se nezjistí skutečně přijatá parita.

K čemu je to dobré? Pro komunikaci mezi více zařízeními na jedné sériové lince. Pokud je 9. bit (tzn. parita) v jedničce, jde o adresu zařízení a pokud je v nule, jde o data pro dříve naadresované zařízení. Pokud by na sběrnici byl pouze jeden master, tak je používání sticky bitu bez problémů, protože slave bude mít sticky bit vypnutý a zjistí si zda jde o adresu nebo data. Master bude mít sticky bit zapnutý. Pokud by ale bylo více masterů byl by problém.

[Jan Martinek]

To je tedy mazané
Ale jestli drivery neumožňují nastavit 9.bit na danou hodnotu, tak by bylo možné změnit paritu (na straně mastra) podle toho, jestli se vysílá data nebo adresa. Parity error na straně zařízení by znamenalo, že byla přenesena adresa. Tímto způsobem by se dalo i lépe využít to bufferování, protože u delších bloků dat nebude nutné kontrolovat každý bajt zvášť.

[Martin]

Hmm, dobrý nápad :)

[j]

POSIX to neumoznuje, ale linuxove-specificky flag na toto my mel byt CMSPAR (viz Google). Mozna vetsi problem bude s detekci chyby parity. Klasicky by se to poznalo prijetim sekvence 255 0, coz krasne rozbije jakykoliv binarni protokol, ktery s tim nepocital . Nadeji bych vkladal do flagu TTY_PARITY, i kdyby se mel testovat po kazdem prijatem bajtu. Hodne stesti, to by me zajimalo, jestli to funguje.

[Voty]

Jo jo. Ja to zkousel primo z programu (volani tcsetattr()) a CMSPAR opravdu funguje. Tusim, ze je definovan nekde v asm/termbits.h (nebo tak nejak). Hlavne prepinani z 0 parity na 1 paritu se provadi nastovavanim sude ci liche parity.

[Jan Martinek]

Symbolické názvy bitů pro UART 8250, 16450, a 16550(A) jsou nadefinovány v souboru
include/linux/serial_reg.h
Takže test na chybu parity by se dal udělat jako

#include<linux/serial_reg.h>
int lsr;
ioctl(fd, TIOCSERGETLSR, &lsr);
if (lsr & UART_LSR_PE) parity_error();

Je tam nadefinován i sticky bit pro paritu:

#define UART_LCR_SPAR   0x20    /* Stick parity (?) */

Nevíte někdo, proč je v tom komentáři otazník?

[Roman Fibinger]

Ahojky, fakticky moc pekny clanek. Hodne noveho jsem se dozvedel. Momentalne se s Linuxem ucim a potreboval bych udelat aplikaci, ktera by umela sahnout do MysQl databaze, najit podle cisla polozku a poslat ji do /dev/ttyS1. Dokazal by jste nekdo neco takoveho?? Dekuji za reakce. Pripadne na mail: fibinger zavinac centrum tecka cz. Diky moc a preji krasne Vanocni a novorocni svatky. Hodne stesti a zdravi.

[Jan Martinek]

Ahoj, zcela jistě by něco takového šlo naprogramovat. Možností, jak to udělat, je celá řada a je těžké napsat konkrétní ukázku, protože neznám žádné údaje z té databáze (server, uživatel, heslo, tabulka, klíče atd.) ani kýžené parametry pro sériový port (přenosová rychlost, parita, atd.)
Každý by to napsal jiným způsobem. Je potřeba vybrat vhodný programovací jazyk. Shell vynechme. Céčko je skvělé pro ovládání se sériového portu, ale kvůli komunikaci s MySQL serverem by asi bylo jednodušší to napsat v Pythonu. Podle mě by to šlo v obou jazycích a je to jen otázka vkusu. Pokusím se nastínit řešení v Pythonu. Nejprve je potřeba vytáhnout data z databáze:

#!/usr/bin/env python
import base64, MySQLdb, os, sys
from MySQLdb.cursors import Cursor,BaseCursor,DictCursor

password_base64 = 'aowfowefwe=\n' # plaintext heslo nechci ukazovat
password_plain = base64.decodestring(password_base64)

db = MySQLdb.connect(db='moje_db', passwd=password_plain )
c = DictCursor(db)
db_command = 'select * from tabulka'
c.execute(db_command)
while True:
  answer = c.fetchone()
  if not answer: break
  print answer #Udelej neco s temi daty
c.close()
db.close()

Takže když už jsou data k dispozici, je potřeba je nasypat do otevřeného a patřičně nastaveného sériového portu. Ukázka pro inspiraci může vypadat následovně:

#!/usr/bin/env python
import tty, os

fd = os.open('/dev/ttyS0', os.O_RDWR | os.O_SYNC)
attr = tty.tcgetattr(fd)

attr[tty.IFLAG] = tty.IGNPAR | tty.IGNBRK | tty.INPCK | tty.IMAXBEL | tty.IXOFF
attr[tty.LFLAG] = tty.ECHOKE
attr[tty.OFLAG] = tty.ONOCR
attr[tty.CC][tty.VMIN] = 0
attr[tty.CC][tty.VTIME] = 5

attr[tty.ISPEED] = tty.B19200
attr[tty.OSPEED] = tty.B19200
attr[tty.CFLAG]  = tty.B19200 | tty.PARENB | tty.PARODD | tty.CSTOPB | tty.CS8 
attr[tty.CFLAG] |= tty.CLOCAL | tty.CREAD | tty.HUPCL

tty.tcflush(fd, tty.TCIOFLUSH)
tty.tcsetattr(fd, tty.TCSANOW, attr)

# Ted se neco zapise do portu ...

# a pak se port zavre

os.close(fd)

Podotýkám, že jsem neměl možnost nic vyzkoušet, takže nevím, jestli to funguje.
Přeji veselé vánoce

[Roman Fibinger]

Dekuji, pokusime se s tim nejak poprat