|
|
Oldal: 1 / 1
|
[ 32 hozzászólás ] |
|
Szerző |
Üzenet |
T68m
a fórum lelke
Csatlakozott: szer. márc. 24, 2004 13:43 Hozzászólások: 12729 Tartózkodási hely: FLF
|
up!
érdekesség: az USB->LPT átalakító (fentebb feltételezésemmel ellentétben) nem várja össze a byteokat, és egy-egy byte-ot nagyon lassan küld ki. Így, ha byte-onként írunk (windowsban), akkor az lassú lehet, célszerű összevárni a szükséges karaktereket és azokat egyszerre kiküldeni.
Mivel a uC amúgy is kellett nekem az LCD enabled lábának megfelelő vezérléséhez, így annak a programjába a megfelelő várakoztatást is beraktam. Tehát a pc programom egyszerre küldi ki az összes kiírandó karaktert és vezérlő byteot. A uC az acknowledge jelet az LCD sebességének megfelelően adagolja vissza az átalakítónak, továbbá az LCD enabled lábát is vezérli. Az eredmény: jó és hihetetlenül gyors lett!
|
pén. nov. 28, 2008 15:27 |
|
|
T68m
a fórum lelke
Csatlakozott: szer. márc. 24, 2004 13:43 Hozzászólások: 12729 Tartózkodási hely: FLF
|
UP! arra gondoltam, hogy a strobe jelet ne input lábbal detektáljam, hanem a timer0-val. És bejött! A timer ugrik, ha megkapja a strobe jelet, tehát a fentebb említett hardware adottság (a lábak magasan, ha nincs jel) kihasználása nem szükséges!
(a strobe jelet - mint fentebb írtam - közvetlenül lábbal nem sikerült detektálnom, mivel túl rövid idejű ehhez. De a timer0-át ugrasztja, és ez már elég a feladathoz)
|
kedd nov. 25, 2008 7:42 |
|
|
T68m
a fórum lelke
Csatlakozott: szer. márc. 24, 2004 13:43 Hozzászólások: 12729 Tartózkodási hely: FLF
|
MotoHacker írta: Nincs mit! Ha kész lesz ez az USB illesztõ+program, publikálod majd -akár zárt körben- ?
Most akkor mire is gondolsz? Egy olyan kapcsolásra, ami közvetlenül az USB-ről megy és meghajtja a hd44780-ast?
Az a baj ezzel, hogy az USB-t más okból is rühellem. Pl. abból, hogy nem képez fizikai eszközt, így Windows alá még meghajtó programot is kell írni ahhoz, hogy használni lehessen. Szemben mondjuk a soros vagy párhuzamos porttal, amit egyszerűen megnyitok, mint egy file-t is kiküldöm rajta az adatokat.
|
vas. nov. 23, 2008 18:02 |
|
|
T68m
a fórum lelke
Csatlakozott: szer. márc. 24, 2004 13:43 Hozzászólások: 12729 Tartózkodási hely: FLF
|
na, ja. Egyébként sikerült!!!
Észre se vettem, mikor sikerült, mert olyan nagyra állítottam az időzítést, hogy amikor az LCD-re néztem, az még inicializálódott. Majd felálltam valamiért, s mikor visszanéztem épp kezdett bejönni a kiírás. Ezután hangolgattam egy kicsit az időzítéseket, most már elég gyors. Igaza volt MH-nak abban, hogy elég rövid időre ráadni az enabledet, utána kell várni, a végrehajtásra. (Ez valamiért nem így van, ha rendes lpt portról hajtom meg. Ott várnom kell mikor kirakom az enabledet, majd várnom kell akkor is, amikor leveszem)
Na, a gond a STROBE-al van. Szal, egyelőre úgy tünik, hogy tényleg csak 1us impulzus jön rajta és a 4MHz-es PIC ezt nem veszi észre. Mivel az LCD-t (lábhiány miatt) amúgy is 4bitesen hajtom (és kettő bit a vezérlés), így maradék két lábat használom a strobe helyett. Valamiért az illesztő magasan tartja a vonalat (uA-ek mellett), ha nincs adat, és ha van, akkor arra áll be, a 2.-3.-as lábak (mivel ezek nem használtak) 0-ra.
Tehát a megoldás NEM ÁLTALÁNOS, mivel nem a strobe-ot használom, hanem a nem használt biteket, amik ennél az USB->parallel átalakítónál (valamiért) használton kívül (kis áram mellett) magas szinten vannak.
itt a kód:
Kód: ; configuration word for p10f200-206 ******************************** ; CODE protection off, ; Watch Dog Timer disabled, ; MCLReset disabled, pin3 is IO port ; __config b'01000' ; ; configuration word for p12f508-509 ******************************** ; CODE protection off, ; Watch Dog Timer disabled, ; MCLReset disabled, pin3 is IO port ; Internal RC oscillator/RB4 function on RB4/OSC2/CLKOUT pin __config b'01010' ; ezzel a beállítással a p10f200-206 is elmegy? ; ior equ 6; gpio register wcr equ 10;wait cointer register str equ 2; strobe in enb equ 3; enabled in org 0 ; az égetőprogram által számolt órajel pontosítás betöltése movwf 5;osccal ; komparátor letiltása movlw 0 movwf 7;cmcon0 ; timer0 source internal clock, not pin, prescaler assigned to timer0 movlw b'11010111' option ; 0-1 pin output, 2-3 pin input movlw b'1100' tris ior ; a bsf és bcf utasításokat nem szabad használni, mert azok nem tényleges bit, hanem ; valójában byte műveletek, amihez a lábak állapota alapján (amit a külső hardware ; elállíthat) rendeli (így esetenként tévesen) a maradék hét bitet ; acknowledge, ebabled '1' movlw b'10' movwf ior ; loop btfsc ior, str goto loop ; btfss ior, enb goto othr ; movlw b'11' movwf ior nop movlw b'10' movwf ior ; othr movlw b'00' movwf ior nop movlw b'10' movwf ior ; movlw 1 call wait goto loop ; wait movwf wcr wc1 decfsz wcr, 1 goto wc1 retlw 0 end
a kihagyás (othr) az van benne, mert ugyanaz a program hajtja meg, ami normál lpt1 port esetén tenné. Ott viszont minden második byte csak az enbledet kapcsolgatja.
|
csüt. nov. 13, 2008 1:37 |
|
|
MotoHacker
gyémánt tag
Csatlakozott: pén. jan. 28, 2005 20:39 Hozzászólások: 3683 Tartózkodási hely: Bp
|
Tuti, hogy ez nem a printerportra vonatkozik, ez valami tökmás... sorosnak tűnik, mert egy adatvonal van. (és annak az állapotával is "trükköznek", busz-állapotokat jeleznek, stb)
|
szer. nov. 12, 2008 19:29 |
|
|
T68m
a fórum lelke
Csatlakozott: szer. márc. 24, 2004 13:43 Hozzászólások: 12729 Tartózkodási hely: FLF
|
na, kartácsak, még ennél is összetettebb az stb-ack kezelése! Ugyanis MH által bemásoltan túl, van egy start rész is (legalábbis eszerint):
http://www.daisy-laser.com/products/CD/ ... 01_dsa.pdf
The transmitter clears the data line to let the other side know it wants to transmit some data. Then it is
waiting until low level on the ACK line is received as an answer from the receiver which recognised the
data transfer request and is ready for it.
Then the transmitter sets the DATA line high and waits for a high level on the ACK line a high level on
the ACK line means the end of the starting synchronisation and both transmitter and receiver are ready for
the data transfer
pontosan az lpt portra nem találtam leírást.
|
szer. nov. 12, 2008 13:55 |
|
|
killbill
ezüst tag
Csatlakozott: szer. jún. 18, 2008 13:41 Hozzászólások: 94 Tartózkodási hely: Százhalombatta
|
T68m írta: MH: A kijelző jóval lassabb, mint a printer pufferbe olvasása, rohadt nagy, akár ms-os időzítéseket kíván! (parancstól függ) Igazándiból nem kell addig rajta tartani az enabledet, de az 1us vajon (amíg az STB tart) elég neki? Gondoltal mar arra, hogy megnezd a hd44780 leirasaban? Mert abban eleg egyertelmuen le van irva. Idézet: Hajlok arra, hogy ezt a feladatot is egy 150Ft-os, 6lábú alkatrésszel lehet a legegyszerűbben megoldani. Hogy az belül a legbonyolultabb? Arról már nem tehetek...
Foleg, ha ugy akarod megcsinalni, hogy becsulettel kezelje a BUSY es ACK jeleket is, hogy barmilyen printer porton (nativ vagy USB-s) mukodjon.
|
szer. nov. 05, 2008 15:41 |
|
|
MotoHacker
gyémánt tag
Csatlakozott: pén. jan. 28, 2005 20:39 Hozzászólások: 3683 Tartózkodási hely: Bp
|
A kijelző nem a paracs vagy adat latch-ba beolvasásához, hanem két adat közt a "végrehajtáshoz" kíván ekkora szünetet!
Tehát azt kell megvizsgálni, ki lehet küldeni egy pár byte-ot is, (azután pihi, kijelző dolgozik) vagy mindig "összevár" az USB egy csomagnyit...
Mert akkor tényleg reménytelen garantálni, hogy pont akkor legyen "szünet", amikor kell.
|
szer. nov. 05, 2008 11:01 |
|
|
T68m
a fórum lelke
Csatlakozott: szer. márc. 24, 2004 13:43 Hozzászólások: 12729 Tartózkodási hely: FLF
|
MH: A kijelző jóval lassabb, mint a printer pufferbe olvasása, rohadt nagy, akár ms-os időzítéseket kíván! (parancstól függ) Igazándiból nem kell addig rajta tartani az enabledet, de az 1us vajon (amíg az STB tart) elég neki?
Hajlok arra, hogy ezt a feladatot is egy 150Ft-os, 6lábú alkatrésszel lehet a legegyszerűbben megoldani. Hogy az belül a legbonyolultabb? Arról már nem tehetek...
|
szer. nov. 05, 2008 9:41 |
|
|
MotoHacker
gyémánt tag
Csatlakozott: pén. jan. 28, 2005 20:39 Hozzászólások: 3683 Tartózkodási hely: Bp
|
Szerintem eltúlzod, a strobe nem lehet úgy alacsony, hogy odakint nincs érvényes adat.
Tehát,ha egy darab dróttal összekötöd az enable-val a dolog működni fog.
A strobe nemtudom, hogy impulzust ad, vagy "úgymarad" miután kiment az adat, (ha az adat nem marad kint, akkor a strobe sem maradhat alacsony) de szerintem mindegy, a kijelző nem lehet lassabb mint a nyomtató, 5us bőven elég neki beírni az adatot.
Ezután már csak a késleltetett ACK-ot kell megoldani, hogy adja a következő byte-ot automatikusan.
Ezt egy akármilyen késleltetés "elintézi".
Igen, erre már utaltam az előbbi hsz-ben is, hogy nem tudod portbitről hajtani az enable-t, itt ez nem fog menni, új programot kell írni.
|
szer. nov. 05, 2008 8:52 |
|
|
watt
gyémánt tag
Csatlakozott: szer. nov. 01, 2006 14:00 Hozzászólások: 3559 Tartózkodási hely: Régi nick .watt Hozzászólások: 3402
|
Esetleg egy Latch IC használata?
|
szer. nov. 05, 2008 5:36 |
|
|
T68m
a fórum lelke
Csatlakozott: szer. márc. 24, 2004 13:43 Hozzászólások: 12729 Tartózkodási hely: FLF
|
ja, tehát összefoglalva, mivel a byte között a kimenet lebegtetve van, ezért nem működik az, hogy kiküldök egy byte-ot, ami meghajtja az enabled lábat is, 0 enableddel, majd kiküldöm ugyanezt a byte-ot, 1 enableddel.
Így marad az, hogy a STB hatására be kell állítanom az enabledet, tartani, majd elengedni, ezután meg kell húzni az ACK-t, tartani, elengedni. Egyszerű, egy uC-nek!
|
kedd nov. 04, 2008 23:39 |
|
|
MotoHacker
gyémánt tag
Csatlakozott: pén. jan. 28, 2005 20:39 Hozzászólások: 3683 Tartózkodási hely: Bp
|
Az ack a nyugtázás, a strobe tölti a printerbe az adatot.
Ha a kijlező enable lábát a strobe vezérli, és (kicsit késleltetve?) az ACK-ot is meghúzza, úgy szerintem működnie kell, szépen kimennek az adatok, és ha elég gyors, akkor át is veszi őket a kijlező.
Tudom, hogy a normál LPT-nél lehet máshogy is, ott az engedélyező jelet is egy portbittel vezérled, de ez itt szerintem nem fog menni, vagy csak nagyon bonyolult segédlogikával.
|
kedd nov. 04, 2008 20:41 |
|
|
T68m
a fórum lelke
Csatlakozott: szer. márc. 24, 2004 13:43 Hozzászólások: 12729 Tartózkodási hely: FLF
|
foglaljuk egy kicsit össze:
normál lpt porton megjelenik az az adat, amit a programból küldök neki, és ott is marad, amíg a következő byte felül nem írja. Normál lpt porton elég csak a busy és paper out lábakat földre kötni, ilyenkor a Windows úgy ézékeli, hogy van rajta eszköz és a program által küldötteket rögtön kiteszi a kimenetre.
Ezt kihasználva a hd44780-as kijezlőt (felső) négy adatlábát rákötöttem (felső) négy kimeneti lábra, két vezérlő vezetékét pedig a legalsó bitekre, az 0. és az 1.-re. A meghajtás négybites módban történik, ahol a kiküldött byte felső része az adat, az alsó része pedig vezérel.
Na, ez nem megy az usb-parallel átalakítón. Először nem akartak kimenni az adatok (nem érzékelt eszközt a rendszer), ezért nyitottam ezt a topicot. Majd rájöttem, hogy a strobe-acknowledge lábakat összekötve kimennek az adatok, csak épp nem úgy, ahogy akarom. Először arra gondoltam, hogy pufferel az átalakító (és ezért elcsúszik az időzítés), majd azt mértem, hogy a kiküldött adat nem marad kint. Tehát amint megkapja az átalakító az ACK-t, rögtön leveszi a jelet a lábairól.
|
kedd nov. 04, 2008 19:54 |
|
|
killbill
ezüst tag
Csatlakozott: szer. jún. 18, 2008 13:41 Hozzászólások: 94 Tartózkodási hely: Százhalombatta
|
Hi!
MotoHacker írta: Én inkább abból indulnék ki, van a kijelzőnek egy E lába, oda kell impulzus, amitől az adatot beolvassa. Ok, de az a baj, hogy az illeszto elveszi az adatvezetekekrol az adatot, amikor megkapja az ACK-ot (ha jol ertem). Ebben az esetben az E pulzust hw-esen kell generalni, es csak utana adni az ACK-t, hogy az adat es az RS vegig stabil legyen. Vagy tarolni kell az adatot egy 6..8 bites taroloval. Egyszerubb az E-t eloallitani az printer STRB jelbol, es utana visszaadni az ACK-t. Idézet: Mivel 4bites módban használod, marad bit az RS jelre is, (amit igazából megoldhattak volna jobban is, de ez van) Ezt hogy erted? Ez egy Motorola busz, cimmel, adattal, WR es E jellel. Plusz van a nCS. Amikor 100 eve ezt a chip-et terveztek, akkor meg bus-on kommunikaltak a processzorok a periferiakkal, nem port labakon keresztul.... Idézet: RW nem érdekes, fixen L, olvasni úgysem lehet, a dolog egyirányú.
Ez biztos? Mondjuk jelen esetben nincs ra szukseg, de a parhuzamos printer port tud ketiranyu is lenni. Gondolom, az USB-s is.
Udv,
Andor
|
kedd nov. 04, 2008 18:02 |
|
|
MotoHacker
gyémánt tag
Csatlakozott: pén. jan. 28, 2005 20:39 Hozzászólások: 3683 Tartózkodási hely: Bp
|
őőő..nem látom át egészen, de ha egyszer nincs ACK, mitől kerül ki a portra az új, az ACK-ot "utasító" kombináció? Nekem ez 22-es csapdájának tűnik, aztán lehet, hogy nem gondoltam át eléggé.
Én inkább abból indulnék ki, van a kijelzőnek egy E lába, oda kell impulzus, amitől az adatot beolvassa.
Mivel 4bites módban használod, marad bit az RS jelre is, (amit igazából megoldhattak volna jobban is, de ez van)
RW nem érdekes, fixen L, olvasni úgysem lehet, a dolog egyirányú.
|
kedd nov. 04, 2008 17:08 |
|
|
T68m
a fórum lelke
Csatlakozott: szer. márc. 24, 2004 13:43 Hozzászólások: 12729 Tartózkodási hely: FLF
|
még nem tudtam eldönteni, hogy pufferel-e vagy sem. Az viszont határozottan úgy tünik, hogy miután megkapja az ACK jelet, nem hagyja kint tovább a kiírt értéket. Tehát mi lenne, ha a szabadon maradó két lábat (2. és 3. bitek) arra használnám, hogy késleltetve előállítsam az ACK-t?
|
kedd nov. 04, 2008 16:17 |
|
|
MotoHacker
gyémánt tag
Csatlakozott: pén. jan. 28, 2005 20:39 Hozzászólások: 3683 Tartózkodási hely: Bp
|
De, én tudtam, minekután a sima printerportost is figyelemmel követtem
|
kedd nov. 04, 2008 8:47 |
|
|
watt
gyémánt tag
Csatlakozott: szer. nov. 01, 2006 14:00 Hozzászólások: 3559 Tartózkodási hely: Régi nick .watt Hozzászólások: 3402
|
Igazából nem tudtuk mit szeretnél építeni. Akkor viszont ha impulzus kell szerintem is egy TTL dual monostabil a megoldás.
|
kedd nov. 04, 2008 5:43 |
|
|
T68m
a fórum lelke
Csatlakozott: szer. márc. 24, 2004 13:43 Hozzászólások: 12729 Tartózkodási hely: FLF
|
MH jól látja a lényeget: ha már uC, akkor az veheti az adatokat közvetlenül az USB-ről, vagy soros portról (ami szintén jöhet USB-ről). Tehát nem megoldás a uC, mert azzal pont az a lényeg veszik el, hogy hogyan hajtsuk meg a hd44780-as kijelzőt (mert erről van szó) egyszerűen, az LPT portról. Normál lpt esetén egyszerű a dolog, csak össze kell kötni a megfelelő lábakat, a többi a vezérlés dolga. Normál lpt porta ha kiküldök egy byte-ot, akkor az kimegy (nem vár össze néhányat) és úgymarad.
|
kedd nov. 04, 2008 4:30 |
|
|
killbill
ezüst tag
Csatlakozott: szer. jún. 18, 2008 13:41 Hozzászólások: 94 Tartózkodási hely: Százhalombatta
|
Szepjonapot!
MotoHacker írta: Valami hót primitív RC tag nem késleltet eleget, hogy a kijelző képes legyen feldolgozni a máskülönben hirtelen kizúduló adatokat?
Kijelzo? Ez honnan derul ki? Idézet: Mondjuk az ultrapimfli megoldás hátránya, hogy érzékeny még az elektromos paraméterekre is, egy másik verziós printerport illesztővel tökmáshogy fog viselkedni Mellesleg a primitiv megoldassal eppen az a baj, es ebbe a HC123-mas megoldas is beletartozik, hogy amig nem pont ugy viselkedik az aramkorod, mint egy printer (hasznalja a BUSY es ACK jelet is), addig nem lehetsz benne biztos, hogy egy masik USB->parallel illesztovel mukodni fog. Ha becsulettel leszimulalod a printert, akkor valodi LPT porton is jo lesz, meg USB-ssel is. Viszont kivancsi lennek, hogy ha adott egy HW, ami fogadni tudja a jeleket a printer port felol, akkor miert nem az csinalja az ACK es BUSY eloallitasat? Miert kell ezt a 25-os csatlakozo hazaba tenni?
Udv,
Andor
|
hétf. nov. 03, 2008 18:08 |
|
|
MotoHacker
gyémánt tag
Csatlakozott: pén. jan. 28, 2005 20:39 Hozzászólások: 3683 Tartózkodási hely: Bp
|
Ennyi erővel egy USB-s PIC elintézné az egész miskulanciát, szerintem ez tévút, pont az egyszerű "sarki boltból 10 perc alatt" utánépíthetőséget dobjuk el felporgramozott PIC-et használva egy pimfli késletetőnek.
Az USB-s IC-nek muszáj pufferelni, mivel az USB maga ilyen, csomagokat küldenek, azt meg nem csinálja a windows sosem, hogy egy byte-ot küldjön csomagonként, tehát a dolog alapvető természetéből következik a probléma.
Valami hót primitív RC tag nem késleltet eleget, hogy a kijelző képes legyen feldolgozni a máskülönben hirtelen kizúduló adatokat?
Mondjuk az ultrapimfli megoldás hátránya, hogy érzékeny még az elektromos paraméterekre is, egy másik verziós printerport illesztővel tökmáshogy fog viselkedni
|
hétf. nov. 03, 2008 17:27 |
|
|
watt
gyémánt tag
Csatlakozott: szer. nov. 01, 2006 14:00 Hozzászólások: 3559 Tartózkodási hely: Régi nick .watt Hozzászólások: 3402
|
Egyszerűbbnek nem egyszerűbb, sőt, viszont kisebb és elegánsabb.
|
hétf. nov. 03, 2008 17:20 |
|
|
killbill
ezüst tag
Csatlakozott: szer. jún. 18, 2008 13:41 Hozzászólások: 94 Tartózkodási hely: Százhalombatta
|
Hello!
T68m írta: Most azon gondolkozom, hogy a strobe impulzus után hogyan tudnám legegyszerűbben (ami elfér a 25pines csatlakozó házában*) késleltetni azt 1-10msig az acknowledge számára.
Elsore egy 74hc123 jut az eszembe. Ez ket monostabil. Az egyik idozit a strobe utan kivant ideig (1..10ms) majd inditja a masodikat, ami eloallitja az ACK impulzust. Csak tapot kell neki adni valahogyan. A 74HC sorozat 2-6V-ig megy, talan valamelyik printer vezerlo jelrol meg is lehetne taplalni. Persze sokak szerint egy 8 labu pic egyszerubb megoldas lenne... talan az is.
Udv,
Andor
|
hétf. nov. 03, 2008 14:58 |
|
|
T68m
a fórum lelke
Csatlakozott: szer. márc. 24, 2004 13:43 Hozzászólások: 12729 Tartózkodási hely: FLF
|
MotoHacker írta: Nincs mit! Ha kész lesz ez az USB illesztõ+program, publikálod majd -akár zárt körben- ?
persze. Tegnap odáig jutottam el, hogy az adat kimegy. Azonban úgy tünik ez a xar is puffereli az adatokat, azaz hiába várakoztatom a programot byte-onként megfelelő ideig, amíg a hardware feldolgozná azt.
Most azon gondolkozom, hogy a strobe impulzus után hogyan tudnám legegyszerűbben (ami elfér a 25pines csatlakozó házában*) késleltetni azt 1-10msig az acknowledge számára.
* hogy ne kelljen a strobe és az acknowledge lábakat sehova se vezetni, hanem helyben el legyenek intézve.
|
hétf. nov. 03, 2008 11:34 |
|
|
MotoHacker
gyémánt tag
Csatlakozott: pén. jan. 28, 2005 20:39 Hozzászólások: 3683 Tartózkodási hely: Bp
|
Nincs mit! Ha kész lesz ez az USB illesztő+program, publikálod majd -akár zárt körben- ?
|
hétf. nov. 03, 2008 8:39 |
|
|
T68m
a fórum lelke
Csatlakozott: szer. márc. 24, 2004 13:43 Hozzászólások: 12729 Tartózkodási hely: FLF
|
sima rémtörténet:
persze, összekötöttem a strobe-t az acknowledgevel, MIUTÁN már kiküldtem az adatot. EZUTÁN, persze, hogy nem történt semmi, hisz az impulzus már kiment, mire én tesztből összeérintettem a vezetéket. fix-en beforrasztva működik. Köszi, amit bemásoltál az is hasznos!
|
hétf. nov. 03, 2008 2:27 |
|
|
MotoHacker
gyémánt tag
Csatlakozott: pén. jan. 28, 2005 20:39 Hozzászólások: 3683 Tartózkodási hely: Bp
|
Azért volna még itt mit átnézni:
Kód: 1, with ground on 19 STROBE out : normally high, pulsed low for about 1µs to clock the data being output into the printer. 2 2, with ground on 20 DATA 0 out : bit 0 of the ASCII data being output to the printer. 3 3, with ground on 21 DATA 1 out : bit 1 of the ASCII data being output to the printer. 4 4, with ground on 22 DATA 2 out : bit 2 of the ASCII data being output to the printer. 5 5, with ground on 23 DATA 3 out : bit 3 of the ASCII data being output to the printer. 6 6, with ground on 24 DATA 4 out : bit 4 of the ASCII data being output to the printer. 7 7, with ground on 25 DATA 5 out : bit 5 of the ASCII data being output to the printer. 8 8, with ground on 26 DATA 6 out : bit 6 of the ASCII data being output to the printer. 9 9, with ground on 27 DATA 7 out : bit 7 of the ASCII data being output to the printer. 10 10, with ground on 28 ACK in : normally high, pulsed low for about 5µs by the printer to acknowledge it has received and processed the last data byte. 11 11, with ground on 29 BUSY in : normally low, the printer takes this high when it cannot receive data (for example it is initialising, or is processing the last data byte received). 12 12, with ground on 30 PE in : normally low, the printer takes this high when it detects paper has run out. 13 13 SLCT in : the printer takes this high when it is selected (ie. on line). 14 14 AUTOFD out : for the XT computer, if low the printer should line-feed after each line has been printed. 15 32, with ground on 15 ERROR in : normally high, the printer takes this low if it detects an error. 16 31, with ground on 14 INIT out : normally high, taking this low for about 50µs then returning it high will initialise (reset) the printer. 17 36 SLCTIN out : when taken low by the computer, the printer is selected.
Én kapásból arra gondolnék, nem adja ki az adatot, amíg szabályos 5uS impulzust nem kap az előzőre...
Esetleg a select-in nincsen felhúzva? CMOS bemenet ugye furán viselkedik, valami tökmást piszkálsz, aztán közben véletlenül H-nak érzi..?
|
vas. nov. 02, 2008 22:15 |
|
|
watt
gyémánt tag
Csatlakozott: szer. nov. 01, 2006 14:00 Hozzászólások: 3559 Tartózkodási hely: Régi nick .watt Hozzászólások: 3402
|
Meg kéne tudni, hogy egy printer miként jelzi, hogy ott van.
|
vas. nov. 02, 2008 20:10 |
|
|
T68m
a fórum lelke
Csatlakozott: szer. márc. 24, 2004 13:43 Hozzászólások: 12729 Tartózkodási hely: FLF
|
oké, abban igazad van, hogy nem sok eszköz meghajtására jó. De addig el se tudom dönteni, hogy nekem jó-e, amíg nem hajlandó kiküldeni az adatot, mert nem érzékeli, hogy eszköz (printer) lenne rajta!
|
vas. nov. 02, 2008 20:06 |
|
|
MotoHacker
gyémánt tag
Csatlakozott: pén. jan. 28, 2005 20:39 Hozzászólások: 3683 Tartózkodási hely: Bp
|
Szerintem itt az lesz a bukás, minden USB-s printerport más, végülis egy félig hardveres emulációról van szó, ahol csak arra figyelnek, a legtöbb hagyományos printerrel működjön.
Más printerportos cuccok (pl epromégetők) szintén nem működnek ezekkel.
|
vas. nov. 02, 2008 19:31 |
|
|
T68m
a fórum lelke
Csatlakozott: szer. márc. 24, 2004 13:43 Hozzászólások: 12729 Tartózkodási hely: FLF
|
USB-s nullprint adapter
Normál parallel (lpt) porton ha a busy és a paper out lábakat lekötöm a földre, akkor a Windows úgy veszi, mintha printer lenne rajta, és az adatok kimennek. USB -> parallel porton ez nem elég, az acknowledge lábhoz kell hozzáérnem párszor, hogy kimenjen az adat. Viszont ha fixen földhöz, táphoz vagy a strobe lábhoz kötöm az acknowledge-t az nem segít.
Lenne valakinek tippje, hogy hogyan lehet nullprinter csinálni az USB -> parallel port végére?
|
vas. nov. 02, 2008 17:51 |
|
|
|
Oldal: 1 / 1
|
[ 32 hozzászólás ] |
|
Ki van itt |
Jelenlévő fórumozók: nincs regisztrált felhasználó valamint 28 vendég |
|
Nem nyithatsz témákat ebben a fórumban. Nem válaszolhatsz egy témára ebben a fórumban. Nem szerkesztheted a hozzászólásaidat ebben a fórumban. Nem törölheted a hozzászólásaidat ebben a fórumban.
|
|
|