>
> Wow. Thanks. Asynchronous seems a lot more complicated. What is the
> advantage of using an asynchronous system? Is USB asynchronous?
>

The main reasons to use asynchronous signalling (and this applies a lot to
higher-frequency channels like USB, SATA, etc.) are, among others: the clock
line itself is a source of lots of high frequency noise, toggling a clock
line fast and doing it "hard" enough that you don't get very soft edges
consumes a lot of power, and high frequency signals are expensive in terms
of PCB routing requirements, and you run into problems with phase delays
between, say, the clock edge and the signal edge.

(Imagine a very very fast SPI channel - in the hundreds of MHZ, maybe. Now,
at those frequencies, the time it takes for the signal to propagate through
one unit length of copper becomes a very real consideration compared to the
period of your clock signal. If your clock and data trace lengths don't
match up, the edges start shifting apart. All of a sudden, you've got your
clock and data edges no longer lining up, or worse yet, they're out of phase
so that you're sampling the data at the same time that the data line itself
is being changed by one of the chips - mayhem! Of course this can be dealt
with, but it's expensive and complicated, and in some cases, it's better to
just send the data and make sure both devices are synchronized.)

Look into something like Manchester or 8b/10b coding to see how high
throughput signals embed the clock in the data. It's usually a combination
of both sides knowing what frequency to run at, sort of, and a commonly
agreed-upon scheme of signaling the clock phase (via a sync bit or something
like that).
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist