Timing in Synch Comm.

[Jon Slaughter]

How critical is keeping the timing relatively stable in synchronous
communications? Obviously the slave is synched to the master's clock but is
there ever any problems if the clock timing is extremely unstable? Say
varying up to 10% on average but even peaking to 100% or more in rare
circumstances.

I'm writing a windows app which sends data to the parallel port but because
its pre-emptive there can be extreme latency in the timing. The data is
always synched with the clock so there is no issue with that but just of the
clock's frequency varying a great deal. I imagine since its synchronous
comm. that it should matter but just wondering if there are instances it
could?

Lets say, for example, that its a clock at 1Mhz but then stops completely
for several ms. Could this cause any problem with any device?

I know its the nature of synchronous devices only to send/recv data on a
clock transition and it would seem that frequency variations wouldn't matter
but I just want to be sure that its not going to be an issue.

Thanks,
Jon

 

[Vladimir Vassilevsky]

How critical is keeping the timing relatively stable in synchronous
communications? Obviously the slave is synched to the master's clock but is
there ever any problems if the clock timing is extremely unstable? Say
varying up to 10% on average but even peaking to 100% or more in rare
circumstances.

I'm writing a windows app which sends data to the parallel port but because
its pre-emptive there can be extreme latency in the timing. The data is
always synched with the clock so there is no issue with that but just of the
clock's frequency varying a great deal. I imagine since its synchronous
comm. that it should matter but just wondering if there are instances it
could?

Lets say, for example, that its a clock at 1Mhz but then stops completely
for several ms. Could this cause any problem with any device?

Yes, it can cause problems in some cases.

AVR Mega644 is indeed sensitive to the SPI clock irregularities while
being programmed. It causes the programming to fail. I suppose the other
new AVRs are sensitive to this, too. The older AVRs don't have this
problem; you can interrupt the process at any moment for any long time.

I know its the nature of synchronous devices only to send/recv data on a
clock transition and it would seem that frequency variations wouldn't matter
but I just want to be sure that its not going to be an issue.

This can be the issue - it is a fact. We can only speculate why it
happens; perhaps, the internal state machines may have a timeout
protection or something. I didn't believe it before I encountered that
problem myself.



Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

 

[Joerg]

Yes, it can cause problems in some cases.

AVR Mega644 is indeed sensitive to the SPI clock irregularities while
being programmed. It causes the programming to fail. I suppose the other
new AVRs are sensitive to this, too. The older AVRs don't have this
problem; you can interrupt the process at any moment for any long time.




This can be the issue - it is a fact. We can only speculate why it
happens; perhaps, the internal state machines may have a timeout
protection or something. I didn't believe it before I encountered that
problem myself.

I believe the OP wasn't talking about SPI. But with SPI you are right.
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.

 

[Vladimir Vassilevsky]

I believe the OP wasn't talking about SPI. But with SPI you are right.

What else is the PC parallel port can be used for if not for the
simulation of the SPI or I2C by bit banging?

I keep the 14-year old PC with Win98 exactly for this purpose: it is
often the quickest way to get something to work.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

 

[Joerg]

What else is the PC parallel port can be used for if not for the
simulation of the SPI or I2C by bit banging?

Hey, I still print over it. Ok, I have a network printer but also
another one here in the office that gets shared by a LPT auto-switch
between two PCs. It's quicker to print and I don't have to get off my
keester

I keep the 14-year old PC with Win98 exactly for this purpose: it is
often the quickest way to get something to work.

Yep, often the old stuff works better than anything that came later.
This is also why there are things such as the old Eico tube voltmeter in
the lab. That thing remains completely unfazed should a spike come along.

 

[Jon Slaughter]

I believe the OP wasn't talking about SPI. But with SPI you are right.
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 ;/

 

[Jon Slaughter]

Yes, it can cause problems in some cases.

AVR Mega644 is indeed sensitive to the SPI clock irregularities while
being programmed. It causes the programming to fail. I suppose the other
new AVRs are sensitive to this, too. The older AVRs don't have this
problem; you can interrupt the process at any moment for any long time.



This can be the issue - it is a fact. We can only speculate why it
happens; perhaps, the internal state machines may have a timeout
protection or something. I didn't believe it before I encountered that
problem myself.

Thanks. This isn't what I wanted to hear though ;/ Is this a hardware issue
or was it designed that way? If its designed that way then maybe its ok to
some degree... unfortunately with SPI there is no way to know if it timed
out or not?

Jon

 

[Vladimir Vassilevsky]

Jon Slaughter wrote:

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.

There is no point in developing anything for the parallel port now.
This is what you need:

http://www.ftdichip.com/Products/FT2232C.htm


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

 

[Rich Grise]

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

 

[Jon Slaughter]

Jon Slaughter wrote:




There is no point in developing anything for the parallel port now.
This is what you need:

http://www.ftdichip.com/Products/FT2232C.htm

Well, I wanted to hook directly up to some devices with minimum external
circuitry. Eventually I might add support for usb and some other devices but
at this point all I have is the parallel port.

I'm essentially just making something that is similar to WinPic. So if I
wanted to program so some pics or play with some controllers that use some
some communications method I could do it quite easily by just typing in the
commands and have the program do the rest(its more work than that but it
would only need to be done once).

Thanks,
Jon

 

[Jon Slaughter]

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.

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

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.

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

 

[Don Bowey]

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.

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.

 

[Joerg]

Jon Slaughter wrote:




There is no point in developing anything for the parallel port now.
This is what you need:

http://www.ftdichip.com/Products/FT2232C.htm

Yep, that's the modern way. Just keep in mind that many of those types
of chips will only work as bus masters.

 

[Joerg]

Well, I wanted to hook directly up to some devices with minimum external
circuitry. Eventually I might add support for usb and some other devices but
at this point all I have is the parallel port.

I'm essentially just making something that is similar to WinPic. So if I
wanted to program so some pics or play with some controllers that use some
some communications method I could do it quite easily by just typing in the
commands and have the program do the rest(its more work than that but it
would only need to be done once).

But keep in mind that when your PC croaks the new one might no longer
have a parallel port. Adapters might be available for a while but aren't
100% the same. Then all your work could be flushed down the drain.
Personally I'd go RS232 since USB-RS232 should be available for a long time.

 

[Joerg]

Thanks. This isn't what I wanted to hear though ;/ Is this a hardware issue
or was it designed that way? If its designed that way then maybe its ok to
some degree... unfortunately with SPI there is no way to know if it timed
out or not?

The datasheet will usually tell you.

 

[Paul Burke]

Vladimir Vassilevsky wrote:

Yep, that's the modern way. Just keep in mind that many of those types
of chips will only work as bus masters.

The FT2232 can be glacially slow for bitbanged serial protocols.

 

[Vladimir Vassilevsky]

Yep, that's the modern way. Just keep in mind that many of those types
of chips will only work as bus masters.

BTW, in the old good DOS, it is possible to sample the LPT port with the
rate of up to about 1.5 MHz. In many cases, this allows for the
simulation of the slave modes as well as sniffing on the serial protocols.

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

 

[Joerg]

BTW, in the old good DOS, it is possible to sample the LPT port with the
rate of up to about 1.5 MHz. In many cases, this allows for the
simulation of the slave modes as well as sniffing on the serial protocols.

I do that with a Dolch logic analyzer. From pre-DOS days

 

[JosephKK]

Joerg [email protected] posted to
sci.electronics.design:

But keep in mind that when your PC croaks the new one might no
longer have a parallel port. Adapters might be available for a while
but aren't 100% the same. Then all your work could be flushed down
the drain. Personally I'd go RS232 since USB-RS232 should be
available for a long time.

I would not bet on that either, while USB ip is cheap ethernet ip is
free like RS232 and RS485.

USB will survive in applications where "provable" hardware connections
are still valuable (DRM). Eventually even that will collapse.

 

[Joerg]

Joerg [email protected] posted to
sci.electronics.design:




I would not bet on that either, while USB ip is cheap ethernet ip is
free like RS232 and RS485.

But neither is easy from within applications such as Office. Most lab
gear I have uses the old RS232 protocol over USB but to me as the user
the fact that it's a physical USB layer becomes transparent. I can talk
to it via Hyperterminal just like usual.

USB will survive in applications where "provable" hardware connections
are still valuable (DRM). Eventually even that will collapse.

Considering USB/s market penetration I doubt that. USB simply works.
What should possibly replace it anytime soon? Ok, wireless but that'll
be a while.