Re: Confused about synchronous communications


"Jonathan Kirwan" <jkirwan@xxxxxxxxxxxxxx> wrote in message
news:1p46f31dkehifmq9p1tkr6lm0c0i708vmk@xxxxxxxxxx
On Thu, 20 Sep 2007 19:16:17 -0500, "Jon Slaughter"
<Jon_Slaughter@xxxxxxxxxxx> wrote:

I think I do not have to worry about that though? The clock itself will
change 2x as fast and the edge trigger will never change with data because
the data is twice as slow. Basically every other edge will change with the
data but thats not the edge that triggers so its no big deal which one
comes
first?

If I understand you correctly then you are probably okay. I gather
you are saying that you DO change the data and clock at the same time,
but that when that takes place it is only on a benign clock change (in
other words, the clock edge that doesn't clock in the data but only on
the opposite phase.) Assuming set up and hold isn't a problem, that
seems okay. And with that terrible-looking c++ code I saw (I didn't
check to see when the data changed relative to the latching edge of
the clock), I am not much worried about the timing. I don't think
they build latches that slow or cpus that fast. ;)


Its actually C# code.

Essentially what I do is load the bits into an array and output them to the
port. But only on lines that are for output. So basically you would call the
code like

SyncSend(ParallelPortPins.Data0 | ParallelPortPins.Data1, new int[] {
i,j,k,l });
So that the only pins that are changed are the D0 and D1 + clock pins(which
is defined inside the class).

So all that mess is just masking out the pins that are to be changed and
putting the data in them (the data itself is in a special format and wastes
a lot of space but easier to work with(essentially matches the memory mapped
port).

The code I send only changes the data with the clock at the same rate... but
if I double the clock rate then its should match up just right and if its
the wrong edge then I can easily invert the pins.

The main problem now is actually implementing i2c. I'm not sure if I can
actually do it because its not clear to me(still reading over the specs) if
the clock is always in control of the master when sending and recieving
data. Basically I want to avoid polling for this as much as possible
because windows makes it a bitch to do.

My initial thoughts where that the master clock was always used to send and
recieve data and if thats the case then it shouldn't be a big problem. If
slaves take over the clock when they send data then its a problem cause I
have no way to know except for polling(or try to implement some interrupt
driver in windows which is probably much more trouble than its worth).

I think I'm going to go ahead and try to implement ICSP since that seems to
be the easiest and then see what happens.

Thanks,
Jon


.

Relevant Pages

  • Re: Confused about synchronous communications
    ... I just have to change the clock 2x as fast I think and it should work ... This wouldn't work with just a single edge trigger ... Theres just a few issues I wanted to talk ...
    (sci.electronics.design)
  • Re: Confused about synchronous communications
    ... change 2x as fast and the edge trigger will never change with data because ... the data is twice as slow. ... If I understand you correctly then you are probably okay. ... you are saying that you DO change the data and clock at the same time, ...
    (sci.electronics.design)
  • Re: Confused about synchronous communications
    ... I just have to change the clock 2x as fast I think and it should work ... This wouldn't work with just a single edge trigger ... Theres just a few issues I wanted to talk about ...
    (sci.electronics.design)
  • Virtual PC and real time clock lag
    ... I noticed something that is rather peculiar about Virtual PC, Windows ... PC to lose its real time clock accuracy. ... The real-time clock still ticks once per second. ... playing around with iTunes for Windows, I found that QuickTime ...
    (microsoft.public.mac.virtualpc)
  • Re: Clock drift problems
    ... I know almost nothing about Linux, ... the real-time clock has gotten 7 hours slow. ... and setting up ntpd to autostart - probably ... >claim it's nothing to do with Linux, that it would happen with Windows ...
    (comp.os.linux.misc)