Dotaz: Při otevření sériového portu se aktivuje signál RTS - nežádoucí!

[Ilfirin]

Dobrý den. Snažím se napsat jednu aplikaci v Pythonu (ale to není důležité) a mám problém.

Zařízení které mám připojené k sériovému portu reaguje na signál RTS tak, že se přepne do programovacího režimu. I když mám hned druhý řádek programu vynulování RTS (v programovacím módu se to se mnou moc nebaví), při otevření portu se RTS stejnak na krátkou dobu nastaví. To stačí na to, aby se mnou to zařízení již nekomunikovalo.

Snažil jsem se, seč to šlo. Dokonce jsem si zničil knihovnu pySerial, aby nebyla schopná RTS nastavit, závada nezmizela.
Hádám tedy, že moje potíže způsobuje právě "Linux". Pročítal jsem manuál k stty, zkoušel plno věcí a opět neuspěl (ale zjistil jsem, že jakákoli operace s stty a ttyS0 obecně RTS také sama nastaví).

Prosím o radu

Děkuji

Odpovědi

[Petr Šobáň]

Asi by bylo vhodné uvést jak s tím portem komunikuješ.

Asi budeš muset použít nějaký přímý přístup k portu a nepoužívat nějaké nádstavby.

[Ilfirin]

Ona nástavba je PySerial (také dost nízko-úrovňová bych řekl).
Ovšem, jak jsem už napsal, RTS se aktivuje při jakékoli práci s portem. I při čtení informací o portu s stty. Testovací program je otevriport(), zavriport().

[trekker.dk]

Zkus vypnout RTS/CTS handshaking toho portu dřív, než ho otevřeš (stty -F /dev/ttySx -crtscts), třeba to pomůže.

[Ilfirin]

Teď už nejsem v práci, a ono zařízení doma nemám, tak nemohu vyzkoušet. Ale jsem si jistý, že to jsem už dělal.
Zkoušel jsem totiž příkaz z článku Sériová komunikace pod Linuxem:

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

[Pavel Stárek]

Že by to byla nějaká featúra kernelu? Zkusil bych to ještě ve windows jestli k nim máš přístup. Jinak já pro jistotu používám toto (ale jestli to má vliv na stav RTS nevím):

port = serial.Serial("/dev/ttyS0", baudrate=9600, rtscts=0)

Ale jak říkám jestli to rtscts=0 má vliv na stav signálu RTS nevím. Jde o to jestli to není taky nějaká hardwarová záležitost (nějaký USB to serial převodník) který se takto chová. Popřípadě bych ten drátek na chvilku odpojil. A připojil bych ho až když bych chtěl programovat to zařízení (což je asi krajní případ, to odpojení drátku).

[Ilfirin]

I tento řádek mi okamžitě hodí RTS do jedničky. Zkrátka jak se šáhne na port, je to tam. Ve Windows.. mám aplikace (ne mnou napsané) a ty fungují. Vtip je v tom, že jsem si chtěl napsat vlastní aplikace pod Linuxem a narazil.

Zkusím to ještě zítra s čistou hlavou, třeba jsem něco přehlédl.

[Ilfirin]

Tak stále neúspěšný. rtscts mám vypnutý jak s pomocí stty, tak i jako parametr otevření portu v Pythonu. Přesto k sepnutí RTS dojde při každé práci s portem.

Hodně divné mi je, že k němu dojde i při pouhém čtení nastavení stty. Zkrátka mi ho spíná vždy .

[Ilfirin]

Konfigurace portu:

michals@air:~> stty -aF /dev/ttyS0
speed 19200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany imaxbel -iutf8
-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

[Pavel Stárek]

A když se v Céčku přeloží a spustí tenhle kousek kódu (+ nějaká main funkce), nahodí se to RTS taky?

    #include <stdio.h>   /* Standard input/output definitions */
    #include <string.h>  /* String function definitions */
    #include <unistd.h>  /* UNIX standard function definitions */
    #include <fcntl.h>   /* File control definitions */
    #include <errno.h>   /* Error number definitions */
    #include <termios.h> /* POSIX terminal control definitions */

    /*
     * 'open_port()' - Open serial port 1.
     *
     * Returns the file descriptor on success or -1 on error.
     */

    int
    open_port(void)
    {
      int fd; /* File descriptor for the port */


      fd = open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NDELAY);
      if (fd == -1)
      {
       /*
	* Could not open the port.
	*/

	perror("open_port: Unable to open /dev/ttyS0 - ");
      }
      else
	fcntl(fd, F_SETFL, 0);

      return (fd);
    }

Co sem koukal různě po netu, tak by to RTS mělo být po otevření portu shozené. Není to opravdu nějaká HW anomálie u tebe? On ten port může být klidně nějak poškozený a to RTS může být nahozené stále. Při bootu bych vlezl do BIOSu (čili neběží nic) a šáhnul bych tam měřákem, jaký bude stav té RTS linky.

[Ilfirin]

Děkuji moc za kód.
Bohužel, nejsem c-čkař, takže vypotění toho main trochu trvalo a ještě mě gcc seřval, že jsem udělal main jako nenávratovou funkci, ale k věci.

Stejné chování . Opět problikne RTS signál. Hardwarová anomaile to není, RTS je v nule. Teprve až otevřením portu se přepne (mám to naměřené i osciloskopem -12V -> +12V) do jedničky. Jak jsem psal, druhá řádek kódu mi jej shodí opět do nuly (pokud takový ten řádek kódu bude, samozřejmě) ale to už je pozdě, už tam ta jednička byla.

[Pavel Stárek]

Hmm, tak jedině tedy odpojit ten drátek. A nebo nějak donutit to zařízení aby se přeplo do programovacího módu pokud ten RTS signál trvá třeba vteřinu (nebo nějakou jinou vhodnou dobu).

[trekker.dk]

Teprve až otevřením portu se přepne (mám to naměřené i osciloskopem -12V -> +12V) do jedničky.

Pozor - tohle (-12V -> +12V) je přepnutí do log. 0. Možná ne pro tvou elektroniku, která je na to připojená, ale pro ten port určitě.

http://rs232.hw.cz/#urovne

[Ilfirin]

Dobrá, spletl jsem si úrovně.

[trekker.dk]

Mě šlo spíš o to, jestli tohle nezpůsobí ten problém - pokud ne, tak jako bych nic neřekl.

[Ilfirin]

Ne, bohužel. Nicméně mě to nesměrovalo semhle (protože ty úrovně jsem naměřil dobře - klid = -12V, aktivita = 12V, jen je špatně zinterpretoval). Citace:

Hardware vs. Software Flow Control

If feasible, it's best to use "hardware" flow control that uses two dedicated "modem control" wires to send the "stop" and "start" signals. Hardware flow control at the serial port works like this: The two pins, RTS (Request to send) and CTS (Clear to send) are used. When the computer is ready to receive date it asserts RTS by putting a positive voltage on the RTS pin (meaning "Request To Send to me").

Ovšem rtscts mám vypnuté jak už mi zde radili

[trekker.dk]

Pak už mě napadá jenom prohrabat se zdrojáky jádra a zkusit najít, kde se to zapínání RTS děje (Nebo spíš vzhledem k tomu, že neumíš C, zeptat se někde v lkml)

A nebo, jak psal někdo výš, přemluvit to zařízení, aby reagovalo jen na delší RTS signál (buď změnou SW nebo hardwarově např. RC členem mezi portem a zařízením.)

[Pavel Stárek]

No nedalo mi to a prolezl jsem si zdrojáky jádra, a našel jsem tam zajímavý kousek kódu:

... snip
if (init_hw) {
176                         /*
177                          * Initialise the hardware port settings.
178                          */
179                         uart_change_speed(state, NULL);
180
181                         /*
182                          * Setup the RTS and DTR signals once the
183                          * port is open and ready to respond.
184                          */
185                         if (info->tty->termios->c_cflag & CBAUD)
186                                 uart_set_mctrl(port, TIOCM_RTS | TIOCM_DTR);
187                 }
... endsnip

Je to kousek souboru drivers/serial/serial_core.c, funkce uart_startup (ta je volána z uart_open tuším) . A vypadá to, podle těch posledních dvou řádků, že za nějakých podmínek (ten if) se skutečně nahodí RTS a DTR. Tudíž by to asi chtělo ten druhý řádek uart_set_mctrl zakomentovat a přeložit jádro a vyzkoušet co to bude dělat.

[Ilfirin]

Ok . Díky moc, kouknu na to (jo, půjdu zítra do práce).

[Pavel Stárek]

Jeste pripominam ze ten vypis je z kernelu 2.6.25.4 koukal jsem na to tim git web rozhranim na kernel.org . Myslim si ale ze to bude stejne i pro jinou verzi rady 2.6, co by na tech seriovych portech vymýšleli

[Ilfirin]

Je to neuvěřitelné, ale stále stejné chování .

[Pavel Stárek]

Tak, a už toho mám dost (nebrat vážně !) Je to klasický sériový port na motherboardu (ty co mají adresu portu 0x3f8, 0x2f8), nebo je to nějaký USB2RS232 převodník? Ono těch serial driverů je totiž v kernelu více, takže jsi(jsme) sice zakomentoval správný řádek, ale u jiného driveru a možná je to (to nahození RTS) ještě někde jinde. Jdu se podívat do git stromu kernelu.

[trekker.dk]

Ono těch serial driverů je totiž v kernelu více, takže jsi(jsme) sice zakomentoval správný řádek, ale u jiného driveru.

AFAIK se to, co je v serial_core, používá pro všechna sériová zařízení, protože je to nezávislé na hardwaru. Což ale nevylučuje ten zbytek věty, tj.:

a možná je to (to nahození RTS) ještě někde jinde

[Pavel Stárek]

Tak jsem to ještě procházel a v souboru drivers/serial/8250.c ve funkci autoconfig_irq() se taky (asi) nahodí ten RTS. Jsou tam řádky:

...
if (up->port.flags & UPF_FOURPORT) {
		serial_outp(up, UART_MCR,
			    UART_MCR_DTR | UART_MCR_RTS);
	} else {
		serial_outp(up, UART_MCR,
			    UART_MCR_DTR | UART_MCR_RTS | UART_MCR_OUT2);
	}
...

Zkusil bych z toho vyházet ty UART_MCR_RTS, tudíž poté by ten kousek kódu vypadal takhle:

...
if (up->port.flags & UPF_FOURPORT) {
		serial_outp(up, UART_MCR,
			    UART_MCR_DTR);
	} else {
		serial_outp(up, UART_MCR,
			    UART_MCR_DTR | UART_MCR_OUT2);
	}
...

Tento driver je tuším pro klasické porty na motherboardu (čipy 8250/16550 atd.). Ovšem oni si při vlezení do té funkce uloží stav těch DTR,RTS (celý ten stavový registr) a po výlezu ten uložený stav zase vrátí, takže to nastavení RTS musí trvat strašně malou dobu. Ale koukal jsem například do zdrojáku ovladače pro sériové karty Moxa (drivers/char/mxser.c) a tam to RTS nahazují ve funkci mxser_startup() taky, takže je to skutečně nějaká (blbá) featůra kernelu. Nezbude nic jiného a na kabel si dát nějaký přepínač kterým se ta RTS linka přeruší.

[trekker.dk]

No ona ta featůra tak blbá není. Vem to tak, že RTS je signál, kterým se (normálně) dává najevo druhé straně, že může vysílat. Bylo by docela trapné, kdybys v každém programu, který používá RTS/CTS řízení provozu, musel kontrolovat, jestli je RTS v log.1 a kdyžtak ho přepnout.

Že tohle chování nevyhovuje lidem, kteří na sériák věší lecjak udělané leccos, je věc druhá. Faktem je, že když je RTS/CTS vypnuté, tak je zapínání/vypínání RTS poněkud nadbytečné, ale pravděpodobně to ještě nikomu nevadilo natolik, aby kvůli tomu posílal patch...

[Pavel Stárek]

Asi máš pravdu. A rozhodně nehodlám posílat patch, protože ty moje úpravy jsou takové "ošklivé" a ani se neví jestli fungují (zatím spíš ne) (jo kdyby se udělal parametr třeba activate_rts a patřičně by se tam doplnily testy na tento parametr tak to by bylo něco jiného). Spíš mě zaráží, že ve Windows to prý funguje.

[Ilfirin]

Děkuji moc za rady. Ale zkouším začít opět od začátku, vypozorovat to chování ve Windows atd. Zkrátka je mi líto nutit vás lítat do jader, když si vinou Linuxu nejsem moc jist.
Dám vědět, jak vyšetřování dopadlo

[Pavel Stárek]

Zkrátka je mi líto nutit vás lítat do jader, když si vinou Linuxu nejsem moc jist.

O to nejde, já se do toho jádra rád podívám , protože v naší firmě taky používáme sériový port na různé komunikace, tak mě to zajímalo - abych pak nebyl překvapen . Ale jak jsem psal výše, po studiu lowlevel ovladačů v jádře (8250.c a mxser.c) je vidět že se to RTS běžně nahazuje při inicializaci (a možná i po otevření portu) a jak psal kolega trekker.dk je to asi dobře, ačkoliv já si myslím, že pokud nechci řízení toku RTS/CTS tak by se ta linka RTS měla nechat při otevření portu napokoji . Je tedy lepší počítat s tím v hw/sw toho protějšku se kterým člověk komunikuje pomocí seriového portu, a/nebo si prolézt ty zdrojáky jádra a ty aktivace RTS při inicializaci (nebo otevření) portu vyházet.

[Petr Tomášek]

Tudíž by to asi chtělo ten druhý řádek uart_set_mctrl zakomentovat a přeložit jádro a vyzkoušet co to bude dělat.

Tudíž by to chtělo zakomentovat oba řádky, neb je to podmínka...

[Ilfirin]

Stačí jeden, holt se při podmínce nic nestane. Ale měl jsem zakomentované oba. Teď spíš hledám chybu jinde (respektive simuluji na Windows). Jestli to někdy vyřeším, bude z toho velký blog.

[Pavel Stárek]

No všiml jsem si toho pozdě, ono tam nebylo to klasické:

if (neco) {
  prikaz;
}

ale ta jednořádková podmínka. Takže tazatel to pochopil, jak se to má zakomentovat .

[Pavel Stárek]

Stále mi to nedá, provedl jsem vlastní výzkum ve Windows:

Python 2.5.1 (r251:54863, May  1 2007, 17:47:05) [MSC v.1310 32 bit (Intel)]
Type "help", "copyright", "credits" or "license" for more information.
>>> import serial
>>> port = serial.Serial("COM1")
>>> port._rtsState
1
>>> port.setRTS(0)
>>> port._rtsState
0
>>> port.open()
>>> port._baudrate
9600
>>> port.bytesize
8
>>> port._rtsState
1
>>> port.setRtsCts(0)
>>> port._rtsState
1
>>> port.setRTS(0)
>>> port._rtsState
0
>>> 

z něhož je vidět že to RTS nahazují i Windows. Dokonce když se ještě před voláním open to RTS shodí, tak po zavolání open a po vypnutí hw řízení toku dat ( setRtsCts(0) )je opět aktivní a musí se shodit. Ale skusím ještě jeden pokus ve Visual Basicu 6 (no moc se nesmějte )

[Ilfirin]

Nesměju.
Tvůrci aplikace jsem už poslal mail, ať mi vyrobí ultra-light verzi s jedinou maličkou funkcí ve VisualStudiu, takže to nebude umět nic, než otevřít port, pingnout, zavřít port.

To půjde pustit jak ve Windows, tak v Linuxu (Mono) a budu jí mít jako referenční aplikaci (hele, tady jo a tady ne).

Mezitím jsem zkoušel vylepšit (s tou neznalosti C jsem trochu kecal, ale je opravdu hrubě základní) ten program v C, ale ať přidávám jakékoli parametry a zapínám vypínám handshaky, blikne to tam :-/.

[Pavel Stárek]

To nesmějte se mělo být ne na tebe ale na veškeré osazenstvo (už je slyším, jéé Visual Basic no to je hrůza ). Ale jinak prostředky VB6 (tedy komponenta MSCOMM32.OCX) jsou přímo strašné, tudíž jsem toho mnoho nezjistil. Ale to "bliknutí" opravdu udělá to otevření, nebo konfigurace portu. Je to vidět v těch zdrojácích kernelu, jak jsem psal výše. (linux/drivers/serial/8250.c - funkce autoconfig_irq() a ta je volána tuším zase z funkce serial8250_config_port() a tu zase volá serial_core.c jako jednu z operací portu právě při otvírání nebo inicializaci (mám pocit že něco z toho se volá už při bootu jádra), no ty vazby v kernelu jsou někdy hrůzostrašné, ale zase se, díky tvojemu problému (trochu) vyznám v serial subsystému jádra )

[Ilfirin]

Ach jo!

Jsem z toho už v pr... . Ve Windows ve Visual Studiu to funguje hned. Binárka z VisualStudia nejde v mono 1.9.1 spustit (nedává na System.IO.Ports) takže opět nic.

Nu co no. Tak zahodím Python, Linux a asi se půjdu učit C#, jinak nevím, kudy cesty dál.

PS.: Ve Visual Studiu je "EnableRTS" option která je defaulně nastavená na False. Musí se povolit na True, aby se to začalo chovat tak jak se mi to chová.

[Pavel Stárek]

Bodejď by to nenadávalo, ten kolega, co to psal v nějakém VS tam určitě natvrdo zadrátoval COM1. Zkus v linuxovém Monu přeložit tento příklad a poreferuj. Samozřejmě si ho patřičně uprav. Ještě se zkusím podívat do pySerial protože ještě dneska jsem dělal pokus: po čerstvě naběhlých windows bylo RTS neaktivní, a jen jsem v Pythonu otevřel port tak se nahodilo.

[Ilfirin]

Pardon za vzteklý výjev, omylem jsem pouštěl jinou aplikaci. Takže:

Kolega mi nechal volbu mezi COM1 a /dev/ttyS0 a natvrdo zadal enableRTS=False. A výsledek je (krom toho, že to v Monu běží ), že ve Windows to udělá to co má, otevře port, pošle data a nic, tak v Monu mi to to RTS sepne. Takže jsem vymazal RTS řádky z 8250.c a zrovna rekompiluji jádro.
Asi to pak bude chtít napsat vývojářům kernelu, protože to takhle přece nejde .

[Ilfirin]

Takže pokusy jsou u konce. Mám multiplatformní aplikaci v C#, která výslovně říká "nezapínej RTS" a pak otevře port.

Chování:
Windows - Otevře se port, RTS nereaguje
Linux - Při otevření se RTS sepne, ale ihned se sám opět vypne.

Ted můžeme spekulovat, zda to sepnutí RTS udělá Linux nebo Mono. Já osobně tipuji, že Linux si RTS sepne sám. Pak teprve koukne na to, co že to vlastně aplikace chce, Mono řekne, že RTS nechtělo, takže to Linux opět dodatečně vypne a je to tam .

[Pavel Stárek]

To sepnutí dělá linux (tedy pokud jsi neupravil ty zdrojáky jádra, tedy jak 8250.c tak i serial_core.c), avšak pozor, pythonovský pySerial 2.2 nahazuje RTS taky. Už jsem si udělal verzi která by neměla RTS nahazovat při otevření, tedy po příkazu např. port = serial.Serial("COM1") (ale vyzkoušel jsem ji jen ve Windows). Jinak ale musím souhlasit s trekkerem.dk protože ten HW by měl být navržen trošku jinak, tohle je haluz.

[Ilfirin]

Jj, na ten pyserial ve Windows jsem koukal taky, akorát jsem to nepsal sem do diskuze. Z té doby pochází můj příspěvěk, že nevím kde přesně je problém a že to musím prošetřit.

Já také souhlasím s trekkerem.dk, ale co mohu dělat. HW je, a já si chci udělat software.

Otázka je, má se tlačit směrem na jádro? Já si myslím že ano. RTS ať se spíná, když je povolené hardwarové řízení toku. Pokud ale uživatel chce mít všechny dráty pod kontrolou (jako že v mém případě musí mít), měl by mít tu možnost.

Jádro je přeložené, uvidím zítra ráno a dám vědět.

[Ilfirin]

Bééééé! (brekot)

Tak ani tohle jádro nezabrání kmitnutí RTS.

[Ilfirin]

Jen pro úplnost:

Upravím zdrojáky v /usr/src/linux (symbolický link na zdrojáky linux-2.6.22.17-0.1).
Dám "make mproper"
zkopíruji funkční config z /boot/config-jádro
make menuconfig : upravím název jádra, abych si ho poznal
make rpm:
rpm -ivh hotový_kernel.rpm
mkinitrd
V Yastu si přidám položku zavaděče s vytvořeným (od mkinitrd) vmlinuz a initrd. Uložím
Přebootuji
"uname -r" mi vrací název mého jádra

Dělám něco špatně?

[Pavel Stárek]

No pokud ti to Suse žere tak asi nic špatně neděláš. A kde to konkrétně měníš? Pošli ty soubory sem na abíčko jako přílohu. Měl by se měnit ten linux/drivers/serial/serial_core.c a linux/drivers/serial/8250.c (tedy pokud je tvůj sériovy port klasický na motherboardu). Bohužel nevím, jak se v git stromu jádra přes webové rozhraní dostat na verzi 2.6.22, vždy mě to hodí na 2.6.25.4. Asi si sosnu 2.6.22.

[Ilfirin]

Přílohy:

• 8250.c (75991 bytů)
• serial_core.c (59477 bytů)

No, důležité je, že tam ty sekce jsou. Měním to přímo v tom /usr/src/linux.

[Josef Kufner]

Kdepak všude ještě je zmínka o RTS? grep -r RTS /usr/src/linux

Na ukázání tvých změn ostatním není špatný diff (nebo git a jemu podobné nástroje).

[Pavel Stárek]

Ale tak ja celkem tusim kde ty zmeny udelal. Ale mam pocit ze to bude jeste nekde. Chtelo by to nejak upravit to jadro globalne, tech seriovych driveru je tam hodne (ruzne usb a pci) a mam obavy ze nebude stacit uprava serial_core.c

[Voty]

Podle zdrojaku jadra zacinam mit pocit, ze nahozeni RST pri otevreni portu je zamyslena operace, nahazuje se spolecne s DTR. Krome pripadu, kdy je rychlost nastavena na 0.

[Ilfirin]

Ano, je to zamýšlená operace, ale co mají dělat ty, co tohle chování nechtějí . Existují zařízení (určitý druh 485 převodníků) co se nechají RTS signálem ovládat.

[trekker.dk]

To už jsem psal výše - napsat patch (aktivovat RTS pouze při zapnutém RTS/CTS řízení toku) a poslat ho do lkml.

Podle mě celý problém spočívá ve špatném chování toho HW - aktivace a téměř okamžitá deaktivace toho pinu by se skoro nechala považovat za zákmit, který se do toho kabelu může naindukovat i jinak. Je chyba, že to zařízení na tak krátký pulz vůbec reaguje.