Sériová komunikace pod Linuxem - I

18. 8. 2004 | Jan Martínek | Hardware | 43288×

Zajímá vás jak komunikovat přes sériový port? Ptáte se, co to je? Myslíte si, že zmizel v hlubinách času? Ne tak docela...

Sériový port (neboli rozhraní RS-232) je jednoduchá univerzální sběrnice určená pro komunikaci mezi dvěma zařízeními, z nichž jedno je ve většině případů počítač.

Mohlo by se zdát zpátečnické zabývat se sériovým portem v dnešní době, která je poznamenána bouřlivým rozmachem USB, ale sériový port ještě dlouhou dobu zůstane používaným standardem zejména pro svou rozšířenost a jednoduchost. A právě tato jednoduchost je důvodem, proč různá amatérská elektronická udělátka bývají navržena pro připojení k sériovému portu a proč je mnoho jednočipových mikropočítačů vybaveno rozhraním RS232.

Obvyklý způsob použití sériového portu je čtení a zápis dat, přičemž nejmenší datovou jednotkou je jeden znak, který představuje nejčastěji osm bitů. Ne však vždy. Nešťastný historický vývoj obdařil sériový port schopností přenášet pět, šest, či sedm bitů v jednom znaku. Jakýkoli jiný počet než osm je ovšem pouze pro zlost. Proto aby se člověk divil, že přenos binárních dat nefunguje správně.

Říká se, že v *NIXech je všechno soubor - a platí to i o sériovém portu. Tím souborem je /dev/ttyS0, což představuje první sériový port, který zcela určitě ve svém počítači máte. Druhým sériovým portem je /dev/ttyS1, který už takovou samozřejmostí být nemusí (např. u laptopů nebo některých motherboardů). Chcete-li něco poslat do sériového portu, napište

echo Hello world! > /dev/ttyS0

Nemáte-li právo zápisu do /dev/ttyS0 (obvykle to smí pouze root), dostanete nejspíš hlášku "Permission denied". Zkoušet tyhle věci jako root je poněkud nerozumné, takže pro začátek bude lepší změnit práva pomocí

chmod a+rw /dev/ttyS0

To sice není o mnoho rozumnější, ale bezpečnost ponechme stranou. Nyní se tedy řetězec "Hello world!" bez reptání spláchne kamsi do útrob sériového portu. Kdyby na port bylo připojeno nějaké zařízení, mohlo by si tento řetězec přečíst. A dost možná, že by i odpovědělo. Odpověď by bylo možné přečíst pomocí

cat /dev/ttyS0

Jestliže nemáte připojené žádné zařízení, příkaz zůstane viset, protože nejsou k dispozici žádná data. Pokud zrovna nemáte po ruce zařízení, které komunikuje se sériovým portem, nevadí, lze jej snadno zhotovit svépomocí. Potřebujete k tomu pouze kousek alobalu od svačiny. Ten postačí k tomu, abyste v konektoru sériového portu propojili vývod pro vysílání (TxD) s vývodem pro příjem (RxD). Konektor má buď 9 nebo 25 vývodů. Ať už máte kterékoli provedení, jedná se o vývody (piny) číslo 2 a 3. Jednotlivé piny jsou označeny drobnými, takřka nečitelnými číslicemi vyraženými v umělé hmotě konektoru. Situaci v případě devítipinového konektoru ilustrují následující obrázky (fotografie se po kliknutí zvětší):

Číslování a význam pinů konektoru RS-232

Fotografie konektoru RS-232

Konektor RS-232 s propojeným 2. a 3. pinem

Jsou-li vývody 2 a 3 navzájem propojené, pak cokoli, co vyšleme, bude opět beze změny přijato. Toto lze snadno ověřit tím, že se v jednom terminálu spustí příkaz pro čtení (cat /dev/ttyS0) a následně ve druhém příkaz pro zápis (echo Hello world! > /dev/ttyS0). Jestliže to nedělá vůbec nic, byl to asi ten druhý port a místo /dev/ttyS0 patří /dev/ttyS1.

Výsledek však může být poněkud nečekaný. Počáteční nastavení parametrů sériového portu nemusí být totiž pro tyto pokusy zcela vhodné, a tak kupříkladu s mým jádrem a distribucí Linuxu začne příkaz cat /dev/ttyS0 vypisovat řetezec Hello world! stále dokola, přestože do portu již žádná data neposílám. Způsobuje to parametr echo, ale o tom se zmíním později.

Data tedy tečou z výstupního pinu na vstupní - ale jakou rychlostí? Přenosová rychlost se u sériového portu udává v tzv. baudech (baudrate), což je zhruba řečeno číslo, které říká, kolik bitů se přenese za jednu sekundu. Obvykle nejvyšší rychlost představuje 115200 a další možné rychlosti musí být dělitelem této rychlosti, např. 57600 = 115200/2 nebo 38400 = 115200/3 atd. Rychlost lze nastavit příkazem stty. Například

stty -F /dev/ttyS0 14400

Nastaví přenosovou rychlost na 14400 baudů. Příkazem stty lze také zjistit takřka veškerá nastavení portu.

stty -aF /dev/ttyS0

vypíše děsivé množství nepřehledných informací, zde je ukázka:

speed 14400 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>;    start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

Hned první údaj představuje přenosovou rychlost. Další informace z výpisu jsou vysvětleny v manuálové stránce příkazu stty. Parametry umožňují nastavit sériovému portu zcela nečekané chování, které mělo svůj význam v zaprášených dobách terminálů ovládaných po sériové lince. Bude nejlepší tyto vymoženosti vypnout či zakázat. Nechci zde rozebírat význam jednotlivých položek a také nezastírám, že mi mnohdy uniká. Pouze podotýkám, že rozumné nastavení sériového portu získáte příkazem

stty -F /dev/ttyS0 clocal cread -crtscts cs8 -cstopb hup -parenb parodd -brkint -icrnl ignbrk -igncr ignpar imaxbel -inlcr inpck -istrip -iuclc -ixany ixoff -ixon bs0 cr0 ff0 nl0 -ocrnl -ofdel -ofill -olcuc -onlcr -onlret onocr -opost tab0 vt0 -crterase crtkill -ctlecho -echo -echok -echonl -echoprt -icanon -iexten -isig -noflsh -tostop -xcase time 5 min 1

Příkaz stty umožňuje díky parametru -g vypsat nastavení v hexadecimální podobě, které je sice člověkem nečitelné, zato stty umí tento formát nastavení načíst zpátky. Tím je možno zazálohovat aktuální nastavení. Uvedu příklad. Pokud příkaz

stty -gF /dev/ttyS0

vypíše

500:5:cad:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

Je možné si toto nastavení kdykoli obnovit příkazem

stty -F /dev/ttyS0 500:5:cad:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

Jednotlivé parametry jsou několikerého typu. Nejčastěji mají možnost zapnuto/vypnuto, a pak, jestliže je nějaký parametr vypsán či zadán s předcházejícím mínusem (pomlčkou), je daná volba vypnuta. Konkrétní použití uvedu na příkladu nastavení paritního bitu. Příkaz

stty -F /dev/ttyS0 parenb parodd

zapne kontrolu parity (parenb = parity enable) a nastaví ji na lichou (parodd = parity odd). Sudou paritu (parity even) lze nastavit vypnutím liché parity, tedy příkazem

stty -F /dev/ttyS0 parenb -parodd

Pozor - existuje sice parametr evenp pro nastavení liché parity, ale ten radím nepoužívat - je to jen alias a navíc mění počet bitů v jednom znaku. Sudost či lichost ovládejte vždy pomocí parodd. Úplné vypnutí paritního bitu (parity none) se provede následovně:

stty -F /dev/ttyS0 -parenb

V tomto případě může být nastavení parodd jakékoli, protože se ignoruje. Pro úplnost uvádím, že parita se používá jako způsob detekce chyb v přenosu.

Dalším často zmiňovaným komunikačním parametrem je počet tzv. stopbitů. Bývá buď jeden, nebo dva. Přednastaven je jeden, ale volba cstopb umí zapnout další stop bit, čímž se jejich počet zvýší na dva. Tedy

stty -F /dev/ttyS0 cstopb

nastaví počet stopbitů na dva, zatímco

stty -F /dev/ttyS0 -cstopb

nastaví počet stopbitů na jeden.

Kromě parametrů, které mají možnost zapnuto/vypnuto, rozeznává příkaz stty ještě parametry s argumentem. Například počet bitů v jednom znaku se nastavuje volbou csn, kde n je počet bitů. Opět uvedu příklad:

stty -F /dev/ttyS0 cs8

cs8 nastaví počet bitů na osm. Jestliže najdete na smetišti nějaké pošetilé zařízení, které vyžaduje sedm bitů, lze sériový port přinutit i k tomuto poklesku:

stty -F /dev/ttyS0 cs7

ale raději to rychle vraťte zpátky na osm.

Dovolil bych si malé srovnání příkazu stty a jeho oškubaného dosovského protějšku MODE při nastavování parametrů sériového portu. Řekněme, že chceme nastavit baudrate = 9600, osm bitů na znak, sudá parita, jeden stop bit. Příkazem MODE v DOSu toho docílíme takto:

MODE COM1 9600,8,E,1

Totéž pomocí stty:

stty -F /dev/ttyS0 cs8 parenb -parodd cstopb 9600

přičemž k dispozici je celá škála dalších parametrů pro řízení toku dat, zacházení s chybami, timeouty, řídicí sekvence atd.

Nebývá jednoduché najít chybu v komunikaci, když sériový port (či spíše jeho driver) ze své vlastní iniciativy mění některé bajty, některé ignoruje a některé zopakuje vícekrát. Celkem častá je situace, kdy chceme, aby sériový port vyslal přesně to, co zapíšeme do /dev/ttyS0 a naopak z /dev/ttyS0 přečteme přesně to, co přišlo po drátech do portu. Mám tedy na mysli nastavení vhodné pro binární přenos. V tomto případě můžeme provést následující test: pošleme do /dev/ttyS0 posloupnost všech 256 možných bajtů a měli bychom dostat zpátky totéž. Pro tento účel přikládám ke stažení soubor bytes_00-FF.bin, který obsahuje bajty 0 až 255. Příkazem

xxd bytes_00-FF.bin

se můžete přesvědčit, co v souboru je:

0000000: 0001 0203 0405 0607 0809 0a0b 0c0d 0e0f ................
0000010: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f ................
0000020: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f !"#$%&'()*+,-./
0000030: 3031 3233 3435 3637 3839 3a3b 3c3d 3e3f 0123456789:;<=>?
0000040: 4041 4243 4445 4647 4849 4a4b 4c4d 4e4f @ABCDEFGHIJKLMNO
0000050: 5051 5253 5455 5657 5859 5a5b 5c5d 5e5f PQRSTUVWXYZ[\]^_
0000060: 6061 6263 6465 6667 6869 6a6b 6c6d 6e6f `abcdefghijklmno
0000070: 7071 7273 7475 7677 7879 7a7b 7c7d 7e7f pqrstuvwxyz{|}~.
0000080: 8081 8283 8485 8687 8889 8a8b 8c8d 8e8f ................
0000090: 9091 9293 9495 9697 9899 9a9b 9c9d 9e9f ................
00000a0: a0a1 a2a3 a4a5 a6a7 a8a9 aaab acad aeaf ................
00000b0: b0b1 b2b3 b4b5 b6b7 b8b9 babb bcbd bebf ................
00000c0: c0c1 c2c3 c4c5 c6c7 c8c9 cacb cccd cecf ................
00000d0: d0d1 d2d3 d4d5 d6d7 d8d9 dadb dcdd dedf ................
00000e0: e0e1 e2e3 e4e5 e6e7 e8e9 eaeb eced eeef ................
00000f0: f0f1 f2f3 f4f5 f6f7 f8f9 fafb fcfd feff ................

V jednom terminálu pusťte

cat /dev/ttyS0 | xxd

a v jiném

cat bytes_00-FF.bin > /dev/ttyS0

Výsledkem by mělo být

cat /dev/ttyS0 | xxd
0000000: 0001 0203 0405 0607 0809 0a0b 0c0d 0e0f ................
0000010: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f ................
0000020: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f !"#$%&'()*+,-./
0000030: 3031 3233 3435 3637 3839 3a3b 3c3d 3e3f 0123456789:;<=>?
0000040: 4041 4243 4445 4647 4849 4a4b 4c4d 4e4f @ABCDEFGHIJKLMNO
0000050: 5051 5253 5455 5657 5859 5a5b 5c5d 5e5f PQRSTUVWXYZ[\]^_
0000060: 6061 6263 6465 6667 6869 6a6b 6c6d 6e6f `abcdefghijklmno
0000070: 7071 7273 7475 7677 7879 7a7b 7c7d 7e7f pqrstuvwxyz{|}~.
0000080: 8081 8283 8485 8687 8889 8a8b 8c8d 8e8f ................
0000090: 9091 9293 9495 9697 9899 9a9b 9c9d 9e9f ................
00000a0: a0a1 a2a3 a4a5 a6a7 a8a9 aaab acad aeaf ................
00000b0: b0b1 b2b3 b4b5 b6b7 b8b9 babb bcbd bebf ................
00000c0: c0c1 c2c3 c4c5 c6c7 c8c9 cacb cccd cecf ................
00000d0: d0d1 d2d3 d4d5 d6d7 d8d9 dadb dcdd dedf ................
00000e0: e0e1 e2e3 e4e5 e6e7 e8e9 eaeb eced eeef ................
00000f0: f0f1 f2f3 f4f5 f6f7 f8f9 fafb fcfd feff ................

Připomínám, že piny 2 a 3 musí být navzájem propojené. Dostanete-li jiný výsledek, neznamená to, že je něco špatně. Vše závisí na způsobu použití. Kupříkladu volba

stty -F /dev/ttyS0 igncr

způsobí, že se všechny bajty přenesou beze změny, kromě bajtu s hodnotou 0x0d = 13 a dostaneme tedy

0000000: 0001 0203 0405 0607 0809 0a0b 0c0e 0f10 ................
0000010: 1112 1314 1516 1718 191a 1b1c 1d1e 1f20 ...............
0000020: 2122 2324 2526 2728 292a 2b2c 2d2e 2f30 !"#$%&'()*+,-./0
0000030: 3132 3334 3536 3738 393a 3b3c 3d3e 3f40 123456789:;<=>?@
0000040: 4142 4344 4546 4748 494a 4b4c 4d4e 4f50 ABCDEFGHIJKLMNOP
0000050: 5152 5354 5556 5758 595a 5b5c 5d5e 5f60 QRSTUVWXYZ[\]^_`
0000060: 6162 6364 6566 6768 696a 6b6c 6d6e 6f70 abcdefghijklmnop
0000070: 7172 7374 7576 7778 797a 7b7c 7d7e 7f80 qrstuvwxyz{|}~..
0000080: 8182 8384 8586 8788 898a 8b8c 8d8e 8f90 ................
0000090: 9192 9394 9596 9798 999a 9b9c 9d9e 9fa0 ................
00000a0: a1a2 a3a4 a5a6 a7a8 a9aa abac adae afb0 ................
00000b0: b1b2 b3b4 b5b6 b7b8 b9ba bbbc bdbe bfc0 ................
00000c0: c1c2 c3c4 c5c6 c7c8 c9ca cbcc cdce cfd0 ................
00000d0: d1d2 d3d4 d5d6 d7d8 d9da dbdc ddde dfe0 ................
00000e0: e1e2 e3e4 e5e6 e7e8 e9ea ebec edee eff0 ................

Všimněte si, že bajt 0x0d chybí. Měl by být hned v prvním řádku. Uvádím to pouze pro demonstraci zdánlivě podivného chování, které někdy může být i žádoucí.

       

Komentáře

[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