Diskuzní fórum Elektro Bastlírny

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?

Potvrdzuje sa kazdy bajt.

Zkusil bych propojit STB a ACK. Může být potřeba ještě ošetřit BUSY a PAPER ERROR.

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 ...?

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.

EKKAR píše: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.

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?

V SPP mode sa vsetko robi cez SW. V EPP a ECP modoch to riesi HW.

Osmdesat píše:Otázka je, jak přísná je ta kontrola - tedy jestli tomu stačí jen ACK? Nebo tam potřebuje mít i to BUSY?

BUSY je nepovinný, dej ho na 0.

tomasjedno píše:

EKKAR píše: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?

A nestačilo by v príkazovom riadku napísať "type LPT1 > nul" ?

Ten prikaz by mal robit akoze co?

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.

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.

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.