So, in other words... I can have the software tell the port to poll for = data ? ----- Original Message -----=20 From: "James Lee Williams" To: Sent: Sunday, June 03, 2001 5:30 AM Subject: Re: [PICLIST] [PIC] ECP paralell port interfacing :-) Pin 15(nError,nFault) is user defineable for ECP and can be used to indicate that data is available for the host. The host can then periodically check this pin (Status3). If programming in windows environment, the you use DeviceIoControl to get access to this bit. -----Original Message----- From: Kyrre Aalerud [mailto:kreature@C2I.NET] Sent: Saturday, June 02, 2001 10:04 PM To: PICLIST@MITVMA.MIT.EDU Subject: Re: [PIC] ECP paralell port interfacing :-) Arrgh! In my eagerness to get this to work, I also forgot that I need 2 pins for the temp measuring too :-((( Enyone have some code that works ? I guess I can live with serial if nothing else :-( BTW: I want to run the PIC at either 4 or 10 MHz... KreAture ----- Original Message -----=20 From: "Kyrre Aalerud" To: Sent: Sunday, June 03, 2001 3:55 AM Subject: [PICLIST] [PIC] ECP paralell port interfacing :-) Hi, I am currently working on a ECP-paralell interface routine. This simply because I am tired of my 16F84 based thermometer having comm problems on serial. I find that I need the whole B-register as the data-channels. Then I can use the five A-ports as follows: HostAck PORTA, 0 ; RA0 is HostAck input (pin 14) nReverseRequest PORTA, 1 ; RA1 is nReverseRequest input (pin 16) nAckReverse PORTA, 2 ; RA2 is nAckReverse output (pin 12) =3D HIGH PeriphAck PORTA, 3 ; RA3 is PeriphAck output (pin 11) =3D LOW PeriphClk PORTA, 4 ; RA4 is PeriphClk output (pin 10) =3D HIGH PeriphRequest output (pin 15) Where do i put this then :-( I was thinking of harw-wiring it to low, but that might be a mistake. I don't want the comp to poll for a value before I have measured one... The measuring takes too long to be done on a hardware request level. Any genious ideas ? Here is a "pseudo" of the routine: --------------------------------------------- PeriphRequest =3D> LOW (Causes the comp to sense that there might be data for it) wait for nReverseRequest =3D> LOW (Waiting for the comp to poll = the data) ack by nAckReverse =3D> LOW (Ack the poll) Place data (duh!) PeriphAck =3D> HIGH (Tell host that data is OK) PeriphClk =3D> LOW (Ready the clock for host) wait for HostAck =3D> HIGH (Wait for host ack) PeriphClk =3D> HIGH (Clock data in on host) wait for HostAck =3D> LOW (Wait for host ack) PeriphRequest =3D> HIGH (Stop reverse request) --------------------------------------------- Nice isn't it ? The good thing about this is that it will work as long as it uses a fast enough clock. It will let one transfer data at a rather nice rate too. (1 MB/sec is not a problem if needed) Hope to get some nice ideas :-) KreAture -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.