Názory k článku Stavíme ochranu paralelního portu
-
badger (neregistrovaný)
Ahoj, jinak pokud by nekoho zajimaly ty ruzny cisla na zacatku, tak je to hlavne o pracovni teplote a rozsahu napajeciho napeti.. nasel jsem sice jen teplotni rozsahy ale lepsi nez nic: 84 serie: –25°C az +85°C 74 serie: 0°C az +70°C 64 serie: –40°C az +80°C 54 serie: –55°C az +125°C (tusim, ze tahle splnovala nejaky pozadavky na vojensky vybaveni)
-
Clock (neregistrovaný)
Yokotashi, to me vzdycky nastve kdyz nekdo naznacuje, ze by moje vyplody mely fungovat diky stesti, kdyz to neni pravda. Ani jsem nedelal dlouhou serii experimentu.
Z datasheetu HC rady je znamo jaky odber ma hradlo v poloprepnutem stavu a kolik nanosekund mu trva prechod z jednoho stavu do druheho a jake je zpozdeni. Vystupni proud do zkratu se da zmerit. Z toho se da odhadnout, jak velke budou ztraty diky paralelnimu zapojeni hradel.
Kdyz jsem to radove odhadnul, prislo mi ze to nestoji za rec, ze ztraty diky prepinani samotnemu jsou vetsi. Tak jsem to s klidem paralelne spojil.
-
Yokotashi (neregistrovaný)
Jenomze v datasheetu uz asi neni rozptyl zpozdeni pro ruzna hradla (navic v ruznych chipech).
Takovehle zapojeni muze v digitalni logice chodit jenom se stestim, nebo s dlouhou serii experimentu.
Ty to nepouzivas jako digitalni logiku, ale jako posledni stupen zesilovace, ktery budi LEDku necim, co by klidne mohl byt sinus a melo by to stejne chodit …
-
Clock (neregistrovaný)
Rozptyl zpozdeni tam sice neni, ale podle datasheetu Philips ma HC typicke zpozdeni 7ns. Rozptyl bych odhadoval tak na 3ns. Vic nez 7ns to rozhodne nebude, to by porusilo kauzalitu :)
Ted rekneme ze jedno hradlo sepne za 3ns a druhy za 10ns, tak to 6ns smazi do zkratu. Ten vystup da ztezi 20mA do zkratu jestli si spravne pamatuju, a prepina to nejrychlejc 1 za 50ns. Cili z 50ns je 6ns zkrat, to je prumerny odber 2mA navic na hradlo neboli 12mA na cip. To je 60mW na cip to v pohode uchladi (Philips HC family specifications: max. odpar na pouzdre DIL 750mW).
V realu si myslim ze to bude jeste min, protoze ty hradla nespinaji natvrdo ale prochazeji plynule jakymsi napul sepnutym stavem (datasheet philips: output transition time 7ns) kdy plny zkratovy proud asi nedaji.
Ty hradla jsou interne na zkrat navrhovany – kdyz se vystup nastavi do pulky, bere to asi 20mA (podle kteryho datasheetu uz nevim, tusim 74HCU04). Takze jestli to na tech par nanosekund zkratuje uvnitr nebo venku je podle me jedno a zadna prasarna takovej navrh podle me neni.
-
Clock (neregistrovaný)
Jeste me napada treti argument: Podle Fairchilda je absolute maximum rating output DC current per pin 50mA, mnou odhadovany pridavny proud zpusobeny paralelnim spojenim je 2mA. Mam tam 15 hradel budicich 70mA DC proudu, to je 4mA na hradlo, celkem 6mA. I kdyby rozptyl byl 7ns (ja pocital 3ns), proud zpusobeny paralelnim zapojenim bude stale jen 4.6mA, to je celkovy proud 8.6mA z 50mA. I kdyby hradlo dalo do zkratu ve skutecnosti 100mA (jako ze verim, ze da 20mA), proud zpusobeny paralelnim zapojenim by se vysplhal na 23mA, celkovy proud 27mA z 50mA. To ma stale spoustu rezervy.
Kritika tech dvou lidi ze Ronja je kvuli tomu prasarna mi prijde nefer, protoze oni zadny argument neprezentovali proc by to prasarna byt mela, zatimco ja jsem prezentoval 3 nezavisle vypocty, proc je to korektne navrzene.
-
vystupy cmos logiky typicky snesou kratke zkraty, kdyz jsou delsi nez cca 1us (jednorazove), kremik se roztavi. pri opakovani zkratu na vystupu je odolnost samozrejme mensi. mezi vystupy se v tomhle zapojeni davaji odpory, aby se ty vystupy neodsmahly navzajem. u obvodu na vyssi frekvence byvaji na vystupu proudove zdroje, takze tam by to nevadilo. ale to neni pripad rady 74×x.
dalsi problem je, ze diky zkratum na vystupu bys mel mit dobre blokovane tyhle integrace. pulsy v napajeni vzniknou kvuli rozdilum v parametrech jednotlivych hradel, je tam ruzne zpozdeni (navic zavisle na teplote :-). bez blokovani budou po napajeni prolezat pulsy na frekvencich odhadem 100MHz-1GHz. co jsem koukal do schematu http://ronja.twibright.com/…/nebulus.png tak mi nepripadalo, ze tyhle pulsy blokujes. tj. cekal bych, ze to zapojeni nebude poradne fungovat na plosnaku a bude se to muset ruzne geometricky preusporadavat, aby se to samo nezarusilo az k nefunkcnosti. koukal jsi nekdy co se deje v napajeni s cca 10GS osciloskopem?
takze ano, myslim, ze tvoje vyplody skutecne funguji diky stesti. a klidne se kvuli tomu rozciluj, tvuj problem.
-
Clock (neregistrovaný)
Nepripadalo ti ze v Nebulusu pulsy na napajeni blokuju? To me prekvapuje, protoze v tom schematu je nakreslenych asi 20 keramickych kondenzatoru na napajeni tech svabu.
Kdyz rikas „tvoje vyplody skutecne funguji diky stesti a klidne se kvuli tomu rozciluj, tvuj problem“, to me sere.
-
Biktop (neregistrovaný)
Tak tady se připojuji k autorovi článku. V tý Ronje máš více takovýchhle prasáren (alespoň před lety tomu tak bylo) . Nejsi sám, když otevřeš červenou řadu Amára, podobné prasečinky tam má víc lidí. Řekl bych, že podle takovýchto návrhů se dá celkem jednoznačně poznat buď bastlíř-samouk experimentártor, nebo bastlíř-samouk se znalostmi fyziky (podle Ohmova zákona to přece vychází, tak co) od někoho, kdo se tím zabývá vážně.
-
Yokotashi (neregistrovaný)
Optrony jsou pomale … a jsou planovane do pristiho dilu.
Zatim jsem nikdy neodpalil ani jeden port a to vicemene oddelovac nepouzivam … a driv jsem na paralely pripojival vsechno, co mi prislo po ruku :-).
Oddelovac to ochrani proti zkratu a asi i proti pripojeni +-12V – sezerou to vstupni diody tech chipu. Kdyz tam nekdo pripoji 220, tak samozrejme uvidi ohnostroj.
-
JArda (neregistrovaný)
Připojováním strojů k parportu se zabývám již 17 let (ročně cca 90 strojů), takže o tom vím dost. Snad by stálo upozornit všechny zájemce, že parport je poměrně odolný a „leccos snese“, ale že přesto je riziko poškození portu velice reálné…
Nejdříve bych upozornil, že ani vysoký proud ani vysoké napětí „neodpráskne“ polovodič. Ke zničení dojde teprve tepelnými účinky toho vysokého proudu či napětí: chip se tak ohřeje, že dojde k jeho roztavení a tím i zkratu většiny pinů mezi sebou. Následně dojde k přerušení nejzatíženějších přívodů uvnitř pouzdra (zpravidla napájecích) a ostatní piny zůstanou zkratovány.
Proto ani hradlový oddělovač nezachrání port proti zničení: Jak jsem psal v jiném příspěvku, TTL hradlo nesnese zkrat proti +5V. Pokud k němu dojde, hradlo se „odpráskne“. Pak už záleží na náhodě, které přívody se přeruší, ale může se stát, že se těch +5V přenese i na vstup hradla a tedy na výstup parportu a ničení pokračuje dále – jenže tentokrát uvnitř počítače. A protože většina dnešních počítačů má integrovaný port, dochází k částečnému zničení chipu jižního můstku a tedy k znefunkčnění i jiných portů, např. klávesnice, USB i řadiče disku. Několik takových základních desek, co dostaly elektrošok na parport a od té doby už nemůžou najít pevný disk jsem už viděl…
Proto nesouhlasím s tvrzením, že by TTL hradlo ochránilo proti +-12V! Vstupní diody snesou max 50 mA, pak jdou do křemíkového nebe a s nimi i celý chip. Ostatní viz výše.
A že optrony jsou pomalé? I ty nejobyčejnější PC817 za 3,50 Kč „jdou“ do 5–10 kbit/s, no a 6N137 za 13 Kč jdou do 10 Mbit/s. A takové rychlosti nedosáhnete na parportu ani když ho přepnete do ECP módu s DMA přenosem. -
Yokotashi (neregistrovaný)
Aha, tak to jsem mel stesti. Me hradlo vzdycky port ochranilo. Priznavam, ze zpusob likvidace logickych obvodu jsem nikdy nestudoval a neexperimentoval s nim …
Ten PC817 je podobny tomu, co jsem pouzival ja. Na oddeleni diod a podobnych veci je to perfektni soucastka, ale na treba paralelni laplink uz s tim bez zpomaleni neudelate.
A kdyz jsem chtel opticky oddelit 10Mbit ethernet, tak s tim byly poradne problemy. Zadny dost rychly optron nesel v .cz koupit. Sice jsem vymyslel jak na to (byla v tom SFH203 z ronji a proti ni cerveny 5mW laser – s predpetim 24V z toho slo dostat 50MHz), ale uz jsem to nepostavil. Holt me zivi neco jineho a nestiham sledovat vsechno. Diky za info, ten 6N137 se bude hodit. Skoda, ze jsem o nem nevedel driv … do pristiho dilu ho nestihnu vyzkouset.
-
finn (neregistrovaný)
Na rychlé přenosy (třeba těch 10Mbitů) se už nepoužívá optika, ale třeba něco jako ADUM1201 (http://www.analog.com/…product.html).
-
JArda (neregistrovaný)
Prohlédněte si katalog GM – je tam spoustu optronů – srdce jásá.
Likvidaci hradel jsem nestudoval ani úmyslně neexperimentoval. Veškeré zkušenosti jsem získal položením si otázky: Jak je to možné, že ten brouk umřel? Samozřejmě brouka vyměním a pak ho „cvičně proťukám“ šlusmetrem a nestíhám se divit, co je s čím prošluslé… Samozřejmě odpověď je hledána o to úporněji, čím větší je škoda. A takový mainboard, co nedokáže najít disk, to je důvod k důkladnému rozmýšlení. Samozřejmě, že tam byl hradlový posilovač (dnešní parporty mají tak malou zatížitelnost, že nedokážou vybudit rychlé optrony) i optrony. Ale když pak nějaký údržbář pustí do přístroje šroubek, matku, šroubovák, případně rovnou 17-ku prstýnkový klíč – to se pak nestačíte divit, kolik toho „zemře“…
Proč chceš oddělovat ethernet? Vždyť v každé síťovce je trafíčko, co TP drát galvanicky oddělí od „zbytku světa“. 100V to spolehlivě vydrží – to nestačí? -
zu1234 (neregistrovaný)
1. Obecně k celé diskuzi: Vadí mi že někteří přispěvatelé jsou fachtidioti, kterým nikdy nedocvakne, že tento článek je určen začátečníkům.
Troubí do světa: mládeži, než abyste něco pokazili, raději zůstaňte sedět u piva nebo vaší oblíbené hry.
Asi je děsí přicházející konkurence ;-).
Je normální začínat od jednoduchých věcí!
Ale hlavně začít!!
2. Nyní k věci: ty vstupy a výstupy není možno zajisti nějakou zenerkou, transilem, nebo co já vím čím??? -
1. lpt beha do cca 1–2MHz, na coz optrony staci. 2. vstupni diody tech 12V sezerou na zlomek sekundy, pak se roztavi. teda pokud tam nedavas ochranne odpory na omezeni proudu a nenakreslil jsi je do schematu. btw, pres dost velky odpor jde na cmos vstup zapojit i 220V a delat detekci pruchodu nulou – pokud si tedy nekdo veri natolik, aby tohle zkousel vyrobit.
-
Clock (neregistrovaný)
Ted si krasne rejpnu, mam na to i oficialne diagnostikovanou poruchu osobnosti F60.3 :D
Jeste lepsi nez co nejlepsi parazitni indukcnost je parazitni indukcnost ktera vytvari rezonanci na hornim kraji kmitoctoveho pasma ruseni obvodu. Pri rezonanci se takovy kondik chova jako parazitni seriovy odpor kondenzatoru, cili jeste lepe, nez kdyby to by lidealni kondenzator.
Priklad: 100n bez indukcnosti ma na 100 MHz (30–15i) mOhm, zatimco s vhodnou parazitni indukcnosti ma pouze 30mOhm.
V praxi to tedy nestoji vubec za rec a zminovat to muze skutecne jedine nekdo s poruchou osobnosti.
Jaky ma parazitni indukcnost privodu efekt? „Rule of thum“ Tektronixu je 1nH na milimetr cesticky na plosnaku. Maji-li tedy privody celkem 20mm, ma to 20nH, cili na 100MHz 12i Ohmu.
-
Clock (neregistrovaný)
Rule of thum je samozrejme chyba. Jedinec, co ma poruchu osobnosti F60.3 si ale mysli ze at udela cokoliv, je to spravne, protoze on je ten jediny spravnyna svete a ostatni jsou spatni a delaji vsechno chybne.
Tohle se neprihnojuje. Podle meho psychoterapeuta je to zpusobene vychovou.
-
JArda (neregistrovaný)
Cituji „Obvody s otevřeným kolektorem jsou odolnější, snesou větší proudy směrem do země, naopak poskytnou menší proudy při log 1“. To se moc nepovedlo: hradla s OC mají stejné proudové zátížení do země, jako srovnatelné hradla „normální“ a při log 1 neposkytnou naprosto žádný proud – proud poskytne jedině ten pull-up odpor. Čím menší odpor, tím větší proud. Ale ouha – při log 0 se o ten proud, který teče pull-up odporem, snižuje zatížitelnost hradla.
Jinak co se odolnosti týče: klasické TTL obvody, z kterých tady „vaříte“, snesou zkrat jednoho hradla na zem (říká katalog-mě se podařilo zkratovat 4 vývody na zem a brouk to přežil, i když byl dost žhavý). Samozřejmě u hradel s OC můžete zkratovat třeba všechny výstupy na zem a nic se nestane (žádný proud z hradla neteče, tedy ani hradlo není nijak zatířeno). Zkrat výstupu proti napájení (+5V) během malé chvilky „odpráskne“ ten vývod nebo celý obvod. Na to pozor při bastlení toho oddělovače: zkontrolovat, že žádný z drátů vedoucích k výstupům parportu nemá zkrat proti +5V, pokud nechcete o port přijít… -
Nezlob se na mě, ale než vypustíš do světa nějaký článek, měl by sis ověřit některá fakta a opravit zjevné překlepy.
- pravdivostní tabulka NOR je až na první řádek celá špatně
- A OR B = NOT(NOT(A) OR (NOT(B)) je taky blbě – má to být
A OR B = NOT(NOT(A) AND (NOT(B))
- řada 74HC NENÍ kompatibilní s TTL, má jinou rozhodovací úroveň na vstupu.
Standardní TTL má od 2.4V nahoru logickou jedničku, HC má od 2.5V dolů logickou nulu. Co se stane, když máš na vstupu napětí 2.45? TTL to považuje za H, HC to považuje za L. TTL na výstupu nezaručuje úrovně kompatibilní s HC. (naopak ano). Věř mi. V jedné desce jsem měl GAL a jeho výstup šel na HC. Bylo to nespolehlivé.
Jestli jsou v článku ještě další nepřesnosti, to nevím, dál už jsem to nečetl.
Takže ještě jednou: HC → TTL bude fungovat TTL → HC NEBUDE FUNGOVAT SPOLEHLIVĚ, musel bys tam dát pullup
řada 74HCT je naproti tomu plně kompatibilní s úrovněmi TTL. Proto taky existuje.
-
Yokotashi (neregistrovaný)
At to posobe ctete kolikrat chcete, takovehle chyby proste nejsou videt. Mozek tam vidi to, co si mysli, ze tam ma byt. A korekturu dela osoba elektroniky a boolovske algebry neznala :-(.
Diky za informace o tech urovnich. Pro tenhle clanek jsem to nezjistoval, protoze mym cilem bylo doporucit cokoliv ne-CMOS. Ja HC proste nepouzivam, protoze tam, kde chci odolnost davam LS/ALS a tam, kde rychlost davam F. A HCT pouzivam jenom, kdyz nejde obvod koupit v jinem provedeni, nebo mi jde o spotrebu … takze jsem to ani nevedel. Dobra pasticka … podobna, jako kdyz clovek mixuje obvody TTL a CMOS (rada 4000).
-
mhi (neregistrovaný)
Na spinani veci jako LED/rele/apod. se hodi mnohem vice ULN2003. Za nej muzete dat i rele. Nechapu, proc vymyslet nove postupy. Shodou okolnosti mame ULN2003A v DILu plnou krabici (par tisic ks), omylem se objednalo spatne pouzdro. Kdyby bylo jak efektivne to rozdat, tak rad rozdam.
V clanku mi chybi co s Ucc? A dale kdyz shori 74×xx, tak to v zadnem pripade nedava zaruku, ze neshori i LPT, jen to tu pravdepodobnost snizuje. Setkal jsem se uz nekolikrat se zrusenym hradlem a s nim i prislusne I/O piny MCU.
Jine nepresnosti uz jsou v dalsich komentarich.
-
Yokotashi (neregistrovaný)
ULN2003 vypada zajimave … par bych si jich vzal. Odkud jste?
Ten oddelovac byl minen k oddeleni jakehokoliv bastlu, ne vyhradne, jako budic LEDek – to bych tam nekreslil ty pull-upy. A taky to funguje, jako tvarovac k blbym portum.
Ucc – jak jsem psal v uvodu – se vezme z napajeciho konektoru pocitace, nebo z USB. Odber je maly.
Zarika, ze to ochrani port samozrejme neni, ale narozdil od optickeho oddeleni je to rychle. Me zatim port nikdy neshorel … ten oddelovac proste snizi pravdepodobnost. To jsem mel uvest explicitne.
-
mhi (neregistrovaný)
Jsem z Prahy, resp. kousek za Prahou. To ale opravdu budete mit (casove) levnejsi koupit v GMku, ten obvod muze stat tak 5 korun. Mne jen tak nesezenete,,, no ale pokud stoji vyznamne vice, tak se po te krabici podivam.
Neberte to nijak zle, ale to tvrzeni ‚me zatim port neshorel‘ je opravdu desive. To je jako ruska ruleta… mne taky prezila spousta zapojeni, kdy obvod byl temer do ruda. Ale preci jenom takovou vec zakzanikovi nedam.
Prectete si teorii obvodu I z CVUT FEL a datasheety k obvodum, ktere pouzivate. Potom vam bude jasne, proc a kde delate chyby. Skripta jsou za stovku, datasheety zdarma.
A mimochodem, optocleny se delaji i VELMI rychle.
-
Yokotashi (neregistrovaný)
Ja jsem ze severu Prahy. Myslel jsem to tak, ze kdybych mel nekdy cestu okolo, tak bych si jich treba stovku vzal.
Tohle tvrzeni jsem taky nenapsal do clanku. To, ze me port za nejakych 14 let neshorel znamena jenom to, ze zacatecnik, ktery bude aspon trochu opatrny, si sve p100, ktere k tomuto ucelu koupil za dve piva, patrne nijak brzy neodpali. Nic vic. Davat zakaznikovi neco na paraleni port je vubec problem, protoze kazdy port je jinak zpraseny a co na jednom chodi, na druhem nechodi. RS232 vyrobci tolik neprasi (maximalne vystupni napeti a to je porad v mezich normy).
Umyslnou likvidaci obvodu jsem nikdy nezkousel, ani nepocital. Kdyz tak nad tim uvazuju, tak obvod z rady 74 jsem snad nespalil nikdy a z rady 4000 tak 3–4. Vetsinou likviduju vykonove FETy, schottkyny, stabilizatory, operaky, procesory a tak …
-
PACi (neregistrovaný)
tak to me dost zklamalo… cekal jsem optocleny a ono nic… :-(
teda necekal jsem http://www.sunrom.com/index.php?… , ale aspon neco jednoducheho…
-
Yokotashi (neregistrovaný)
Ten kod jsem naposledy modifikoval nekdy v roce 2003 …
Jak tak do toho koukam, tak se usleepuje 2× pouze v pripade, ze bylo detekovano zmacknuti nejakeho tlacitka (je tam continue za poslednim else). Rozdil mezi timhle a 2× delsim usleepem je v tom, ze k detekci zmacknuti dojde v prumeru za polovicni cas, ale hodnota se meni stejne rychle, jako by tam byl 2× vetsi usleep.
Jinak zkusenost z dlouhodobeho provozu je, ze opravdu nedochazi k samovolnym zmenam hlasitosti, ani mute/unmute, vlivem ruseni.
-
Yokotashi (neregistrovaný)
Prectete si neco o protokolu USB a zauvazujte, jak se to slucuje se tretim dilem serialu pro zacatecniky, z nihz mnozi nikdy nedrzeli pajecku v ruce.
A to nebudu hovorit o tom, ze USB je naprosto priserna vec, kde nejde zvenku vyvolat interrupt, vsechno se musi pollovat a kvuli jednomu bitu se konstruuje urb a kamsi posila. Takze zatimco blikani LEDkou zabere asi tak 3 instrukce (+ contextswitch navic), tak udelat totez pro USB zabere nekolik tisic instrukci. O reakci na nejaky vnejsi podnet vubec nehovorim.
Ostatne zkuste si koupit seriovy port pro usb (nejaky FTDI232), pripojit k nemu terminal (treba VT510 … nebo druhy pocitac se seriakem) a rict kernelu, ze to je jeho konzole. Hadejte, co uvidite 1. pri bootu 2. v pripade problemu s kernelem (idealni je RT linux + par RT procesu + nejaky bug, ale staci jenom nejake zatezove testy). Az si to vyzkousite, pochopite, proc je na spoustu veci hardwarovy seriak, paralel, ISA, nebo PS/2 __MNOHEM__ lepsi, nez prasecina jmenem USB.
Na druhou stranu na bezne ovladani, kde nejde o presne casovani a vykonu pocitace je dost, USB dostacuje a casem se k nemu v tomto serialu dostanu.
-
na usb se pouzivaji obvody od ftdi, jako moduly do dil patice je u nas prodava napr. http://asix.cz/ftusbmod.htm. Umi jak seriove, tak paralelni rozhrani. Takze na ovladani ledky a cteni tlacitek jdou pouzit krasne a na pripojeni jednocipu jeste lepe. Prislusni zacatecnici to muzou bez problemu propojit na nepajivem kontaktnim poli, pokud tedy dokazou rozdelit usb kabel na jednotlive vodice, ty pocinovat a zapojit do pole (to a strihani zvonkace jsou nejslozitejsi operace)
Nechapu sice, k cemu potrebujes, aby jednocip na seriaku videl zpravy kernelu pri bootu, ale lide jsou ruzni. Pokud ti na seriovou konzoli na usb kernel nic nevypisuje, zpozdi inicializaci te konzole az po inicializaci usb.. Mas prece zdrojaky, tak si to zmen, kdyz ti to tak vadi.
A co se tyka rtlinuxu, tak to je sracka. da se k nemu rict akorat: nepouzivat! Aspon do doby, nez se naucis programovat bez chyb. Nema to ochranu pameti.. :-(
-
JArda (neregistrovaný)
Zkoušel jsi už připojit nějaké vlastní zařízení k PC? Asi ne, když se tak blbě ptáš. Přes parport jseš např. schopen připojit i 2 krokové motory (pouze s výkonovými zesilovači) k PC a ještě pár vývodů zbyde na řízení zbytku stroje. Zkus to s USB.
Těch příkladů je hodně, např. osmikanálové stopky nebo řízení modelové železnice. To vše jde s minimem hardwaru a „trochou“ softwaru. Když se to pokusíš udělat na USB, nebudeš se stíhat divit, jak se vše zesložití a dost možná, že se ti to ani nepodaří rozhýbat.
A že dnes už parport na základní desce není? Za 300 Kč koupíš desku s 2 parporty do PCI a můžeš začít bastlit… -
Yokotashi (neregistrovaný)
Uz vidim nekoho, kdo jeste nikdy nedrzel pajecku v ruce, jak si lepta desku a osazuje na ni (pokud mozno ne pistolkou – takze si jeste kvuli jednomu pokusu koupil poradnou pajecku) SMD svaba s rozteci nohou 1/20".
Ostatne – dokud tu pisu o paralelu, tak se ozyvaji lidi, pro ktere to eni problem zapajet. Pockejte si, kdo se bude ozyvat a co bude psat, az tu o tom FTDI napisu.
To, ze USB je prisernost je druha vec, ktera s tim nesouvisi. Da se z toho udelat seriak, je to na prumyslovych deskach …
-
JArda (neregistrovaný)
Pomocí LPT řídím 4 osé NC-čko s krokáči do maximální frekvence 150 kHz ve všech osách současně. Každá osa se řídí signály Krok a Směr. Někdy stačí generovat kroky pouze v jedné ose, někdy ve všech. Když se jede po povrchu koule je to „pěkná maštal“. Zkus, jakou maximální frekvenci vymáčkneš z FDI a pak něco raď.
Jo a ty kroky musí být pěkně plynulé (rovnoměrně uspořádané), jinak krokáč vypadne a už se nerozjede – to je další problém, který s FDI nevyřešíš. Jinak na ledky FDI stačí…
Jo a když si chceš pokusně zabastlit, tak si koupíš 1000 brouků? Já koupím jednoho v GM – jenže tam stojí 130 Kč (nejlevnější) a ještě je v TQFP pouzdře – s tím se dobře bastlí na univerzální desce… Ty umíš TQFP pájet? Já jo, ale kolik nás v republice je? -
PL (neregistrovaný)
To je vec pristupu. Na hrani je HW paraelni port asi nejsnazsi, ale rozumen reseni (podle me) je vzit nejake mikro a low-level ridici kod napsat do nej. Pres usb pak staci posilat prikazy ktere se realizuji jako nekolik kroku (coz u obecneho NC asi muze znamenat pouzit furier na kousek povrchu).
Na MCU to muzu naprogramovat hard-realtime, navic muzu pouzit jedno mikro pro krokac a udelat 4 identicke moduly vcetne budicu.
Seny v GM jsou dost drsne, treba ryston ma FTDI asi za pulku. A kusovku (prinejmensim nam) jsou schopni dodat.
A pajeni TQFP se slusnou pajeckou je sranda, do 0.5mm roztece to jde pajet pin po pinu, pripadne po trose zkusenosti jde zapajet celou radu na jednou, jde jen o spravny odhad mnozstvi cinu a dobrou pajeci pastu. I QFN se da zapajet, ale to uz je horsi a je to fakt nej na pokusy.
-
JArda (neregistrovaný)
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í“? -
vita (neregistrovaný)
Už to někdo nahoře zmiňoval. Na pokusy není potřeba myslet na TQFP http://www.asix.cz/…ums2_big.jpg
-
JArda (neregistrovaný)
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?…
-
Ondrej 'SanTiago' Zajicek (neregistrovaný)
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).
-
JArda (neregistrovaný)
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é)… -
Ondrej 'SanTiago' Zajicek (neregistrovaný)
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).
-
JArda (neregistrovaný)
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í?? -
Ondrej 'SanTiago' Zajicek (neregistrovaný)
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. -
JArda (neregistrovaný)
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? :-) -
Ondrej 'SanTiago' Zajicek (neregistrovaný)
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:
- granularita – udelat 10k instrukci 100* za sekundu bude z mnoha duvodu pro system vyrazne mensi zatez nez udelat 10 instrukci 100k* za sekundu.
- 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.
- 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.
-
Ondrej 'SanTiago' Zajicek (neregistrovaný)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. -
JArda (neregistrovaný)
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. -
Ondrej 'SanTiago' Zajicek (neregistrovaný)= 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 procesoroveho casu. -
PL (neregistrovaný)
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 ;-)
-
frr (neregistrovaný)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.
-
PL (neregistrovaný)
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/…)
-
JArda (neregistrovaný)
Neznáš Murphyho: „Co se může stát – to se určitě stane. Co se naprosto vůbec nemůže stát – to se stane taky.“
Asi jsi zatím nic neubastlil nebo jsi génius, když se ti nikdy nic nezkratovalo. Nikdo nedělá zkraty schválně, ale: zapadne kapka cínu, spadne do toho matička/šroubek/kus drátu/odpor(a vývody zkratují obvod), sjede šroubovák, při měření ti ujede hrot, zbortí se vrabčí hnízdo, strhneš přístroj za přívody na zem a desítky dalších nemilých příhod, které by se neměly stát a přesto se stanou a už je „oheň na střeše“ – někdy doslova…
Jenom úplný lamer může narazit autem do stromu. A přesto každý týden zemřou při nehodách desítky lidí (asi schválně viď) a o „pomačkaném plechu“ ani nemluvím…
A že jsi zatím nic nezničil? Nezapomeň na Murphyho: „nešťastná níhoda dovede trpělivě vyčkávat na ten správný okamžik – okamžik, kdy dovede způsobit největší škodu.“
Neodsuzuj nikdy nikoho za lamerství, nikdo proti němu nejsme imunní… -
brigadnik (neregistrovaný)
chci ti eriku poděkovat – článků tohoto typu je pomálu.
ohledně diskuze usb vs parport: Řekl bych, že parport je pro začátečníka prostě nejpřístupnější – kdo si chce hrát, ať si ten usb chip koupí, má to hi-tech malý nožičky ;p Na osobních počítačích lpt mizí, ale není problém si koupit pci kartu (linux si navíc s těmito zařízeními dobře rozumí, mimochodem). Taky mě by zajímalo kolik různých amatérských zapojení vzniklo na parportu a kolik na usbčku. ?!?
malý bugreport :) Program parmixer mi po spuštění vyhodil segfault :není tam ošetřená situace, když uživatel nemá práva na zápis do 0×379, ale funguje a to je hlavní (teda ještě bych nějak nahradil ten polling, aby tomu nic nescházelo)
díky za články a těším se na další.
ČLÁNKY DO MAILU
