Connect with us

Timing in Synch Comm.

Discussion in 'Electronic Design' started by Jon Slaughter, Sep 20, 2007.

Scroll to continue with content
  1. 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
     
  2. 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.



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

    Joerg Guest

    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.
     
  4. 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
     
  5. Joerg

    Joerg Guest

    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 :)

    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.
     
  6. 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 ;/
     
  7. 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
     
  8. 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


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

    Rich Grise Guest

    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
     
  10. 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
     
  11. 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
     
  12. Don Bowey

    Don Bowey Guest

    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.
     
  13. Joerg

    Joerg Guest

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

    Joerg Guest

    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.
     
  15. Joerg

    Joerg Guest

    The datasheet will usually tell you.
     
  16. Paul Burke

    Paul Burke Guest

    The FT2232 can be glacially slow for bitbanged serial protocols.
     
  17. 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
     
  18. Joerg

    Joerg Guest

    I do that with a Dolch logic analyzer. From pre-DOS days :)
     
  19. JosephKK

    JosephKK Guest

    Joerg 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.

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

    Joerg Guest

    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.

    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.
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-