Re: Confused about synchronous communications


"Jan Panteltje" <pNaonStpealmtje@xxxxxxxxx> wrote in message
news:fd0vo0$71e$1@xxxxxxxxxxxxxxxxxx
On a sunny day (Fri, 21 Sep 2007 16:50:51 GMT) it happened "Jon Slaughter"
<Jon_Slaughter@xxxxxxxxxxx> wrote in
<LDSIi.6267$FO2.115@xxxxxxxxxxxxxxxxxxxxxxxxxx>:


"colin" <colin.rowe1@xxxxxxxxxxxxxxxxxx> wrote in message
news:1MQIi.47066$ph7.38833@xxxxxxxxxxxxxxxxxxxxxxx
"Jon Slaughter" <Jon_Slaughter@xxxxxxxxxxx> wrote in message
news:gbEIi.5374$7P7.242@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
<snip>
Basically I just sendt he clock like its a piece of data but I
alternate it every time I send a piece of data. Of course then I
thought that this wouldn't work because theres no way to make sure
the
data would be valid before the clock changed(if it was edge
triggered... which I think I was thinking that it was level triggered
and thats why I did it).

I just have to change the clock 2x as fast I think and it should work
fine. Then I just have to worry about getting it to work within the
protocol but I think I can handle that.

it also depends how fast you are sending and how fast you are polling
at
the receiving end.
if the port you are receiving with doesnt actually 'clock' the data in
then you have to make sure you poll
it fast enough to detect both the high and low state of the clock.


For my communications I don't have to poll but I will eventually add
that
ability. There are some major problems that I see with polling because
I
cannot do it in a consistent way(because of windows). I will try and
poll
it fast as possible but not sure how its going to work out cause I
haven't done any tests.

if you are sending quite slow you could actually afford to toggle the
clock
and change the data at the same time, when the receiving end detects
the
clock has changed it quickly reads the port again
and the data should be stable at that time.

Ok, I see what your saying. Basically the set up time is "artificial"
in
that its only used because it takes time to get stable data? So if I
know
for a fact that I can do something like this

out data
out clock

yes that could do it, depends on the cycle time etc...


and the setup time is just a few cycles of the then it would work just
fine because the data would be valid(by assumption). Of course I'll
still
needt toggle the clock 2x unless it would be both + and - edge
triggered?

not many things are dual edge triggered, i doubt if the parallel port is
if thats what your using
but then ive never used it this way.

maybe you have a pulse output capability on your micro
depends how fast you wish togo,
but you probably have time to do it in software.


Although the problem I have, because I was thinking about using this
method which I called "interleaved" where I offset the clock 1/2 the
clock freq so its

out data
delay
out clock
delay
out data
...

so the clock always changes in the middle of when the data
changes(approximately). This wouldn't work with just a single edge
trigger though.

The problem I wast thinking is right at the transition between two
consecutive data changes. Basically, Does the data have to be valid
durring the whole hold time or just basically durning most of it at the
start? (I would imagine it depends on the integrity of the clock signal
though?)

the data must be valid from the clock edge - setup time
and mustnt change till the clock edge + hold time.

otherwise the latch may contain garbage.





it is sometimes relied on that the hold time is 0
so that the clock and data can be changed at the same time,
but this is not good if the clock can be delayed more than the data
wich
could happen with long cable,
it is possible to overcome this by introdicing a delay on the data,
some chips have tunable data delays to allow the fastest comunication
possible.


Well, at this point I'm just trying to do simple I2C, SPI, and ICSP
stuff
for a few projects I have in mind. I think just "bit-banging" is
pretty
much going to do it though. Theres just a few issues I wanted to talk
about before I moved on so I didn't get down the wrong path.

theres several issues with comunications wich can get quite complicated
mostly to do with error detection and error recovery etc,
retrying missing packets ...

ive had to repair many such implementations becuase they assumed
things wouldnt go wrong and then got hung up when a char got lost or
something.

this sort of thing has been done so many times it might be worth trying
to
find something someone else has already got working and adapt it to your
needs.


Well, I have looked at some others codes and all they do is bang the bits
outs. I'm sure this method works 99% of the time. Most likely I will do
this
too but I want to get it as fast as possible.

Biggest problem I have though is if I have to poll or use interrupts to do
any of these protocols(that is, basically if I have to be a slave).

If you want to play slave, then I highly recommend using a separate micro
controller with buffer (say fifo), if you want to avoid writing interrupt
routines.
Even in real time Linux interrupt latency can be > 10uS.
I dunno about mswindows.
If however you use an external hardware buffer, you can signal it has
data, and
have the PC read the lot at once.


Yeah, I was eventually thinking about doing this but I first want to be able
to program PIC's and a few other devices using ICSP, I2C, and SPI. Once I
get a working program that does what I want I'll think about trying to make
it better. Since PIC's support USB, SPI, I2C, Serial, etc... its pretty
easy to get data to and from them but I first need to be able to program
them and I want to play around with some of the debugging features and
stuff.

Its just that windows makes this a bitch to do. In dos it would be a piece
of cake...

Normally in i2c I only use the PC as master.

Well, I'm not sure I understand the protocol completely. For example, it has
an awknowledgement but I'm now sure how it works. Because in this case the
slave has to set the data pin but the master is controlling the clock. There
are cases also where the slave will hold the clock line low to interrupt the
master. I don't see how I can solve these problems easily in windows
without interrupts and polling. Its going to be more work than I thought.
Hopefully though I can get ICSP done pretty easily and then I'll probably
use a pic as a proxy for the other two protocols since they have it built
in.

Thanks,
Jon


.

Relevant Pages

  • Time Drift Compensation on Linux Clusters
    ... While working on a Linux cluster with kernel version 2.4.27 we've ... for this problem which is based on the Pentium's TSC clock. ... Following is a detailed description of the problem and the fix, ... The number of interrupt per second is defined by ...
    (Linux-Kernel)
  • Re: Time is going very much off all the time
    ... cumulative so eventually the clock will loose more and more time. ... used during running linux after startup. ... That was the timeer interrupt on DOS. ... That has nothing to do with the rtc. ...
    (alt.os.linux.suse)
  • Re: [RFC][PATCH] new timeofday core subsystem (v.A0)
    ... >>Still need some way to do user timers that are tightly pegged to the clock. ... > nothing to peg or tie the timer with. ... > caused latency caused by the interrupt programming. ... >>adjust it for drift over time. ...
    (Linux-Kernel)
  • Re: [PATCH][I2C] ST M41T00 I2C RTC chip driver
    ... You can't stop the clock when you read it ... This particular RTC chip provide no mechanism to manually stop the clock ... There is a problem that if all the register reads don't happen within ... assumes that its not called from an interrupt handler (e.g., ...
    (Linux-Kernel)
  • Re: Premature wakeup of time.sleep()
    ... >> clock, shich varies from os to os. ... Once you have a wakeup time, you can put your sleeper in a time-ordered queue, ... have the option of a hot return as if the sleep call hadn't happened. ... meaning any time there is any interrupt. ...
    (comp.lang.python)
Quantcast