882
« kdy: 15. 06. 2019, 13:58:11 »
I já děkuji za odpovědi...
Virtuální COM port je jenom potěmkinova vesnice, která předává jednotlivé bajty nebo řekněme dávky znaků o nějaké délce tam a zpátky. Samotný ten virtuální device nemá nějaký svůj nativní baud rate. Prostě pošlete write() nebo něco na ten způsob, virtuální COM port jenom zkopíruje data kam má (rychlostí jakou RAMka a sytémové sběrnice dovolí) a okamžitě se vrátí. Nějaký baud rate a třeba taky FIFO (které může přetéct) jsou vlastností fyzického UARTu, což je vlastně posuvný registr s konkrétními bitwise hodinami. Pokud virtuální COM dostane ioctl() k nastavení baudu apod., tak ho zcela jistě odkejve, ale otázka je, co s tím pokynem dál udělá - možná jenom pokrčí rameny. Mám pocit, že se takhle chovají třeba některé USB modemy, kde na hostiteli vidíte virtuální COM port, a v koncovém zařízení to končí zas jenom nějakým bufferem v RAM pro přebírání dat z USB endpointu. Windowsy nejsou schopny dostatečně jemného časování, aby zvládly softwarově časovat emulaci jednotlivých bitů nebo byť třeba i znaků (a pokud by ta možnost byla, tzn. hnát tu emulaci interruptem od nějakého časovače, bylo by to dost neefektivní.) Některé "transportní vrstvy", které končí z jedné strany fyzickým UARTem a z druhé strany virtuálním sériákem, umí "prosignalizovat" i ioctl() od virtuálního COMu pro nastavení baudu a formátu znaku - viz např. RFC2217 Telnet options, a většina proprietárních transportů "serial over TCP". Ono to možná nějak jde protáhnout i skrz com0com + hub4com, ale už si nepamatuju jistě.
Tlačiareň je v pohode, bere znaky jednotlivě tak jak přijdou, blok dat uzavírá newline případně form feed (nebo nějaký jiný způsob, jak říct "tato stránka je kompletní"). Tiskové jazyky nemívají timeout na "ticho na lince". V "průmyslu" se vyskytují na sériových linkách protokoly, které spoléhají na fyzický UART a mohou být citlivé na transportní latence, pauzy mezi znaky apod. (klasicky frame break timeout v Modbus/RTU) - ale to by nejspíš nevysvětlovalo Vámi pozorované chování.
Pod Windowsama trochu znám COM porty na úrovni Win32 API. Jednou jsem koukal někomu přes rameno, jak se pracuje s COM portama v C#.NET (pomocí objektů co Microsoft standardně přibaluje) a dost jsem žasl, jak to relativně čisté API známé z úrovně Win32 dokázali nalámat na menší kousky a zašmodrchat.
Možná ještě jako jeden další test bych navrhoval, sáhnout si nějakým terminálem na serveru na protunelovaný COM port :-)
Historicky si pamatuji situaci, kdy staré drivery pro sériový hardware pro Win2k nechodily pod XP, nebo se to rozbilo někde mezi dvěma service packy... zhruba v tom smyslu, že u víceportových RS232 karet chodil jenom první port, vyšší už ne, zařízení se tuším dalo otevřít ale při prvním pokusu o zápis nebo čtení zatuhlo navždycky apod. Taky to tehdy nějak souviselo s "enumerací" portů - ono to že se v device manageru objeví seznam ikonek pro jednotlivé porty, to je zřejmě třešnička na dortu, je to možná jenom "grafická nadstavba" či "další patro" nad interním seznamem zařízení v NT kernelu - prostě seznamy zařízení na několika úrovních abstrakce, musí na sebe nějak navazovat, a API pro jejich vzájemnou synchronizaci se mezi verzemi maličko změnilo, takže za určitých okolností se ty hračky rozsypaly...
Pokud je aktuální driver z webu Silicon Motion už reálně testovaný jenom v desítkách, tak je možné, že kompatibilita s Win7 už uplavala (klidně v nějakém obskurním detailu). A je šance, že starý ovladač z dob, kdy o desítkách nebylo vidu ani slechu, možná problém vyřeší. Podobné problémy s nesprávnými informacemi o kompatibilitě ovladačů vs. verze Windows (tehdy snad XP/7) jsem zažil před pár lety u FTDI... a taky tehdy mi pomohlo, schrastit starší driver.
(BTW upozorňuji na soukromou zprávu - doufám, že došla.)
Zobrazit příspěvky
