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.
Založen: Jan 01, 2023 Příspěvky: 2801 Bydliště: Česká Lípa
Zaslal: po prosinec 08 2025, 18:17 Předmět:
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.
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.
Založen: Jan 01, 2023 Příspěvky: 2801 Bydliště: Česká Lípa
Zaslal: po prosinec 08 2025, 18:53 Předmět:
lesana87 napsal(a):
A to se dá, nabourat se mezi aplikaci a WinAPI?
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.
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.
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.
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.
Vždycky první kontrolovat HW - konektory, otočné přepínače (+ použití WD-40), kabely, stínění, zdroje atd. Procesor autor původního řešení locknul, nebo zůstal odemčený?
Časy uváděny v GMT + 1 hodina Jdi na stránku Předchozí1, 2
Strana 2 z 2
Nemůžete odesílat nové téma do tohoto fóra. Nemůžete odpovídat na témata v tomto fóru. Nemůžete upravovat své příspěvky v tomto fóru. Nemůžete mazat své příspěvky v tomto fóru. Nemůžete hlasovat v tomto fóru. Nemůžete připojovat soubory k příspěvkům Můžete stahovat a prohlížet přiložené soubory
Informace na portálu Elektro bastlírny jsou prezentovány za účelem vzdělání čtenářů a rozšíření zájmu o elektroniku. Autoři článků na serveru neberou žádnou zodpovědnost za škody vzniklé těmito zapojeními. Rovněž neberou žádnou odpovědnost za případnou újmu na zdraví vzniklou úrazem elektrickým proudem. Autoři a správci těchto stránek nepřejímají záruku za správnost zveřejněných materiálů. Předkládané informace a zapojení jsou zveřejněny bez ohledu na případné patenty třetích osob. Nároky na odškodnění na základě změn, chyb nebo vynechání jsou zásadně vyloučeny. Všechny registrované nebo jiné obchodní známky zde použité jsou majetkem jejich vlastníků. Uvedením nejsou zpochybněna z toho vyplývající vlastnická práva. Použití konstrukcí v rozporu se zákonem je přísně zakázáno. Vzhledem k tomu, že původ předkládaných materiálů nelze žádným způsobem dohledat, nelze je použít pro komerční účely! Tento nekomerční server nemá z uvedených zapojení či konstrukcí žádný zisk. Nezodpovídáme za pravost předkládaných materiálů třetími osobami a jejich původ. V případě, že zjistíte porušení autorského práva či jiné nesrovnalosti, kontaktujte administrátory na diskuzním fóru EB.
FAQ
Hledat
Uživatelské skupiny
Profil
Soukromé zprávy
Přihlášení
