Diskuzní fórum Elektro Bastlírny

Nemáte někdo tip na SW na PC, který by sledoval okamžité vytížení sériové linky a kreslil podobný graf jako je třeba ve windows na vytížení sítě nebo wifi?
Jde o to, monitorovat přenost mezi dvěma systémy jestli se občas nezahltí vysílací buffer.

To si moc nedovedu představit. Co analyzovat přijatá data na chyby, to by nestačilo? Co je vlastně zdrojem dat? Programátor by měl vědět, kolik dat potřebuje odvysílat a měl by i mít přístup k informaci o naplnění či přetečení bufferu.

Je to komunikace mezi dvěma přístoji. Lidsky nečitelný formát. A ani na jedné straně samozřejmě není k dispozici zdrojový kód. Na vysílací straně je možné různě uživatelsky konfigurovat funkce na jejichž nastavení závisí četnost a obsah vysílaných dat. Problém je, že se problém objevuje málo často a náhodně.
V normálním odposlechu komunikace ve změti znaků není vidět nic podezřelého.

Je to LAN spojenie? V tom pripade by som sa porel po nejakom svici, ktory to vie. Mozno aj nejaky Mikrotik by to mohol zvladnut.

Je to úplně klasický sériák.
Kdyby to byl ethernet, tak bych to už měl vyřešené pomocí wiresharku a neptal bych se tak blbě

Zkusil bych použít nějaký převodník RS232 <-> TCP, nebo ještě lépe desku s Linuxem a přesměrovat to na UDP do PC s Wiresharkem. Když zvolíš vhodný formát tak ti s dekódováním může Wireshark pomoci. Teda v případě že zná protokol na té sériovce, ale zná jich hodně.

Kolegové v bývalé práci to kdysi řešili tímhle.

Edit: Přečetl jsem si vlákno pořádně, a došlo mi, že to asi už znáš.

Terminal 1.9b by Br@y„ Termite.

Pod Win môže mať jeden konkrétny sériový port otvorená iba jedna aplikácia, to znamená že ak už máš rozbehanú jednu klientsku aplikáciu na RS232 prenos, druhou (diagnostickou) už ten port neotvoríš.
Možno by to šlo kompenzovať rôznymi softwarovými "loopback" adaptérmi, prípadne je nejaké riešenie vo svete *nix, ale bez použitia (dostatočne rýchleho) logického analyzátora na UART sa asi nevyhneš.

Ten terminal by Br@dy se blíží tomu, co bych potřeboval.
Pak jsem našel ještě něco podobného jako Extension pro Saleae a asi to půjde upravit.

HF_Tech píše:Jde o to, monitorovat přenost mezi dvěma systémy jestli se občas nezahltí vysílací buffer.

Pokud je jednou z komunikujících stran cizí aplikace ve Windows pak můžete zdarma vyzkoušet Free Serial Analyzer. Měl by fungovat ve Windows od verze Vista až po 11. Tato aplikace instaluje ovladač filtru nad ovladač sériového portu. Díky tomu poté zachycuje aktivity na sériovém portu otevřeném jinou aplikací. Tato aplikace grafy nekreslí, ale podle záznamů by mělo být možné zjistit zda dochází k přeplňování vysílacího bafru například prostřednictvím sledování požadavků typu IOCTL_SERIAL_GET_COMMSTATUS kde by měla být v datové struktuře SERIALPERF_STATS viditelná aktuální hodnota položky čítače BufferOverrunErrorCount, ve které je počet chyb přeplnění vyrovnávací paměti zjištěných od otevření sériového portu nebo od zpracování posledního požadavku IOCTL_SERIAL_CLEAR_STATS .

Jak se dá přeplnit vysílací buffer? Neplete si někdo vysílací buffer s přijímacím?

Už jsem se s tím setkal. Knihovna pro sériovou linku byla špatně udělaná a netestovala správně, jak zápis dopadl. Když se zaplnil vysílací buffer, tak se vše další zahodilo.

Nejako neviem si predstaviť ako to pomôže vyriešiť/odstrániť problém.

Okej postavíš si RS232 sniffer a nejakú vizualizáciu k tomu dajme tomu v pythone za jeden večer by sa dalo vyviesť všetky signály z RS232 do grafu a logovať to (ja by som šiel touto cestou pretože pochybujem že sa nájde presne na mieru sw), a zistíš niečo... , napr. že ten prijímač naozaj nestíha spracovať dáta čo s tým ďalej keď zdrojaky nie su k dispozícii, čo si posiela tiež tomu nerozumieme, a su k dispozícii ako som pochopil len nejaké konfigurácie.

S tým istým úspechom je možne meniť konfigurácie komunikácie a sledovať či sa problém ešte vyskytne alebo nie.

Ak je to pod windowsom ešte by som skúsil nastaviť najvyššiu prioritu pre danú aplikáciu ktorá obsluhuje rs232, a tak tiež pozrieť do PortSettings-> Advanced či su zapnute windows buffre alebo ci sa nedajú navýšiť.

Z vlastnej skúsenosti pre staršie Windows ako 98/2000 niekedy pomohlo pravé nastavenie nízkej priority, ale neanalyzoval som to prečo.

Držím palce snáď sa to podarí odstrániť ...

Závisí to na aplikaci případně knihovně, kterou aplikace používá pro sériovou komunikaci a na tom jak dobře nebo špatně je napsaná. Pokud aplikace/knihovna nesprávně kontroluje prováděné zápisy, může se stát, že část dat předaných k odvysílání bude zahozena a aplikace pak neobdrží očekávanou odpověď od protistrany.

Sledováním toho zda dochází k přeplnění vysílacího bafru se samozřejmě problém obecně nevyřeší pokud nelze aplikaci upravit programově. HF_Tech zřejmě doufá, že pomocí toho zjistí při jaké konfiguraci na vysílací straně kde jak již napsal je možné různě uživatelsky konfigurovat funkce na jejichž nastavení závisí četnost a obsah vysílaných dat, zjistí jaká konfigurace to způsobuje a pak se tomu bude pokoušet vyhnout jiným nastavením konfigurace na vysílací straně, ale dle mého názoru to může být v závislosti na množství nastavitelných parametrů velmi zdlouhavá práce s nejistým výsledkem, zejména pokud k tomu dochází jen zřídka. Nicméně je to v podstatě jediná možnost jak se pokusit to nějak ovlivnit když nemá možnost upravit přímo tu komunikační aplikaci.

Pokud by připadalo v úvahu k těm přístrojům najít nebo vytvořit jinou komunikační aplikaci bylo by to samozřejmě lepší řešení, ale taková varianta zřejmě nepřichází v úvahu, protože ta komunikační aplikace je zřejmě vázaná na konkrétní specifické zařízení, ke kterému zřejmě ani není k dispozici popis specifického komunikačního protokolu.

Pokud je to možné a ještě nebyl učiněn pokus oslovit výrobce toho zařízení tak bych navrhoval to zkusit a zeptat se zda by nemohl výrobce poskytnout popis komunikačního protokolu, podle kterého by se pak dala napsat vlastní aplikace a pokud ne tak se zkusit zeptat výrobce zda by nemohl alespoň poradit jak konkrétně tomu problému s komunikací případnou změnou konfigurace té problémové aplikace předcházet.