Vlákno názorů k článku Stavíme ochranu paralelního portu od killer - Proč píšeš o prehistorickém paralerním portu když dnes většina věcí...

Na první pohled máte pravdu, ale:
a) Krokáče už nejsou to, co se učí ve škole – jsou to 3-fázové motory s mikrokrokováním. Tím dosáhnete třeba 20k kroků na otáčku, ale potřebujete na to 3× 16-bitové PWM, tabulku SIN a to vše musí stíhat při rychlosti do 200K kroků za sec (při rychloposuvu). K tomu zpětná proudová vazba a korekce PWM podle skutečného proudu (jinak tam máte úhlovou chybu kroku). Osmibit na to nestačí. Nějaký low-level kód nikde neseženete – to si každý sakra hlídá, jsou to léta dřiny. 2 roky práce na to taky stačit nebudou. A proč taky? Koupíte nějaký hotový výkonový stupeň. Ani není moc drahý. Nastavíte do toho jmenovitý proud krokáče, počet mikrokroků a hotovo – už jen „sypete“ kroky a směr… Takže jeden procesor/krokáč tam je. A ne ledajaký – je tam nějaký DSP od TI.
b) Takže stačí už jen ten interpolátor. Opět připomínám, že z něj kroky musí „padat“ rychlostí až 200 kHz, což při běžných rychlostech osmibitů (20 Mhz) je 100 taktů/krok – myslíte si, že toho fouriera stihnete osmibitem? Navíc všechny osy musí být na krok přesně synchronyzovány. To přes USB nedosáhnete, kdybyste se rozkrájel… Takže všechny osy (v mém případě až 8) musí počítat jeden procesor (dost výkonný). Ty stroje děláme už 15 let – tehdy žádné levné výkonné 32-bitové procesory nebyly. Tedy byly – jmenovaly se Pentium I. A na nich to děláme dodnes. A jediný „rozumný“ port PCčka s kterým si můžete dělat, co chcete (nesvázán nějakým protokolem), je parport…

I když koupíte FTDI za polovinu ceny, pořád je v TQFP. To na univerzální propojovací pole nestrčíte. Ani k vývodům nepřipájíte drátky (tedy jeden, dva drátky bych svedl, ale cca 15 a začátečníci?). Takže koupit ještě nějakou redukci. A až to uvidí začátečník, tak od toho uteče… Takže raději koupit hotovou redukci USB/LPT. No a můžeme se k tomu hardwarově zase chovat jako k parportu. Opravdu je tam ten mezistupeň USB nutný? Aby to lépe fungovalo? Nebo jen proto, aby to bylo „moderní“?

Už to někdo nahoře zmiňoval. Na pokusy není potřeba myslet na TQFP http://www.asix.cz/…ums2_big.jpg

Vy jste z Asixu? Proč kupovat modul v Asixu za 643 Kč (s daní) k tomu ješte USB kabel za cca 50 Kč, když si můžu koupit hotovou celou redukci za 246 Kč i s daní: http://www.czechcomputer.cz/product.jsp?…

A proc bych mel byt z Asixu? Kdyz si chci hrat s FTDI obvodem a treba zkusit Bit Banging, tak je ten modul smysluplnejsi nez prevodnik USB na LPT. A modul proto, abych nemusel pajet titerny obvod ;-)

A jak casto se do toho zarizeni ta data posilaji? Uvedomujete si, ze na PC (pokud nemate kontrolovanou hardwarovou platformu) se vam klidne muze stat, ze SMM zablokuje operacni system treba na 1 ms? Proto kontrolovat cokoliv, co vyzaduje presne casovani, pres paralelni port z PC je nespolehlivy hack.

Mimochodem, oznacovat paralelni port jako rozumny je velmi odvazne. To, ze je vhodny k hardwarovemu hackovani (a da se pouzit jako GPIO piny) je dusledkem toho, ze je naprosto nevhodne navrzen pro svuj hlavni ucel – pripojeni tiskarny (ci jinych zarizeni, ktere ocekavaji, ze port do PC se bude chovat jako bytovy stream).

SMM „kecá“ do všeho. Takže na PC neexistuje ani žádný jiný port, krerý lze k přesnému časování použít. Ale SMM lze „vypnout“ a pak je parport k řízení dobrý. Psal jsem že krokujeme rychlostí 200 kHz – tedy za milisekundu se udělá 200 kroků. Kdybych SMM neeliminoval, ani by se krokáč nerozběhl – při prvním „zadrhnutí“ se zasekne a už se neroztočí.
Ano byla to před lety pěkná rána pod pás, když se některé boardy z nepochopitelných důvodů nedaly pro řízení použít. Ale pak jsme zjistili, že ty „nepoužitelné“ boardy jsou na platformě Intel a SIS „nedělá problémy“. Tak jsme to stavěli na SISkách. Když po letech i SISky začaly dělat problémy, už se na internetu daly sehnat informace, proč se tak děje a jak to obejít…

Mimochodem, proč si myslíš, že parport „je naprosto nevhodne navrzen pro svuj hlavni ucel – pripojeni tiskarny (ci jinych zarizeni, ktere ocekavaji, ze port do PC se bude chovat jako bytovy stream)“? Ty stovky milionů paralelních tiskáren, které v naprosté pohodě převádějí bytestream z parportu na papír, snad svědčí, že funguje dobře.
Ostatně podívej se na schéma zapojení klasického SPP portu, tak jak se používal v XT a AT písíčkách: Jsou to 3 registry (0×378, 0×379 a 0×37A), adresový dekódér a pár hradel logiky – suma sumárum asi 6 TTL brouků. Ten hardware nic neumí. Musíš to SW obsloužit. A když to dobře obsloužíš, tak to funguje naprosto správně a naprosto pohodově. No a na obsluhu stačilo „50 assemblerských instrukcí včetně inicializace“. Ostatně ECP rozšíření parportu funguje, tak jak si představuješ: „nasypeš“ do toho adresu paměti a kolik toho přenést a logika ECP sama odešle požadovaný blok do připojeného zařízení. Jenže tady pramení kořeny mýtu o nespolehlivosti parportu: některé staré jehličkové tiskárny nedovedly na ECP řízení dostatečně rychle reagovat a nepodařilo se jim spolehlivě zachytávat každý byte. Stačilo ale nový počítač přepnout do režimu SPP a tiskárna zase spolehlivě tiskla… Ale to jste vy mladí: Proč používat něco „zastaralého“ (SPP), když tu máme možnost „moderního“ (ECP)? Zrovna tak by se tam dalo použít LPT x USB. No přeci proto, že i to nemoderní funguje (a ve většině případů i s menšími náklady na HW i SW, než to „moderní“, které je komplikované až převyumělkované)…

Mimochodem, proč si myslíš, že parport „je naprosto nevhodne navrzen pro svuj hlavni ucel – pripojeni tiskarny (ci jinych zarizeni, ktere ocekavaji, ze port do PC se bude chovat jako bytovy stream)“?

…

Ale to jste vy mladí: Proč používat něco „zastaralého“ (SPP), když tu máme možnost „moderního“ (ECP)?

Navrh SPP je poplatny sve dobe a snaha usetrit na hardwaru co se da je na nem videt. Jenze uz desitky let tu mame multitaskove operacni systemy a tak chceme, aby hardware nebylo treba obsluhovat kazdych par us. I kdyz to je jenom par instrukci, tak to, ze je treba kvuli tomu vyvolat interrupt (at uz toho portu nebo casovace), prerusit zpracovany proces, obslouzit to a vratit se zpatky, To samo o sobe znacne zatizi system. A to ani nemluvim, ze obcas mezi nekterymi operacemi je treba vlozit delay, ktery je ale prilis kratky na to, aby se mezi tim vubec predalo rizeni nejakemu procesu.

Kazdy normalni port ma v pameti dostatecne velky buffer, sam si ridi flow control, a generuje interrupty jen kdyz se buffer dost vyprazdnil. Hardware, ktery alespon tohle neumi, je beznadejne zastaraly (a byl zastaraly uz pred 15 lety).

Staci se podivat na rozdil v zatezi u systemu vysilajiciho sitovou kartou na 100 Mbps a paralelnim portem v SPP na stezi 500 kbps. Stejne tak ECP vs SPP – rozdil v zatezi systemu znacny. Tisk pres onen prevodnik USB-LPT take asi bude asi vyrazne mene zatezovat system (pokud ten prevodnik neni vylozene blbe udelany) nez tisk pres LPT v SPP. ECP uz celkem jde (narozdil od EPP, ten byl take celkem obskurni reseni) i kdyz ‚klasicke‘ DMA kanaly uz jsou take dnes beznadejne zastarale (napriklad, nemylim-li se, mohou pristupovat jen k prvnim 16 MB fyzicke pameti).

Samozrejme mam na mysli hlavne pripad obecneho pocitace. Pokud vyuzivate to PC jako chytrejsi mikrokontroler, budiz. Tam je to vcelku jedno. Nicmene pro vase ucely vubec nepotrebujete paralelni port, ale hromadu GPIO pinu (a SPP vlastne neni nic jineho).

Strucne receno, kdyz rizeni paralelniho portu zvladne obslouzit IC s nekolika tisici tranzistory, je nesmysl to nechavat na (a blokovat tim) procesor s desitkama milionu tranzistoru.

Takže ti vadí vysoké SW zatížení procesoru při obsluze SPP portu? Ale to nepopírá, že ten port naprosto správně funguje pro bytestream přenos (jen ne zcela optimálně, jak by se dnes očekávalo). Ostatně, máš-li zařízení, které „stíhá“ ECP, přepni to na ECP a máš po problému se zátěží. Pokud to zařízení nestíhá, je nutné přenášet „pomalu, s vysokou zátěží, ale jistě“…

Ano, používám parport jako jednoduchý GPIO port. Má to 2 výhody:
 – až do nedávna (a občas ještě i dnes) byl paralelní port v počítači naprosto zadarmo
 – na jeho ovládání se za 20 let naprosto nic nezměnilo!!! Zkus použít nějakou obecnou GPIO kartu. Po 2 letech zjistíš, že její výrobce už neexistuje nebo že vyrábí jinou, „lepší“ kartu, která se ale taky jinak ovládá a tedy to musíš přeprogramovat…

Když už jseš tak vysazený na vysokou zátěž systému, proč tě nerozčiluje, že ten supermoderní USB port nemá předávání událostí přes interrupty a systém je naprosto zbytečně zatěžován poolingem!!! Může mi někdo vysvětlit, proč v 21. století se musí systém 150-krát za vteřinu dotazovat na USB portu, zda nebylo připojeno nebo odpojeno USB zařízení, zda uživatel nestisknul klávesu na klávesnici nebo nepohnul myškou nebo provedl nějaký úkon na tabletu nebo digitiéru, zda nedošel papír v tiskárně, zda je v modemu připraven další znak k přečtení, atd. atd.?!?! Proč prostě systém v pohodě nespinká (nebo renderuje video) a nepočká, až mu port oznámí, že zařízení „klávesnice“ potřebuje předat stisknutou klávesu? Místo toho, aby počítač klidně celou noc renderoval, tak se za noc cca 5 milionkrát zeptá každého připojeného USB zařízení, jestli na něm nenastala nějaká událost. Tomu říkáš moderní zařízení??

Takže ti vadí vysoké SW zatížení procesoru při obsluze SPP portu?

 

Ano.

 

Ale to nepopírá, že ten port naprosto správně funguje pro bytestream přenos

 

To neopopiram. Ze je neco nevhodne neznamena, ze to nemuze korektne fungovat.

 

Když už jseš tak vysazený na vysokou zátěž systému, proč tě nerozčiluje, že ten supermoderní USB port nemá předávání událostí přes interrupty a systém je naprosto zbytečně zatěžován poolingem!!!

 

AFAIK tohle neni problem USB, ale jen nekterych starsich USB radicu. U novejsich fyzicky samozrejme k pollovani stale dochazi, ale pry ho iniciuje sam radic bez asistence procesoru. Ale nevim, (U|O|E)HCI standardy jsem zatim necetl.

 

Kazdopadne obsluhovat periferii 150-krat za sekundu je jeste snesitelne – koneckoncu tiku scheduleru (a tedy interruptu od casovace) je srovnatelne mnozstvi. A takova obsluha spotrebuje zanedbatelny podil z celkoveho vykonu.

Hele, buď spravedlivej. Pokud ti vadí vysoká SW zátěž u prvního návrhu LPT, tak to porovnávej s prvním návrhem USB. A udělej FUJ! nad návrhem SW poolingu pro USB. Pokud chceš porovnávat současné USB, porovnávej ho se současným ECP LPT. Navíc si uvědom dobu vzniku: SPP parport byl navržen v době, kdy 8086 procesor měl cca 20k tranzistorů. Pokud v té době někdo navrhne port, který se skádá z cca 500 tranzistorů, tak to byl dost složitý HW návrh. Navíc ten návrh byl geniální, protože bez jakýchkoliv změn vydržel více než 20 let. USB byl navržen už v době, kdy přidat nějakých 10k tranzistorů do brouka už nebyl žádný problém a přesto byl navržen tak debilně, že vyžadoval SW podporu poolingem!!

Nepovažuji za snesitelnou žádnou, ani nepatrnou činnost, pokud je zbytečná. Obsluha časovače není zbytečná, protože nelze časovačem přímo spustit nějaký SW proces. To musí udělat SW supervisor. Pooling USB je zbytečný – tedy nesnesitelný. A i když bude udělán HW, stejně zpožďuje přenos dat, protože 150× za vteřinu je nutné přerušit ten přenos dat do externího HDD a každého připojeného zařízení zvlášť se zeptat, jestli nepotřebuje obsloužit… Brrrr!

Ostatně ani to pro tebe nesnesitelně vysoké zatížení procesoru při obsluze SPP portu není tak obrovské, jak by se ti mohlo zdát. Počítej se mnou: stránka A4 v grafickém čb módu a rozlišení 600 DPI má necelých 5 MB informace. K přenesení jednoho bytu SPP portem potřebuješ 10–15 instrukcí. Tedy na přenesení této stránky potřebuješ pouhých max 75M instrukcí. To je v době gigaherthových procesorů méně než 100 ms strojového času na přenos stránky. Opravdu, to je tedy neskutečně vysoké (až trestuhodné) zatížení procesoru, že? :-)

Navíc si uvědom dobu vzniku: SPP parport byl navržen v době, kdy 8086 procesor měl cca 20k tranzistorů.

To ja si uvedomuju. V dobe 8086 to byl rozumny design. Ale v devadesatych letech uz to bylo beznadejne zastarale, natozpak dnes.

A i když bude udělán HW, stejně zpožďuje přenos dat,

Ano, ale jak to tam udelat lepe, kdyz tam je halfduplexni sbernice? Bud by bylo treba mit vyhrazene draty na bus arbitration ci intrerrupt, nebo pouzit nejakou obdobu CSMA (coz by samo asi prineslo vic problemu, nez kolik by to resilo). Idealni by bylo, kdyby USB byl fullduplexni a hub by fungoval stejne jako ethernet switch, ale pak by bylo treba mit 6 dratu misto 4.

Počítej se mnou: stránka A4 v grafickém čb módu a rozlišení 600 DPI má necelých 5 MB informace. K přenesení jednoho bytu SPP portem potřebuješ 10–15 instrukcí. Tedy na přenesení této stránky potřebuješ pouhých max 75M instrukcí. To je v době gigaherthových procesorů méně než 100 ms strojového času na přenos stránky.

Jenze tenhle vypocet je nesmyslny – zanedbava tri dulezite veci:

1. granularita – udelat 10k instrukci 100* za sekundu bude z mnoha duvodu pro system vyrazne mensi zatez nez udelat 10 instrukci 100k* za sekundu.
2. in/out instrukce netrvaji takt, ale trvaji tak dlouho, nez dany hardware acknowledguje danou operaci. Coz vcelku nezavisi na frekvenci procesoru – cim rychlejsi procesor, tim vic taktu takova instrukce bude trvat. A bude to odhadem minimalne radove tisice (a spis jeste vic) taktu na jeden out. V tomhle ma vyhodu MMIO, ale bezne radice paralelniho portu MMIO nepodporuji.
3. Nejspis bude treba mezi nekteryma IN/OUT instrukcema mit nejake explicitni cekani, to bude nejspis prilis kratke na to, aby behem toho melo smysl schedulovat nejaky proces. Takze se pri tom i spousta casu nevyuzitelne proflaka.

Ha, priserny redakcni system mi zmrvil komentar. Takze jeste jednou – ten vypocet je nesmyslny – zanedbava tri dulezite veci:

Zaprve – granularita – udelat 10k instrukci 100* za sekundu bude z mnoha duvodu pro system vyrazne mensi zatez nez udelat 10 instrukci 100k* za sekundu.

Zadruhe – in/out instrukce netrvaji takt, ale trvaji tak dlouho, nez dany hardware acknowledguje danou operaci. Coz vcelku nezavisi na frekvenci procesoru – cim rychlejsi procesor, tim vic taktu takova instrukce bude trvat. A bude to odhadem minimalne radove tisice (a spis jeste vic) taktu na jeden out. V tomhle ma vyhodu MMIO, ale bezne radice paralelniho portu MMIO nepodporuji.

Zatreti – Nejspis bude treba mezi nekteryma IN/OUT instrukcema mit nejake explicitni cekani, to bude nejspis prilis kratke na to, aby behem toho melo smysl schedulovat nejaky proces. Takze se pri tom i spousta casu nevyuzitelne proflaka.

Nejspíše jsi si přečetl příklad pro začátečníky, jak programovat parport… Protože jsem programoval dost dlouho v PC assembleru (jinak těch 200k kroků/sec z PC nelze vymáčknout), musím ti ukázat, jak vypadá IN/OUT programování:

push BX, AX, DX ;uložení registrů
inc BX ; inkrementovat pointer
mov BX,[pointer odesílaných dat]
cmp BX,[Počet prenesených dat] ; je ještě co přenášet?
jz KonecPrenosu ; všechna data přenesena
mov AL,LPT_Buffer[BX] ; natažení dalšího byte pro prenos
mov DX,0×378
out DX,AL ; ano toto je ta OUT instrukce a u 486-ky trvá 2 takty – tím se zapíší data do registru 0×378 je uloženo v DX
mov DX,0×37a ; ještě je třeba vyrobit strobe puls a ten udělá manipulaci s registrem 0×37A
in AL,DX
xor AL,1
out DX,AL
xor AL,1
nop
out DX,AL ;Puls je vyroben, konec přenosu bytu
pop DX, AX, BX ; obnova registrů
IRET ; návrat z přerušení

Protože parport má přerušení, není třeba neustále zjišťovat tisíci instrukcemi, zda zařízení převzalo byte. Až nahodí ACK, vygeneruje se interrupt a na port se „vyhodí“ další byte podle výše uvedené sekvence. Trochu jsem ji zjednodušil, ještě jsou tam 4 instrukce na zjištění stavu tiskárny (zda nedošel papír nebo tiskárna není v chybovém stavu). Samozřejmě tam chybí také inicialitace portu a řadiče přerušení – ale to se provádí jen jednou po restartu. A taky tam chybí zahájení a ukončení přenosu a obsluha chybových stavů – to je trochu složitější, ale zas se to nedělá příliš často…

Po návratu z přerušení se pokračuje přesně tam kde byl běh systému přerušen. A i kdyby tam byl čas jen na provedení jedné instrukce, tak se ta instrukce provede, pokud tam bude času více, udělá se více instrukcí.

Přerušení LPT se nesheduluje jako proces. K přerušení dochází naprosto náhodně v průběhu nějakého běžícího procesu. Provádění procesu se přeruší a po přenesení dalšího byte se pokračuje v provádění procesu. Proces ani „nevyčmuchá“, že byl přerušen. Žádný čas se zbytečně neprofláká, ty moje počty jsou správné.

Jo a k té granularitě: jediné co se musí dělat navíc, když dochází k rozkouskování přenosu pomocí „jednobytového přerušení“ jsou instrukce PUSH na začátku přerušení a POP a IRET na konci. Ale to jsou tak často používané instrukce, že je autoři procesorů dělají jednotaktové. Ostatně jsem je započetl do předchozího výpočtu.

= Nemel jsem na mysli ani tak cekani na ACK, ale podle me dokumentace by strobe puls mel byt dlouhy alespon 1 us

= co se tyce granularity – dnesni pocitace se nechovaji jako 386 nebo mikrokontrolery, neda se doba behu kodu spocitat souctem nominalnich taktu jednotlivych instrukci. Masivni vliv na vykon ma pametova cache. Pristup k bunce RAM, ktera neni v procesorove cache, stoji stovky taktu. Krom toho pri vyvolani interruptu nejspis znacny cas (na x86 procesorech v protected rezimu) zabere zmena opravneni procesoru. A to ani nemluvim o rezii operacniho systemu (genericky kod spusteny pri interruptu, ktery pak preda rizeni samotnemu driveru).

= „out DX,AL ; ano toto je ta OUT instrukce a u 486-ky trvá 2 takty – tím se zapíší data do registru“ – to mozna na 386. Podle cetne dokumentace IN/OUT na adresy 0–0×3ff trva zhruba 1 us vcelku bez ohledu na rychlost procesoru (puvodne zrejme kvuli casovani ISA sbernice a na novejsich pocitacich se to zachovalo pro lepsi kompatibilitu) Takze na modernich procesorech to budou tisice taktu.

Takze i kdyz zanedbam vsechny ostatni vlivy, tak muj vypocet bude 5 MB * (5 IN/OUT instrkuci na B) dava 25 MIO, coz pri 1 us na 1 IO dava 25 s procesoro­veho casu.

ad a) .. tak nejak je to pro me zatim spis hracka, nna te urovni ridit krokac dovedu (vcetne mikrokrokovani), ale profi jsem to nikdy nepotreboval. Takze hotovy konec asi ma smysl.

ad b) Asi mi porad prijde rozumne zvolit vhodne mikro. ARM na 100MHz + 256k flash a nejaka ram dnes stoji par korun (atmel kolem 150kc? Uz jsemm to dlouho neresil)

Synchronizaci na krok bych resil mimo USB – bud jedno mikro, nebo pridat sync signal mezi nekolika.

A pouziti parportu pred patnacti lety … tenkrat bych to asi kdyztak resil ISA kartou a hotovo. A mozna na ni jen dat fifo, ktere mi zaridi presne casovani pokud procesor nahodou nestihne, ale to je asi zbytecne. Je fakt, ze dnes by ISA byl dost problem, ale pokud se nepletu, pak PC104 je vicemene to same.

Asi je to fakt vec pristupu. Vase zarizeni zjevne funguje (a skoro bych tipoval, ze zacalo jako napul bastl, ktery se nakonec postupne vylepsil).

Ad USB – Zalezi na typu zarizeni. Pokud budu delat zarizeni pripojitelne k uzivatelskemu PC, tak se budu snazit udelat na casovani vicemene nezavisly protokol a nejaky rozumny interface – RS232 drive, dnes uz USB.

A pokud by uzivatelovo PC jen neco zobrazovalo (a nejlepe pres WWW prohlizec, ethernet pripojeni ridiciho embedded PC), tak bych mel nejvetsi klid ;-)

USB/LPT převodníky jsou HNUS.

1) zapomeňte na to, že budete tahat za režijní signály, není to ve specifikaci USB/LPT standardu. Výrobci švábů mívají nějaké svoje speciální API + upravený firmware, kterážto kombinace to třeba i umí – ale k tomu se dostanete pouze pokud podepíšete NDA a koupíte pár desítek tisíc těch švábů.

2) ovladače pro Windows dodávané výrobcem převodníku jsou obvykle pochybného stáří a kvality, softwarový základ od výrobce švábu je ukryt pod nánosy bastlů výrobce převodníku (a vanilkový ovladač od výrobce švábu buď neexistuje, nebo je závislý na vanilkových USB VID/PID, které výrobce převodníku změnil)

3) použitý superlevný šváb od čínského výrobce má problém „udržet stolici“, a často prostě vůbec nefunguje. Z tiskárny třeba vyleze kus obrazu správně a pak chybová hláška. Nebo taky vůbec nic. A finta: za ty prachy nemá ani smysl to reklamovat, poštovné je skoro stejně drahé.

4) smíte v zásadě jednu věc: posílat na ten výstup stream bajtů. Pokud Vám to převodník dovolí (pokud nevyžaduje do začátku kompletní handshake s IEEE-1284 tiskárnou). Což se možná liší sváb od švábu a firmware od firmwaru. Číst data z portu zpátky? Pouze přes IEEE-1284 režim (framing) na LPT portu. I při tom zápisu si widle můžou data po libosti bufferovat. Veřejně dobře popsané rozhraní je dokonce skrz spooler tiskových jobů, přímý přístup na USB device není oficiálně podporován (nějaké návody lze dohledat v různých programátorských fórech). Čili zapomeňte na nějaké časování. Ostatně podle čeho byste časování ve woknech taktoval, když nemáte z user space přímý přístup k hardwaru Vašeho PC… podle user-space časovacích funkcí? :-)

5) Z DOSu si na USB/LPT převodník nešáhnete – ovladače pokud vím nejsou. Nemluvě o tom, co už tu někdo zmiňoval, že nelze vyvolat interrupt zvenčí. Takzvaný „interrupt mode“ USB přenosů znamená periodický polling taktovaný časovačem uvnitř UHCI. A nota bene u standardního USB/LPT převodníku stejně nepřipadá v úvahu.

Nedávno jsem se snažil rozchodit připojení staré LPT tiskárny (HP LJ III) na USB. Nakonec jsem pro srovnání zkoušel i několik novějších packardů (LJ4, LJ6) které už umí IEEE-1284 identifikační transakci a ECP režimy. Výsledek: první převodník se švábem WinChipHead CH340S se mi nepovedlo rozchodit vůbec. Nula bodov. Druhý převodník s čipem Prolific PL2305 (IEEE-1284 compatible) kupodivu takřka nechodil s novějšími IEEE-1284 tiskárnami, ale s tou důležitou (prastarou HP LJ III) nakonec jede jako z praku. Obecně na převodníky založené na PL2305 je nejmíň stížností – ale podle mých zkušeností není úspěch zdaleka zaručen…

Pro obecný výstup diskrétních TTL signálů přes USB by možná bylo lepší použít nějakého jednoúčelového švába pro „USB GPIO“, pokud taková věc existuje. Zatím jsem žádného nepotkal. Potkal jsem nekřesťansky drahé hotové modulky tohoto typu na bázi nějakého univerzálního švábu (MCU, FPGA) s USB rozhraním, ke kterému se pochopitelně dodává hotový closed-source driver.

uz jsem to zminoval: http://www.obdev.at/…b/index.html

Staci dil atmel, jednou ho naprogramovat, pak jde pouzit bootloader. Staci krystal, 2 zenerky, 3 odpory, usb konektor. Sice je to trosku prasarna (zener na snizovani napajeni, uplne neodpovida casovani a impedance ..) ale podle vseho to funguje fajn

Drivery existuji pod linux i wokna.

A pro ovladani pinu neni problem napsat kousek kodu, navic atmel ma spoustu dalsi veci (ADC/PWM/…)