Založen: Jan 19, 2016 Příspěvky: 1515 Bydliště: Liberecko
Zaslal: pá březen 12 2021, 23:34 Předmět: Emulace připojené tiskárny na LPT port
Potřeboval bych docílit odeslání dat na LPT port, i když na něj není nic připojeného. Když zadám ve windows zápis do souboru "lpt1", zápis se zasekne, pokud tam není zařízení, které to "odhendšejkuje".
Zkoušel jsem nahodit vstup SELECT, shodit ACK, ale nejde to. Nevíte, jakým zapojením to jednoduše ošulit?
Založen: Mar 16, 2005 Příspěvky: 31800 Bydliště: Česká Třebová, JN89FW21
Zaslal: so březen 13 2021, 0:22 Předmět:
Nešlo by tohle ošetřit nějakým hádrujýnem ? Prostě procesůrek napájenej z portu, kterej by na podnět z datový linky odeslal příslušnej handshake ...? _________________ Nasliněný prst na svorkovnici domovního rozvaděče: Jó, paninko, máte tam ty Voltíky všecky...
Založen: Mar 21, 2006 Příspěvky: 33860 Bydliště: Bratislava
Zaslal: so březen 13 2021, 0:29 Předmět:
Na paralelnom porte nie je ziadne napajanie.
Nieco s minimalnou spotrebou by sa dalo napajat cez diody z riadiacich signalov. Napajaju sa tak automaticke prepinace 2 PC -> 1 tlaciaren. Tie maju vsak vyhodu, ze mozu zrat z PC aj tlaciarne sucasne.
Založen: Jan 19, 2016 Příspěvky: 1515 Bydliště: Liberecko
Zaslal: so březen 13 2021, 9:13 Předmět:
Nevíte, jestli si ten handshake softwarově hlídá windowsový ovladač portu, nebo se hlídání handshaku děje na úrovni HW?
Otázka je, jak přísná je ta kontrola - tedy jestli tomu stačí jen ACK? Nebo tam potřebuje mít i to BUSY?
Mohl bych na výstup STROBE zapojit tranzistorový invertor, který by vyrobil signál pro BUSY, a signál pro ACK bych vyvedl přímo ze STROBE. Ale odehrálo by se to všechno současně a nevím, jestli by to sežral. Třeba tam chce vidět posloupnost - strobe, po něm busy a nakonec ACK. Pak bych tam musel zavést zpoždění. RC členem by se daly ty signály možná trochu prodloužit.
Vím, že existují možnosti to obejít, mám otestovanou knihovnu inpout32.dll pro přímý zápis na V/V porty, s tou to chodí dobře, ale pak to musíš tok dat řídit softwarově - bitbangingem, což zatěžuje CPU, je to pomalé (user mode driver), není to časově přesné a proč to dělat, když to jde nativně úrovni řadiče/ovladače?
Založen: Mar 16, 2005 Příspěvky: 31800 Bydliště: Česká Třebová, JN89FW21
Zaslal: so březen 13 2021, 11:25 Předmět:
tomasjedno napsal(a):
EKKAR napsal(a):
Nešlo by tohle ošetřit nějakým hádrujýnem ? Prostě procesůrek napájenej z portu, kterej by na podnět z datový linky odeslal příslušnej handshake ...?
Jistě by se to dalo vymyslet ještě složitějc.
Pro mě je to všecko "hádrujýno" - prostě myslel jsem nějakej programovatelnej šváb s minimální spotřebou, kterej by se dal napájet buď přímo z portu, nebo usměrněnýho signálu nějaký linky => aby nebyl potřeba žádnej další napájecí zdroj a kterej by učunil tu funkci odezvy na portu. Pokud to zvládneš líp, třeba jedním odporem a půlkou tranzistoru, navrhni to. Já neznám průběhy na tiskovým portu, ale napadlo mě, že nějakej programovatelnej bázmek by to zvládat musel. Některým lidem stačí napovědět směr, dál už pak věc řeší sami. Chtěl jsem jen popostrčit, ne navrhovat jedno určitý a pravděpodobně i moc složitý řešení. Když ale v dnešní době lidi řeší i blbej blikač namísto dvou trandů, pár odporů, kondíku a LEDky jedním programovatelným švábem a tvrdí, že to je levnější řešení, proč nepoužít podobnou cestu i na ten LPT port? _________________ Nasliněný prst na svorkovnici domovního rozvaděče: Jó, paninko, máte tam ty Voltíky všecky...
Založen: Jan 19, 2016 Příspěvky: 1515 Bydliště: Liberecko
Zaslal: so březen 13 2021, 11:53 Předmět:
Já tam ty data budu skutečně potřebovat. Ale na něco jiného, než na tisk. Jen potřebuju, aby si systém myslel, že jsou data přijímána tiskárnou, a v klidu je poslal.
Založen: Jan 19, 2016 Příspěvky: 1515 Bydliště: Liberecko
Zaslal: so březen 13 2021, 14:00 Předmět:
Už mi to funguje - pro funkčnost přes Windows API je nutno uzemnit BUSY a PAPER OUT. Když jsem uzemnil ještě ERROR, už to nefungovalo. S ACK nebylo nutné nic dělat.
Založen: Jan 19, 2016 Příspěvky: 1515 Bydliště: Liberecko
Zaslal: so březen 13 2021, 14:16 Předmět:
Jinak měřil jsem trvání těch přes Windows API volně posílaných bajtů a zjistil, že na ntb s Pentiem 4 a windows XP trvá bajt asi 12 µs.
U čtyřjádrového Xeonu s Windows 7 trvá bajt 30 µs, a trvání dost kolísá. Nechápu, když je to rychlejší počítač. Podezírám, že za to může Windows 7.
Časy uváděny v GMT + 1 hodina Jdi na stránku 1, 2, 3Další
Strana 1 z 3
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í
