Názory k článku Paralelní port a rozhraní Centronics
-
dgrgd (neregistrovaný)Pro práci s jednotlivými piny na parallením portu s úspěchem používám http://parapin.sourceforge.net/.
-
Pavel TišnovskýZlatý podporovatelbtw, tady lze najít jeden z důvodů: http://www.fitnesoft.com/AlmostPerfect/
Je to názor insidera, který (to je nutné říct) asi nebyl zaměstnanci moc oblíben, ale spousta postřehů je dost zajímavá a pěkně ukazuje dobu, kdy se skutečně dalo s dobrým nápadem celosvětově prosadit na trhu s wordprocesory (třeba důvody pádu WordStaru jsou tam popsány dost trefně). -
Michal Kára (neregistrovaný)Moc pekne cteni. Podle toho co pise se duvodem padu nestal ani tak primo Microsoft, jako spis snaha "aby to byla zabava", takze:
1) Honili prilis mnoho zajicu najednou
2) Evidentne neperspektivni projekty nebyly odrezavany od zdroju
3) Nesoustredil se dostatek prostredku na "nudne" ale velmi potrebne ladeni Windows verze
4) Kdyz pak byl autor knihy odejit protoze moc "kazil zabavu", tak nikdo nezabranoval narustu nakladu
Castecne v tom byl i syndrom zakladatelu, kteri nemaji vhodne vlastnosti pro vedeni tak velke firmy (nechteji chodit do konfliktu), ale presto drzi vedeni dale. Na ten dojelo uz mnoho firem.
Dalsi problem bylo, ze v okamziku nastupu Windows meli DOS verzi s mnoha featurami, o ktere nechteli Windows verzi ochudit a vyvinout "plnou" Windows verzi bylo o dost casove narocnejsi, nez vyvinout nejaky "zakladni" text procesor (MS Word). -
PG (neregistrovaný)Moc rád bych se dozvěděl něco o redukcích - LPT na Centronix, USB na PS2 apod. Nеmyslím specilální článek, stačilo by vždycky u příslušného rozhraní uvést varianty a popsat, jak fungují. Nezdá se mi totiž, že by šlo jen o jinak propojené drátky.
Na druhé straně, redukce na myš a klávesnici (USB/PS2) je natolik kompaktní, že tam snad ani elektronika není...
Jinak opět parádní díl skvělého seriálu. Díky! -
mm (neregistrovaný)Existuje ještě jeden - as nejčistší způsob práce s LPT.
Standarní součástí distribuce jádra je modul ppdev.
Stačí tedy udělat modprobe ppdev a pak otevřít zařízení přes /dev/parport0, dev/parport1 atd...
Pochopitelně těm /dev/parportx můžeme přidělit práva nejen pro roota.
Vlastní práce pak spočívá v posílání příkazů přes ioctl() a read(), write()
Používají to např. prográmky jako třeba uisp pro STK-200 programátor mikrokontrolérů Atmel AVR. -
afk_cz (neregistrovaný)diky za skvely clanek
jen bych si dovolil pridat jeden zajimavy web, ktery uz jede spoustu let a jsou tam popsana zapojeni u vsemoznych kabelu: http://pinouts.ru -
fckr (neregistrovaný)O programovani paralelneho portu bol zaujimavy clanok aj na linuxos.sk - http://www.linuxos.sk/clanok/248/index.html
-
anonymníTo s tím signálem BUSY mne překvapilo. Tedy to, že se nastavuje při každém přeneseném byte. Vždy jsem měl za to, že se nastaví až v okamžiku, kdy má tiskárna plný buffer a spadne tehdy, až je možné posílat další data.
Před mnoha lety (kdy ještě nebyl přenos dat mezi Amiga/ST/PC a 8 bit Atari rutinní záležitostí) jsem vyrobil interface a napsal programy pro přenos dat do Atari (texty, nascanované obrázky apod.). Fungovalo to tak, že na straně Amiga/ST/PC se z osmibitových dat stala dvoubitová a ta se "vytiskla na tiskárně". Na straně Atari se to zachytávalo jedním joystickovým portem (dva bity data a pokud si dobře pamatuji, tak další dva bity byly ACK a BUSY, STROBE byla "spoušť"). S BUSY se ale nakonec určitě nijak neoperovalo a fungovalo to výborně (nemluvě o tom, že jsem tehdy neměl povědomost o potřebných časech signálů). -
Pavel TišnovskýZlatý podporovatelNebylo to spíš zapojeno na oba joystickové porty? Pokud si dobře pamatuju (je to strašně dávno :-)), tak se celý port buď choval jako vstupní nebo jako výstupní. I proto byla BT-100 (geniální to plašič myší) připojena na oba joystickové porty. Jinak dobrej nápad, posílat data z paralelu do joystickových portů, zatím jsem viděl jen složitější řešení, například PC2SIO.
-
Jiří Svoboda (neregistrovaný)SIO2PC bylo první řešení, které to moje hned zabilo. :-) Dnes už ovšem propaguji pouze SDrive (http://raster.infos.cz/atari/hw/sdrive/sdrive.htm), také z naší prostějovské kuchyně.
Port jsem použil právě určitě jen jeden, protože jsem od starého joystiku měl jen jeden kabel. I kdybych použil oba porty, nemohl bych posílat celých osm bitů, protože bych neměl volný bit na ACK (leda snad na data použít další FIRE).
Jinak se to jmenovalo PARJOY a vyšlo to ve FLOPu 31 (http://raster.infos.cz/atari/flop/), dnes už ale nestojí za to na to ani koukat.
Ohledně joyportů u Atari obecně, PIA 6520 měla geniální vlastnost, že se pro každý pin dalo nastavit individuálně, zda bude vstupní nebo výstupní, takže se každé "čtyři směry joysticku" daly používat libovolně. FIRE ale už bylo zapojené jinam, takže bylo vždy jen vstupní.
Celé porty (nebo půlporty u portu C) se přepínaly u příšery zvané 8255. -
Pavel TišnovskýZlatý podporovatelAha, díky za info! Opravdu jsem měl dojem, že šla přepínat vždy celá čtveřice pinů. FLOPy určitě někde mám v adresáři s emulátorem Atárka, tak se na to kdyžtak mrknu.
-
Kvakor (neregistrovaný)Pozor - ioperm() funguje jen pro porty z rozsahu ISA sbernice, tj. 0 ax 0x3ff (za to Linux nemuze, tak si to vymysleli v Intelu). Pokud je paralelni port na PCI karte, bude mit nejsips uplne jinou adresu (treba u mne je to 0xc800, zjistuju ho v /proc/bus/pci/devices) a je nutne namisto toho pouzit iopl(), ktere povoli pristup na vsechny I/O porty. Viz http://linux.die.net/man/2/iopl a http://linux.die.net/man/2/ioperm .
A kdysi byly paralelni porty i na "grafickych" kartach MDA a pozdeji na Herculesech, ty meli defaultni adresu 0x3bc, takze se s normalnim portem na I/O kartach (typicky na 0x378 nebo 0x278) nijak neovlivnovaly. A vetsinou mnohem vic vydrzeli ... -
Jet (neregistrovaný)pozor, jedna se o porty MENSI nez 0x400, ne vetsi
krome toho to neni ani vina Intelu, ani vina IBM, je to skutecne vina Linuxu, protoze v dobe kdy se navrhoval, porty nad 0x3ff se skutecne skoro nevyskytovaly (diky IBM). Vzhledem k tomu, ze ram bylo v te dobe nedostatek a kazdy process musi zdedit bitmapu povolenych portu, zvolila se velikost teto bitmapy podle v te dobe pouzitelnych portu.
Kazda bitmapa povolenych portu zabirala 128 bytes pro 0x400 portu, kdezto pro 64Ki portu by zabirala 8KiB. Je to pomerne velky rozdil. Dnes uz samozrejme neni 1 mega zadna mira, ale tento rozsah zustal z historickych duvodu stejny. -
BLEK. (neregistrovaný)Ono to hlavně nejde zvětšit proto, že změnění adresy této portové bitmapy je velmi pomalé (nahrátí nového TSS), přepnutí pomocí stránkování se autorům Linuxu nechce dělat a tak těch 128 bytů kopírují tam a zpátky při přepnutí procesu. A kdyby místo toho kopírovali 8Kb při každém přepnutí procesu, tak by to zpomalovalo.
-
Yokotashi (neregistrovaný)Kdyz se na data a ridici signaly da 12 LED, jsou z toho pekne binarni hodiny - 6 LED na minuty, 5 na hodiny a jedna blika po sekunde ... nekde bych jeste nasel zdrojak, ale je trivialni.
Nebo se tam daji pred dekoder 4->7 propojit 3 sedmisegmentovky.
Tech 5 vstupu jde nekolika multiplexery (z 7400) snadno rozsirit na 8, kdyz se to ovlada jednim z tech ridicich dratu ...
A na nekterych portech pry (to jsem nedelal) jsou ty ridici pouzit jako vstupy - staci je nastavit na 1 a uzemnovat (ale doporucuju okolo toho googlit, jestli si odpalite port, tak za to nemuzu).
Docela by me zajimalo nejake zapojeni, ktere komunikuje s ECP portem ... -
Pavel TišnovskýZlatý podporovatelPresne tak, jinak dnes prakticky kazdy paralelni port umi prepinat datove piny na vstupni (vsechny naraz), vhodne se to da kombinovat (tj. dva latche ovladane treba pres Strobe) a udelat uplnych 8+4 bity vystup a 8+5 bitu vstup. Taky jsem videl, ze nekdo vysunoval data po jednom datovem vodici, nasouval je zpatky po jednom vstupu a simuloval tak SCI (pouziva ho treba Motorola 68HC11). Ale je zde problem - zatezuje to strasne CPU, protoze se musi aktivne vsechny piny (=registry) sledovat.
