5
messages
|
solarwind
<[email protected]>
|
Thu,
Apr 2, 2009 at 11:12 AM
|
|
|
I've
gotten used to the types of busses such as I2C and SPI and
parallel where you have one or more data lines, an optional chip
select line AND A CLOCK LINE. It's so easy to understand - you set the
bit and strobe the clock. The underlying hardware electronics was also
so simple that I was even able to make my own very simple SPI device.
I like to believe that these types of busses are simple, compact, very
stable, fast, and efficient and more immune to errors.
However, the other types of busses which don't use a clock line are
the ones that confuse me. For example, I have no idea how UART
(although I use it all the time), USB and 1-wire work. I would really
like to know how these busses work on the signaling level but I can't
find much information.
If anyone would please enlighten me on the topic or provide some
links, I would very much appreciate it.
--
solarwind
--
http://www.piclist.com
PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
|
|
|
Tony
Vandiver
<[email protected]>
|
Thu,
Apr 2, 2009 at 11:45 AM
|
|
|
The
ones with clocks are called synchronous because the clock transition
syncronizes the behavior between the two systems, but protocols without
a bus are asynchronous and generally use recognizable transitions on the
data lines to synchronize along with a pre-negotiated timing that tells
a uart for instance that it should expect so many bits in the time after
the start bit, i.e. the systems without clocks depend on having a common
time measurement and they expect the "bits" to be a certain width.
That's why it's important to establish a baud rate for those kinds of
systems where not so much for the I2C and SPI other than limiting the
maximum detection frequency. Since there are likely never two systems
with exactly the same clock rates, there is always an oversampling done
on a UART to not just look at the signal received once during the
expected bit time, but to sample 8 or more times, and assume that the
dominant state is the one intended. That's a start anyway.
Tony
solarwind wrote:
> I've gotten used to the types of busses such as I2C and SPI and
> parallel where you have one or more data lines, an optional chip
> select line AND A CLOCK LINE. It's so easy to understand - you set
the
> bit and strobe the clock. The underlying hardware electronics was
also
> so simple that I was even able to make my own very simple SPI
device.
> I like to believe that these types of busses are simple, compact,
very
> stable, fast, and efficient and more immune to errors.
>
> However, the other types of busses which don't use a clock line are
> the ones that confuse me. For example, I have no idea how UART
> (although I use it all the time), USB and 1-wire work. I would
really
> like to know how these busses work on the signaling level but I
can't
> find much information.
>
> If anyone would please enlighten me on the topic or provide some
> links, I would very much appreciate it.
>
>
--
[Quoted text hidden]
|
|
|
solarwind
<[email protected]>
|
Thu,
Apr 2, 2009 at 12:12 PM
|
|
|
On Wed, Apr 1, 2009 at 10:45 PM, Tony Vandiver
<[email protected]>
wrote:
> The ones with clocks are called synchronous because the clock
transition
> syncronizes the behavior between the two systems, but protocols
without
> a bus are asynchronous and generally use recognizable transitions
on the
> data lines to synchronize along with a pre-negotiated timing that
tells
> a uart for instance that it should expect so many bits in the time
after
> the start bit, i.e. the systems without clocks depend on having a
common
> time measurement and they expect the "bits" to be a certain width.
> That's why it's important to establish a baud rate for those kinds
of
> systems where not so much for the I2C and SPI other than limiting
the
> maximum detection frequency. Since there are likely never two
systems
> with exactly the same clock rates, there is always an oversampling
done
> on a UART to not just look at the signal received once during the
> expected bit time, but to sample 8 or more times, and assume that
the
> dominant state is the one intended. That's a start anyway.
Wow. Thanks. Asynchronous seems a lot more
complicated. What is the
advantage of using an asynchronous system? Is USB asynchronous?
[Quoted text hidden]
|
|
|
Marcel
Birthelmer
<[email protected]>
|
Thu,
Apr 2, 2009 at 1:49 PM
|
|
|
>
> 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).
[Quoted text hidden]
|
|
|
