Dotaz: Karta RS485 nečte

[mpi]

Mám kartu MSC-120B od aaexonu, je to 2x RS485 port. V Linuxu se identifikuje sama jako dva další sériové porty, ve Windows je třeba ovladač. Mám ale problém, že karta je v Linuxu schopna vysílat ale ne přijímat. Zdá se, že reaguje na signál RTS. Ve Windows ji lze nastavit v ovládacích panelech, aby tento signál nepotřebovala (active low) a pak funguje správně, tj. po vysílání se sama přepne na příjem. Lze ji takto nastavit v Linuxu? Kde? Nebo lze nějak nastavit sériovou linku, aby správně cvičila s tímto signálem ? (stty, setserial, konfigurační soubory,...). Zkusil jsem se dotazovat distributora i výrobce, zatím odezvu nemám. Jedná se o Ubuntu Kernel 2.6

Odpovědi

[mpi]

Chyba, jedná se mi o signál DTR, ne RTS.

[Pavel Vymetálek]

Pravděpodobně ten signál DTR bude použit k řízení směru komunikace (vysílání/příjem). Podle specifikace MSC-102B (jestli jste se překlepl na MSC-120B) je však směr řízen automaticky.

Zde na ABCLinuxu zadejte do políčka vyhledávání: DTR a vyjede Vám mnoho inspirace.

[mpi]

Ano, karta se řídí automaticky. Když se to ve Windowsech povolí. Je tam volba v nastavení přes ovládací panely "RS485 buffer enable" a když se nastaví na "low", tak to pak funguje jak má. Pro Win98 se tato volba jmenuje přímo "DTR function". Ovšem nevím, jak by se toto dalo nastavit v Linuxu. Připadá mi, že budu muset na to jít naopak, spíš nastavit ten signál DTR, než tu kartu.

[Pavel Vymetálek]

Pak doporučuji použít např. GtkTerm, picocom nebo jiný sériový terminál a nastavit DTR signál do požadované úrovně jím. V GtkTermu je přes F7 a hned uvidíte jestli Vám přichází nějaká data. Samozřejmě je třeba nastavit i další parametry přenosu: rychlost apod.

[mpi]

Ona ta karta v Linuxu kupodivu vysílá. A správně, adresovaný modul na lince zareaguje. Nic ale zpět nepřijme. Ani když mám propojené oba kanály, nepřečtu ani své vlastní vysílání. Při laborování ve Windowsovském terminálu, než jsem to nastavil, se mi ale zdálo, jako by signál DTR přepínal směr. Já pochopitelně budu potřebovat pracovat s jedním kanálem, vyslat a hned přečíst odpověď. Pokud se nepovede nastavit kartu jako ve Windows, budu muset asi s tím signálem DTR cvičit. Prakticky tedy udělat komunikaci řízenou DTR. Jak jsem pochopil, nastavením linky stty se DTR signál asi ovládat nedá, takže jedině přes ioctl ? Je to pro mě větší zkoušení, na které bohužel momentálně (pár dní) nemám čas, takže ani nemůžu napsat, jak to dopadlo. Bohužel pro Linux se tato karta jeví jako hračka bez návodu, žádný dostupný popis neříká, jak s kartou zacházet, instalační příručka píše jen o Windows. Bylo by lepší kartu nebo systém správně nastavit, než pokusně nastavovat signály a čekat, kdy karta obživne.

[Pavel Vymetálek]

Ano přes ioctl ovládat DTR jde. Ale nevím proč by měl být směr přepínán "ručně". Hlavně, pokud zařízení odpoví ihned, nemusíte stihnout směr přepnout. V době 2GHz procesorů je to úsměvné, ale je to tak...

Raději bych kontaktoval technickou podporu výrobce, Linux uvádí v podporovaných systémech!

[mpi]

To už jsem dávno udělal. Kontaktoval jsem českého distributora. Že prý s kartou nejsou problémy. Že se v Linuxu detekuje sama a ovladače nejsou třeba. A pak už se neozvali. Zkusil jsem i na tech. podporu výrobce, zatím žádnou odpověď nemám. Co se týče podpory Linuxu, zdá se mi, že jediná je v tom slově Linux, které je uvedeno v podporovaných systémech. Pravda je, že se karta zcela bez problémů v Linuxu objeví jako další dva sériové porty bez jakékoli potřebné instalace.

[Pavel Vymetálek]

Pak Vám nezbývá než laborovat s vlatsním programem nebo případně přes wine.

Dál se nabízí prozkoumat zdrojové kódy jádra (ovladač této karty - čipu), jak je tam (a jestli je) řešeno přepínání a nastavení těch portů.

Pak nabízím možnost vyzkoušení Vaší karty na našich servomotorech a linuxovém sw.

[mpi]

Budu laborovat, ale za pár dní. Přes Wine to asi nepůjde, ve Windows chce ta karta nainstalovat ovladač. Zkoušel jsem wine, port se terminálem otevřel, ale to bylo všechno. A windows na tom stroji, co to nakonec bude, vůbec nebudou. Vyzkoušet kartu jinde by bylo dobré, i když do Náchoda to mám poměrně daleko (Č. Budějovice). No, snad se mi to přes parametry open a ioctl povede nakonec zprovoznit.

[Mrazík]

Vypadá to, že karta používá čipset 16C950. V Linuxu se zřejmě chová jako 16C550, takže vysílání na RS485 se ovládá signálem DTR. To je možné programově řídit z userspace (asi termios nebo fcntl), ale problém je, že nepoznáte, kdy má vysílání skončit. Proto má 16C950 automatický mód, který hýbe pinem DTR podle toho, zda čip opravdu vysílá. Tento mód se dá nastavit zápisem do registru ACR[4:3] 10 nebo 11, podle budiče RS485. Nepřišel jsem ale na to, jak to udělat v Linuxu z userspace. Jedině snad přes ioctl přímým zápisem na port. Ale to je fuj. Možná to někdo najde a poradí.

[mpi]

Tak zrovna konec vysílání poznám, protože moduly se řídí protokolem Epsnet (Profibus), vím, kolik toho vysílám a hned po skončení vysílání musím být schopen přijímat, protože moduly vysílají okamžitě nazpět odpověď. Ovšem pokud se vysílání v systému bufruje a ioctl by nahazovalo stavy okamžitě, tak by to pochopitelně přepnulo na příjem dřív, než by to odvysílalo. Automatický mod se nastavuje na kartě propojkou, alternativou je přepnutí na řízení přes RTS. O DTR se prakticky nikde nemluví, jen v nastavení ovladačů pro windows - RS422/485 buffer - active High, Active low, Normal, implicitně je Normal a funguje to správně při Active Low. To, že myslím, že je to řízeno DTR vychází z toho, že pokud jsem to ještě neměl ve Winowsech nastavené, pustil jsem si ve Win dva terminály, propojil oba porty na jednu linku a zkoušel jsem jedním vysílat a signály ovládat ručně. Dokázal jsem přitom, že jeden vysílal a druhý přijímal (moje vysílání i odpovědi). Po nastavení ovladačů už jsem mohl komunikovat jedním portem, tj. přepínal se a stíhal to.

[Mrazík]

Však to odpovídá - active High je nastavení ACR[4:3] 11, active Low 10, Normal 00. Takže v Linuxu je to default v Normal a musíte to přepínat pomocí DTR "ručně". Ale nedělejte si iluze, že se vám to povede z userspace načasovat správně. Vysílání se kešuje a jsou tam různé latence, takže 10 ms žádná míra. A to bude asi na Profibus moc. Takže to ACR budete potřebovat nastavit. Ale alespoň už víte, co chcete.

[mpi]

Už jsem na to taky přišel po stažení datasheetu. Připadám si jako kdysi v MsDOSu, ale tam se dalo přímo psát do registrů portu a vynutit si cokoli.

[Aka]

Ohledne latenci, mrkni na:

man setserial low_latency

ioctl: TIOCSSERIAL

[mpi]

Snažím se do těch registrů toho portu zapsat nějakou hodnotu. Ale nejde mi to. iopl(2) - nelze nastavit. Takže outb(...) nelze použít.

zkoušel jsem char buf[2]; buf[0]=0; int ser=open("/dev/port",O_RDWR ); // a pokusně i jiné mody a oprávnění... lseek(ser,0xd030+7,SEEK_SET); //0xd030 je bázová adresa portu, reg. kam chci psát je o 111b dále write(ser,buf,1); .....

Ale nechce se mi ten soubor (/dev/port) otevřít. Když jsem to zkoušel se skutečným souborem, otevřel jsem ho a zapsalo se do něj to, co jsem chtěl.

/dev/port jsem přes sudo nastavil už zcela všechna přístupová práva. Přesto mi open vrací -1. Na internetu jsem našel příklady např na ovládání paralelního portu přesně tímto způsobem přes /dev/port

Lze tohle - přímý přístup na port - vůbec udělat v ubuntu ? Znalosti na opravu a překompilování kernelu nemám.

[mpi]

Podařilo se mi do těch registrů zapsat, karta se začala správně přepínat. Ovšem ten krátký prográmek musím spouštět přes sudo. Nastavení práv, ať hotovému programu, zařízení /dev/port nebo i té akci open() v programu, to vše nestačí. Odpovídá to názoru v jedné odpovědi, který pochybuje, jak to udělat pod userspace. Od výrobce jsem se dověděl, že karta používá běžný ovladač UARTu a že můj dotaz posílá odborníkům. Prostě, věta o podpoře Linuxu platí jen napůl, asi jen pro režim 422, který by měl být duplexní. Ale ten jsem nezkoušel.

[pc2005]

Jestli jsem diskuzi správně pochopil, tak by stačilo imho ten mód přepnout přímo v jaderném modulu, pak by to sudo nepotřebovalo.

[pc2005]

A ještě jen dodám k tomuto:

Znalosti na opravu a překompilování kernelu nemám.

Imho by mělo stačit vložit někam do inicializace modulu instrukci pro ten auto režim. V případě, že v ubuntu je ten ovladač jen jako modul, tak stačí nakompilovat a nahradit jen ten samostatný modul (a ne celé jádro).

[frr]

No moment, snad když to děláte přes sudo, tak to je pořád v user space, jenom tomu dáte rootovská práva, ne? Co takhle zařadit to (bez suda) někam do init skriptů? Co takový /etc/rc.local? (nebo se do toho motá ještě třeba SE-Linux?)

Ta karta má Oxford OX16PCI952, mám pravdu?

Řešil jsem stejný problém, pro karty Advantech PCI-16xx series. Je tam tuším ten háček, že ve standardním Linuxovém ovladači sériového portu se při open() ten ACR vyresetuje (pokud to už někdo neopravil i ve vanilce). Tu Vaši sekvenci je v tom případě potřeba provádět na již otevřeném zařízení. Já jsem to vyřešil krátkým patchem do hlavního stromu jádra, a napsal jsem si vlastní jaderný modul, který zajistí detekci PCI karty, zavedení vanilkového driveru pro UART z 8250.c pro patřičné bázové IO adresy a odpovídající nastavení ACR. Viz http://www.fccps.cz/download/adv/frr/pci-16xx/README.pci-16xx.html Pokud si přidáte IDčka Vaší karty do PCI-1604.c (a vyhodíte je z vanilkového jádra, případně vypnete 8250-pci.ko), tak by to mělo začít fungovat. Pozor na polaritu té speciální funkce DTR, jsou dvě možnosti. Nebo aspoň použijte ten patch na 8250.c a můžete si ACR bez obav inicializovat z init skriptu v user space (ACR zůstane nedotčen až do vypnutí počítače, bez ohledu na open(), close() apod.).

Jinak vanilkový kernel 2.6 už pár let zná a správně hlásí UART 16C950 (viz setserial), jenom tuhle jeho fičuru pro RS485 prostě nezná. Oxfordí UARTy jsou výborný hardware - žádné zjevné bugy (na rozdíl od některých jiných UARTů) a třeba 128B FIFO je taky výborná věc.

Podpora asijských výrobců pro Linux, to je vůbec hanba mluvit. Předkompilované binary-only ovladače zjevně oprásknuté z vanilky apod. Hlavně aby neprozradili svoje Intellectual Property, pitomci (přitom je ta funkce přehledně popsaná v Oxfordím datasheetu). Zrovna ten Oxford si vysloveně říkal o open-source driver, bylo to relativně málo práce.

Apropos, EPSnet - to pojede proti automatům Teco?

[mpi]

Tak tohle je opravdu komplexní řešení, mám co studovat. Problém byl, že jsem myslel, že budu řešit komunikaci s měřicími moduly (Elsaco) a místo toho řeším, jak vůbec číst sériovou linku a přizpůsobit si operační systém. U karty bylo napsáno, že podporuje Linux a teprve když jsem zjistil, že s ní nic nepřečtu, začal jsem studovat proč.

[frr]

Pokud ten EPSnet pojede v jednoduchém režimu "MAS/PC" (single master), mělo by se to stíhat i z user space (obsluha komunikace, ne přepínání 485 RX/TX - to má být v hardwaru). Díky 128B FIFO v UARTu by se Vám nemělo stát, že by Vám podteklo TX FIFO (=frame break) nebo přeteklo RX FIFO - a tempo výměn dotaz/odpověď si taktuje master.

Pokud se jedná o režim EPSnet MPC (multimaster s předáváním tokenu) nebo ještě hůř režim PLC, tam je potřeba rychlá reakce a z user space bych se trochu bál. Ale na jinak nezatíženém systému by to i tak mohlo fungovat. User-space proces se totiž vzbudí nejen při periodě plánovače (pravidelný takt), ale i při příchodu dat (interrupt od sériového portu) - pokud zrovna procesor nemá na práci něco jiného. Patrně zcela bez problému by to fungovalo, pokud byste to napsal jako kernelový modul, který by obsahoval celý EPSnetový stack, nebo aspoň potřebné nižší vrstvy, kritické na časování.

http://www.tecomat.cz/docs/cze/General/txv00106.pdf

[mpi]

Single master a jen několik měřicích modulů. Když to zkouším připraveným telegramem z terminálu, stíhá se to. Ale co se týče časování a bufrování, vím, že s tím mohou být problémy.

[frr]

> Znalosti na opravu a překompilování kernelu nemám.
>
Pokud se týče samotné kompilace kernelu a zavedení do systému, není potřeba se toho extra bát. Když už programujete pod Linuxem, je docela dobrá věc se to naučit. Patří to k věci. Svého času jsem pro někoho sesmolil návod.
Snad Vám to pomůže...

[frr]

Ještě jeden odkaz k RS485, trochu off topic - týká se terminace vedení a rozvodu referenčních zemí (nikoli Oxfordích UARTů v Linuxu)
[self-promotion] tady to roste [/self-promotion]

[mpi]

Výrobce AAEXON se ozval a doporučil pro Linux jinou kartu. MSC-102C Jak jsem se díval, vypadá to, že se to tam nastavuje na jumperech a ne softwarově. Já se přiznám, že už jsem to zkrotil, silou, programátorsky to čistý není.Prostě kombinací zpoždění odezvy a čekání po vysílání mám najednou dost času, abych se časově trefil. Není to na velký systém, už vůbec ne na regulaci, ale na několik měřicích modulů pro dlouhodobá sledování to vyhovovat bude. Radši bych byl, kdyby to bylo opravdu podporované, ať už čistě HW, nebo SW. Příště bych v podobném případě chtěl tu druhou kartu, nebo ještě radši USB převodník, vyvíjený přímo do této sestavy. Firma, která dělá celý systém, bude mít ošetřeno, aby to vzájemně fungovalo. Co se týče terminace, zemních smyček a předepínání, vím, co to dokáže. Tady to ale bude všechno poblíž, prakticky v jednom rozvaděči. Ale ještě jsme nezkusili ostrý provoz, až začnou cvakat relátka, spínat ventily a točit se motory, tak aby to najednou nepřestalo komunikovat.

A dotaz na admina - proč když jsem se registroval, mi registrace po napsání prvního příspěvku zmizela a od té doby sem lezu jako host? Ale maily s reakcemi mi pořád chodí, takže mail. adresa zaregistrovaná je.