Re: Timing in Synch Comm.

> Many devices, even simple DACs and ADCs have time-out circuits in there

>> and when SPICLK hasn't come for a certain period of time during a >> transmission they will abort for the affected data set. > > Actually I'm trying to do it any synch communications. SPI, I2C, and > ICSP will be some of the protocols I'll try and implement. Kinda sucks > that there is at time out and since SPI doesn't have an acknowledgement > it makes it even works ;/

I believe the OP (that's you, Jon. ;-) ) has some confusion about what "synchronous comm" means. Or either I have.

The way I understood it, "sync" means that the receiver provides its own clock, and it gets sync'ed to the master by some scheme.

What you're talking about, driving something from the parallel port, is simply clocked. If you have control over the data and clock, and know how the destination device behaves when it receives them, then just do it; if your receivers are static, they shouldn't care about latency, as long as the signals get there in the right order.

Good Luck! Rich

Reply to
Rich Grise
Loading thread data ...

Oh, I have no idea. I could be misusing the term then. I do see what you mean though. I'm not sure though.

Yeah, thats what I thought but since I'm trying to do it in general I do not know how all devices will behave. I'm just going to assume thats how it works though so I can get something done and worry about any specific devices later.

Thanks, Jon

Reply to
Jon Slaughter

IMO the only way to do it is to use the received data transitions to sync a clock at 2f and use the "recovered" clock to sample the data at it's midpoint. Even if each terminal is synchronized by a master clock traceable to a stratum 3 or better, data detection should be done using the recovered timing.

Reply to
Don Bowey

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.