Zobrazit příspěvky
1
Hardware / Re:Konvertor z RJ11 (RS232/C) na Ethernet
« kdy: 23. 05. 2025, 11:06:03 »
To zařízení se historicky původně jmenovalo "terminal server", přestože je to v dnešní době většinou malá až miniaturní krabička. Má to nějaký firmware způsobilý k TCP/IP, Ethernet (nebo wifi) a sériový port. V základní variantě je to TCP server = otevřete TCP spojení na konkrétní TCP port, a krabka spustí obousměrný relay TCP relace na svůj sériový port.
Sériový port má nějaké konfigurovatelné vlastnosti navíc, které TCP spojení postrádá.
Konfiguraci sériového portu je obvykle možno zařídit nějak "out of band", anebo taky in-band.
Jednak existuje RFC-2217, které káže několik dodatečných Telnet Options = v kontextu mechanismu escape sekvencí protokolu Telnet přidává pár kódů speciálně pro konfiguraci sériového portu (baud rate, formát znaku).
Kromě toho se někteří výrobci "terminálových miniserverů" uchylují k proprietární enkapsulaci transportu sériové komunikace nad TCP/IP - kde mají toto ovládání také pořešeno. Klientem je v tom případě obvykle proprietary "virtual COM port driver" do Windows (a k němu doprovodná konfigurační utilita).
Transport sériových dat nad TCP/IP není úplně transparentní v rovině časování. Pokud používáte virtuální sériák pod Windows a snažíte se, aby aplikace nepoznala, že nemá fyzický lokální COM port, může Vaše partyzánská činnost narazit na principielní vlastnost, že paketizace způsobuje nerovnoměrné rozestupy mezi znaky přijímanými v čase a prodloužení transportních latencí. Ovladač virtuálního COMu se obvykle nesnaží ve směru "příjem" reprodukovat rovnoměrné časování okamžiku příchodu jednotlivých znaků. Prostě přijme TCP paket a payload obsahující kdoví kolik znaků předá jedním vrzem čekající funkci recv() nebo read() nebo jak se to v klientském OS jmenuje. Pravidla pro paketizaci ze sériové linky do TCP mívají terminálové servery do jisté míry konfigurovatelná: po jak dlouhé pauze od posledního znaku ukrojit a odeslat paket, resp. po kolika znacích/bajtech (maximem je zřejmě MTU nebo MSS nebo jak se tomu).
Skrz generickou paketizaci nemusí projít nastojato některé protokoly, které nad fyzickou sériovou linkou dbají na striktní časování. Třeba Modbus/RTU má prohlásit "konec rámce" po ekvivalentu 3.5 znaku od posledního přijatého znaku. Takovéhle protokoly mívají bratříčka, který s TCP enkapsulací nativně počítá - a potřebujete "o něco chytřejší" gateway, která mezi oběma enkapsulacemi bude provádět relay v souladu s normou pro daný protokol. Třeba Modbus/RTU vs. Modbus/TCP, IEC-101 vs. IEC-104 apod.
Inteligentní relay konkrétních fieldbusů tradiční terminálové servery neuměly - ale už dávno existují varianty firmwaru, které takové věci umí buď jako svou pevnou náplň práce, nebo jako konfiguračně volitelnou vlastnost...
Pokud potřebujete od "terminálového serveru" obecně "něco svého", řešíte spíš možnost, dopsat si do takové krabičky svůj vlastní software. Tzn. ke krabičce přistupujete spíš jako k obecnému počítači, ve kterém uvítáte otevřený Linux (nebo tak něco) do kterého si dopíšete co je potřeba. Někteří výrobci tomuto využití jdou naproti (tradičně Lantronix, zřejmě taky ATOP a u některých modelů Advantech), u ostatních nevím.
Případně, pokud Vaše koncové zařízení na sériové lince má nějaký opravdu primitivní protokol, možná byste sehnal "průmyslovou krabičku se sériovým portem", která by to dokázala nějak pozřít a podat dál skrz jednoduché HTTP GUI nebo třeba MQTT apod. Třeba váha pošle řetězec zakončený konkrétním znakem, buď v pravidelném časovém intervalu, nebo v reakci na událost, nebo v opravdu krajním případě na nějakou výzvu po sériové lince... Jako že by to šlo naklikat bez programátorské práce.
Terminálové servery velké jako krabičku sirek či cigaret dělá v dnešní době spousta výrobců. Lantronix je zřejmě pradědeček, tuzemského Papoucha už tu taky někdo zmínil, osobně znám pár dalších značek (Advantech, ATOP, Moxa, Korenix, Westermo) ... prakticky kdokoli v Číně kdo má nos mezi očima to vyrábí v garáži (a jeho babička). Samozřejmě je možné to postavit zcela po svém na dnešních otevřených platformách typu RPi nebo ESP32.
Není pravda, že "většina sériových donglů na USB má RS232 výstup na elektrických úrovních TTL". Pokud Vám to tak připadá, doporučuji Vám udělat si podrobnější průzkum trhu a pořádek ve zbožíznalství :-)
Sériový port se skládá obecně ze dvou čipů: UART (= posuvný registr) a "level shifter" = analogový opakovač, budič linky. Ideové blokové schéma s polaritami signálů najdete třeba tady (disclaimer: samožer).
UART je součástka společná pro RS232/422/485. UART s level shifterem se baví na elektrických úrovních TTL. Teprve level shifter vyrábí kýžené napěťové úrovně pro RS232 nebo 422/485 (nebo třeba M-bus, ten má taky zcela svoji fyzickou vrstvu). Kolmá poznámka: budu dále abstrahovat od detailu, že pro half-duplexní varianty sériové linky (RS485 a snad i M-bus) je vhodné mít z UARTu vyvedený signál TSRE aka TEMT, což třeba klasický TI 16C550A UART nemá.
Konkrétně RS232 má platné logické úrovně 3 až 15 Voltů od společné referenční země, bipolárně plus a mínus. Samotná zem (nula voltů) je zakázaný stav, zavřený ve Schmittově hysterzi. Existuje mnoho level shifterů, které si "divné" napěťové hladiny pro RS232 vyrábí z jediné vstupní napájecí větve (3.3V nebo 5V) on-chip RC nábojovou pumpou, a na výstupech pak vidíte třeba něco jako +/-6 nebo +/- 10 V. Nebo třeba jenom +/- 5V u některých USB donglů. Ale nenechte se zmást, těch "asi 5 Voltů" bývá bipolárně kolem nuly. Taky si všimněte, že polarita logických úrovní je na RS232 lince opačná (invertovaná), oproti interní TTL komunikaci mezi UARTem a level shifterem. Pokud tedy narazíte na dongle, který produkuje TTL (cca 5V / 0V), tzn. nedává zápornou úroveň, a přitom používá "polaritu jako RS232", tak se jedná o paskvil / zmetek / čínskou inovaci - osobně takových mnoho nevídám.
Ano, jsou k nalezení levné USB/serial dongly s výstupními úrovněmi TTL - protože postrádají level shifter. Třeba známá firma FTDI takové varianty nabízí, vedle bratříčků s level shifterem pro RS232 nebo RS485. Dongle bez level shifteru je v tomto případě řádně označen. Bavíte se v tomto případě navenek přímo s UARTem.
K čemu to?
Mnoho malých krabiček (levné routery) mají vyvedenu sériovou konzolu právě na úrovních TTL rovnou z UARTu. Proč: protože použitý SoC/CPU/MCU obsahuje UART nebo dva on chip, a servisní konzola je typickým účelem takové sériové linky. Ovšem ta linka zůstává za normálních okolností schovaná pod kapotou, a použije ji jenom znalý servisák, pokud za vzácných okolností není zbytí - možná ji použije fabrika pro upload firmwaru (pokud toto nemají ošetřeno jinak, třeba přes JTAG nebo SPI). Jedná se o využití na kratičkou vzdálenost, v kontrolovaných laboratorních podmínkách. Poškození "divočejším počasím" nebo nešikovností uživatele až tolik nehrozí. Pro tyto potřeby je škoda utratit dolar nebo dva navíc za level shifter.
USB/serial dongly jsou založeny na čipech několika populárních výrobců: FTDI, Prolific, Silicon Labs, WinChipHead, Moschip, teoreticky taky Exar něco má, možná někdo další by se našel...
USB/serial nemá svou vlastní třídu USB zařízení. Asi nejblíž je CDC-ACM, což je ale třída specificky pro USB modemy. Možná proto výrobci USB/UART čipů CDC-ACM obecně ignorují a používají každý své rozhraní na USB. Proto taky do Windows potřebujete pro USB/serial dongly vždy specifický driver od výrobce UART čipu - protože Windows neobsahují class-based driver, protože neexistuje jednotná třída rozhraní.
Kupodivu Linux obsahuje ovladač usbserial.ko. Tento ovladač sdružuje HW-specifické open-source drivery pro větší počet výrobců čipů :-) Je možné, že tam je nějaká synergie (sdílení kódu) v transportu dat mezi TTY subsystémem a USB endpointem... navenek se to chová úplně jako class-based ovladač :-) Prostě v Linuxu drivery pro USB/serial dongly naprosto neřešíte. Píchnete do počítače anonymní dongle co jste našli válet zaprášený v racku, a ejhle, kernel našel /dev/ttyUSB0, minicom funguje...
No a pokud se týče Androidu: ten má přece uvnitř linuxový kernel, žeano. Takže by snad měl automaticky obsahovat ovladače pro USB UARTy výše zmíněných "obvyklých podezřelých" výrobců...
Omyl vážení! Pardon - tahle zkušenost je už třeba 5 let stará, doufám že nekecám. Osobně do mobilních OS nefušuju - ale bavil jsem se chvíli s hobbíkem, který si pro Android programoval nějakou odposlechovou appku se sériovou komunikací. Android rozhodně vanilkový usbserial driver v kernelu neobsahoval. Naopak existovala/existuje na githubu open-source knihovna pro Javu, která s využitím tuším libusb obsluhuje USB UARTy několika značek. Původně třeba dvou, ale na Githubu projekt dosáhl už v té době několika forků, z nichž ty poslední podporovaly už asi 5 výrobců. Momentálně mi Google ukázal zřejmě "mateční rostlinu", které se evidentně dobře daří a má na okraji repa zmíněno 1600 forků...
= potřebujete v Javě naLinuxuAndroidu sáhnout na USB port? Zkompilujte si ze zdrojáků knihovničku, která ty čipy bude obsluhovat z user space... Sodoma a Gomorra. Naštěstí tyhle USB UARTy mívají docela dlouhé FIFO.
Sériový port má nějaké konfigurovatelné vlastnosti navíc, které TCP spojení postrádá.
Konfiguraci sériového portu je obvykle možno zařídit nějak "out of band", anebo taky in-band.
Jednak existuje RFC-2217, které káže několik dodatečných Telnet Options = v kontextu mechanismu escape sekvencí protokolu Telnet přidává pár kódů speciálně pro konfiguraci sériového portu (baud rate, formát znaku).
Kromě toho se někteří výrobci "terminálových miniserverů" uchylují k proprietární enkapsulaci transportu sériové komunikace nad TCP/IP - kde mají toto ovládání také pořešeno. Klientem je v tom případě obvykle proprietary "virtual COM port driver" do Windows (a k němu doprovodná konfigurační utilita).
Transport sériových dat nad TCP/IP není úplně transparentní v rovině časování. Pokud používáte virtuální sériák pod Windows a snažíte se, aby aplikace nepoznala, že nemá fyzický lokální COM port, může Vaše partyzánská činnost narazit na principielní vlastnost, že paketizace způsobuje nerovnoměrné rozestupy mezi znaky přijímanými v čase a prodloužení transportních latencí. Ovladač virtuálního COMu se obvykle nesnaží ve směru "příjem" reprodukovat rovnoměrné časování okamžiku příchodu jednotlivých znaků. Prostě přijme TCP paket a payload obsahující kdoví kolik znaků předá jedním vrzem čekající funkci recv() nebo read() nebo jak se to v klientském OS jmenuje. Pravidla pro paketizaci ze sériové linky do TCP mívají terminálové servery do jisté míry konfigurovatelná: po jak dlouhé pauze od posledního znaku ukrojit a odeslat paket, resp. po kolika znacích/bajtech (maximem je zřejmě MTU nebo MSS nebo jak se tomu).
Skrz generickou paketizaci nemusí projít nastojato některé protokoly, které nad fyzickou sériovou linkou dbají na striktní časování. Třeba Modbus/RTU má prohlásit "konec rámce" po ekvivalentu 3.5 znaku od posledního přijatého znaku. Takovéhle protokoly mívají bratříčka, který s TCP enkapsulací nativně počítá - a potřebujete "o něco chytřejší" gateway, která mezi oběma enkapsulacemi bude provádět relay v souladu s normou pro daný protokol. Třeba Modbus/RTU vs. Modbus/TCP, IEC-101 vs. IEC-104 apod.
Inteligentní relay konkrétních fieldbusů tradiční terminálové servery neuměly - ale už dávno existují varianty firmwaru, které takové věci umí buď jako svou pevnou náplň práce, nebo jako konfiguračně volitelnou vlastnost...
Pokud potřebujete od "terminálového serveru" obecně "něco svého", řešíte spíš možnost, dopsat si do takové krabičky svůj vlastní software. Tzn. ke krabičce přistupujete spíš jako k obecnému počítači, ve kterém uvítáte otevřený Linux (nebo tak něco) do kterého si dopíšete co je potřeba. Někteří výrobci tomuto využití jdou naproti (tradičně Lantronix, zřejmě taky ATOP a u některých modelů Advantech), u ostatních nevím.
Případně, pokud Vaše koncové zařízení na sériové lince má nějaký opravdu primitivní protokol, možná byste sehnal "průmyslovou krabičku se sériovým portem", která by to dokázala nějak pozřít a podat dál skrz jednoduché HTTP GUI nebo třeba MQTT apod. Třeba váha pošle řetězec zakončený konkrétním znakem, buď v pravidelném časovém intervalu, nebo v reakci na událost, nebo v opravdu krajním případě na nějakou výzvu po sériové lince... Jako že by to šlo naklikat bez programátorské práce.
Terminálové servery velké jako krabičku sirek či cigaret dělá v dnešní době spousta výrobců. Lantronix je zřejmě pradědeček, tuzemského Papoucha už tu taky někdo zmínil, osobně znám pár dalších značek (Advantech, ATOP, Moxa, Korenix, Westermo) ... prakticky kdokoli v Číně kdo má nos mezi očima to vyrábí v garáži (a jeho babička). Samozřejmě je možné to postavit zcela po svém na dnešních otevřených platformách typu RPi nebo ESP32.
Není pravda, že "většina sériových donglů na USB má RS232 výstup na elektrických úrovních TTL". Pokud Vám to tak připadá, doporučuji Vám udělat si podrobnější průzkum trhu a pořádek ve zbožíznalství :-)
Sériový port se skládá obecně ze dvou čipů: UART (= posuvný registr) a "level shifter" = analogový opakovač, budič linky. Ideové blokové schéma s polaritami signálů najdete třeba tady (disclaimer: samožer).
UART je součástka společná pro RS232/422/485. UART s level shifterem se baví na elektrických úrovních TTL. Teprve level shifter vyrábí kýžené napěťové úrovně pro RS232 nebo 422/485 (nebo třeba M-bus, ten má taky zcela svoji fyzickou vrstvu). Kolmá poznámka: budu dále abstrahovat od detailu, že pro half-duplexní varianty sériové linky (RS485 a snad i M-bus) je vhodné mít z UARTu vyvedený signál TSRE aka TEMT, což třeba klasický TI 16C550A UART nemá.
Konkrétně RS232 má platné logické úrovně 3 až 15 Voltů od společné referenční země, bipolárně plus a mínus. Samotná zem (nula voltů) je zakázaný stav, zavřený ve Schmittově hysterzi. Existuje mnoho level shifterů, které si "divné" napěťové hladiny pro RS232 vyrábí z jediné vstupní napájecí větve (3.3V nebo 5V) on-chip RC nábojovou pumpou, a na výstupech pak vidíte třeba něco jako +/-6 nebo +/- 10 V. Nebo třeba jenom +/- 5V u některých USB donglů. Ale nenechte se zmást, těch "asi 5 Voltů" bývá bipolárně kolem nuly. Taky si všimněte, že polarita logických úrovní je na RS232 lince opačná (invertovaná), oproti interní TTL komunikaci mezi UARTem a level shifterem. Pokud tedy narazíte na dongle, který produkuje TTL (cca 5V / 0V), tzn. nedává zápornou úroveň, a přitom používá "polaritu jako RS232", tak se jedná o paskvil / zmetek / čínskou inovaci - osobně takových mnoho nevídám.
Ano, jsou k nalezení levné USB/serial dongly s výstupními úrovněmi TTL - protože postrádají level shifter. Třeba známá firma FTDI takové varianty nabízí, vedle bratříčků s level shifterem pro RS232 nebo RS485. Dongle bez level shifteru je v tomto případě řádně označen. Bavíte se v tomto případě navenek přímo s UARTem.
K čemu to?
Mnoho malých krabiček (levné routery) mají vyvedenu sériovou konzolu právě na úrovních TTL rovnou z UARTu. Proč: protože použitý SoC/CPU/MCU obsahuje UART nebo dva on chip, a servisní konzola je typickým účelem takové sériové linky. Ovšem ta linka zůstává za normálních okolností schovaná pod kapotou, a použije ji jenom znalý servisák, pokud za vzácných okolností není zbytí - možná ji použije fabrika pro upload firmwaru (pokud toto nemají ošetřeno jinak, třeba přes JTAG nebo SPI). Jedná se o využití na kratičkou vzdálenost, v kontrolovaných laboratorních podmínkách. Poškození "divočejším počasím" nebo nešikovností uživatele až tolik nehrozí. Pro tyto potřeby je škoda utratit dolar nebo dva navíc za level shifter.
USB/serial dongly jsou založeny na čipech několika populárních výrobců: FTDI, Prolific, Silicon Labs, WinChipHead, Moschip, teoreticky taky Exar něco má, možná někdo další by se našel...
USB/serial nemá svou vlastní třídu USB zařízení. Asi nejblíž je CDC-ACM, což je ale třída specificky pro USB modemy. Možná proto výrobci USB/UART čipů CDC-ACM obecně ignorují a používají každý své rozhraní na USB. Proto taky do Windows potřebujete pro USB/serial dongly vždy specifický driver od výrobce UART čipu - protože Windows neobsahují class-based driver, protože neexistuje jednotná třída rozhraní.
Kupodivu Linux obsahuje ovladač usbserial.ko. Tento ovladač sdružuje HW-specifické open-source drivery pro větší počet výrobců čipů :-) Je možné, že tam je nějaká synergie (sdílení kódu) v transportu dat mezi TTY subsystémem a USB endpointem... navenek se to chová úplně jako class-based ovladač :-) Prostě v Linuxu drivery pro USB/serial dongly naprosto neřešíte. Píchnete do počítače anonymní dongle co jste našli válet zaprášený v racku, a ejhle, kernel našel /dev/ttyUSB0, minicom funguje...
No a pokud se týče Androidu: ten má přece uvnitř linuxový kernel, žeano. Takže by snad měl automaticky obsahovat ovladače pro USB UARTy výše zmíněných "obvyklých podezřelých" výrobců...
Omyl vážení! Pardon - tahle zkušenost je už třeba 5 let stará, doufám že nekecám. Osobně do mobilních OS nefušuju - ale bavil jsem se chvíli s hobbíkem, který si pro Android programoval nějakou odposlechovou appku se sériovou komunikací. Android rozhodně vanilkový usbserial driver v kernelu neobsahoval. Naopak existovala/existuje na githubu open-source knihovna pro Javu, která s využitím tuším libusb obsluhuje USB UARTy několika značek. Původně třeba dvou, ale na Githubu projekt dosáhl už v té době několika forků, z nichž ty poslední podporovaly už asi 5 výrobců. Momentálně mi Google ukázal zřejmě "mateční rostlinu", které se evidentně dobře daří a má na okraji repa zmíněno 1600 forků...
= potřebujete v Javě na
