Ale stavy těch bufferů přece z komunikace na lince nijak nepoznáš. Maximálně toho přijímacího pokud je použité řízení toku dat (hw nebo sw), tak z něj, že se začne aktivovat.
BufferOverrunError se týká přetečení bufferu na straně příjmu, kdy sw nestíhá odebírat přijímaná data. Dumitru také píše o přetečení bufferu na straně příjmu.
SW pro monitoring vytížení sériové linky
Moderátor: Moderátoři
Pokud ta problémová aplikace volá Win API funkci ClearCommError tak by se to dalo vysledovat z hodnoty položky cbOutQue ve struktuře COMSTAT, která by měla obsahovat počet bajtů, které jsou ve vysílacím bafru a ještě nebyly odeslány.
Mnou již zmíněná aplikace Free Serial Analyzer by to dle jejího popisu podporovaných požadavků měla umožňovat monitorovat na úrovni filtru nad ovladačem sériového portu přes IOCTL_SERIAL_GET_COMMSTATUS kde by ta hodnota měla být v položce AmountInOutQueue struktury SERIAL_STATUS.
Mnou již zmíněná aplikace Free Serial Analyzer by to dle jejího popisu podporovaných požadavků měla umožňovat monitorovat na úrovni filtru nad ovladačem sériového portu přes IOCTL_SERIAL_GET_COMMSTATUS kde by ta hodnota měla být v položce AmountInOutQueue struktury SERIAL_STATUS.
Nějak to jde. Já takhle používám IPXWrapper (našel jsem ho teď tady: https://github.com/solemnwarning/ipxwrapper) s hrou Atomic Bomberman. Obaluje to IPX pakety pomocí UDP. Ale jak je to udělané, to netuším.
Zmíněný Free Serial Analyzer instaluje vlastní ovladač filtru nad ovladač sériového portu tj. v podstatě ze začlení mezi Win API, které je na aplikační úrovni a ovladač sériového portu, který je na úrovni jádra Windows. Díky tomu poté zachycuje aktivity Win API volání na sériovém portu otevřeném jinou aplikací, která jsou realizována na úrovni ovladače sériového portu.lesana87 píše:A to se dá, nabourat se mezi aplikaci a WinAPI?
Baví se mezi sebou dva procesory v různých krabicích. Jeden z nich je ATMEGA. Je to speciální tester, který vzniknul jako hurá akce před cca 15 až 25lety a celkem fungoval. Bohužel nedošlo k předání/archovování ani zdrojového kódu ani popisu komunikace. Původní autor o kopii také přišel.Valdano píše: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.
Na jedné krabici se mění různě uživatelské nastavení - dlouhá léta na to nikdo nesahal a vše fungovalo. Nyní při určité konfiguraci nastavení dojde občas k výpadku. Po vyloučení možného, zbývá právě možnost, že při určitém nastavení dojde k neošetřenému přetečení TX bufferu a následně to rozhodí stavový automat na straně přijmu. Druhá možnost je, že je někde blbě nadefinovaná nějaká proměnná - s tím nic nevymyslíme.
V běhu je výroba nového zařízení, ale to je zábava ještě tak na půl roku.