Searching \ for '[EE] Types of busses' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: massmind.org/techref/index.htm?key=types+busses
Search entire site for: 'Types of busses'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Types of busses'
2009\04\01@231204 by solarwind

picon face
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

2009\04\01@234543 by Tony Vandiver

flavicon
face
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:
{Quote hidden}

2009\04\02@001210 by solarwind

picon face
On Wed, Apr 1, 2009 at 10:45 PM, Tony Vandiver
<spam_OUTtonyTakeThisOuTspamtraceelectronics.com> 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?

2009\04\02@001647 by cdb

flavicon
face


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

As you are probably aware, the above formats are asynchronous and
somehow embed the clock signal onto the data information.

From this there are two ways of coding/decoding the clock signal.
RS232 and1-Wire use a timing method whereby specific signals at
specific time points mark the synchronisation data.

1-Wire does it by performing pulses with defined widths and
predetermined time periods within a constant timeslot (min 960uS) in
sequence.

So (Maxim actually have some excellent might tomes for free download
on this + Maxim App notes 2420 and 162 ) -

To start a transmission on a 1-Wire buss a low reset pulse of 480uS
has to be executed. (following code is in XCSB Basic, so cringe and
then convert to 'C').

proc  fastcall ubyte m_1W_reset()

 response = D_SHORT                //Assume data line is shorted

 m_1W_ddr_in()                        //data line is set as input and therefore high
       
 if (M_1W_PORT & (1<<M_1W_BIT)) == 0 then
               
       return response                //if the data line is low here, the line is shorted

 endif

 m_1W_low()                        //prepare 1wire bit to bring slave low
 m_1W_ddr_out()                          // data line is now an output and low
 delay_10us DLY_500                //hold low for 500uS
 m_1W_ddr_in()                        //return data line to an input and high Z
       
 delay_10us DLY_70                //wait 70uS

 response = NO_DEV                //Assume no presence signal sent
       
 if        (M_1W_PORT & (1<<M_1W_BIT))== 0 then
                       
         response = DEV_OK                //The data line has been pulled low by the
device
                       
 endif
       
 delay_10us DLY_430                 //Finish the time slot

 return response

endproc

In fact you can download the code from my website it is free, unless
you feel like making a donation.

The Master waits upto 70uS and then (hopefully) a presence pulse up to
240uS is sent by the Slave (pulses are from high waiting state to
low).

Once the presence pulse has been received the Master can start sending
commands which are listed in the 1-Wire device manual. there are some
commands that are the same throughout all the devices and then there
are the specific device commands.

Again the sending and receiving of '1's and 0's is pulse width based
within a 960uS time frame.

A 1 is signified by the Master bringing the signal line down for  no
more than 15uS and then releases the data line (all 1-wire busses are
pulled high by a resistor) it then allows the line to stay high
between 60 and 120uS and then pulls the line low again.

A 0 is much easier it brings the line low for 120uS then releases the
line.

To read a byte the Master brings the line low for 6uS, it then allows
the line to drift high again after 5uS it checks the line, if it is
still high then a 1 has been sent if it is low then a zero.

/* Reads a byte from one wire device */

proc fastcall ubyte m_1W_r_byte()

ubyte loop rxbyte

loop = 0
rxbyte = 0
 
        asm_start
                                       
               loop8

        asm_end        

               m_1W_low()                                 //Prepare pin to go low
               m_1W_ddr_out()                         //Pin is now low and an output        
               delay_100ns DLY_6                         //delay 6uS
               m_1W_ddr_in()                         //return line to high Z                
               delay_100ns DLY_5                         //Delay 5uS        

               rxbyte = (rxbyte >>1)                 //Assume the bit is a zero

               //Test the port bit, if still high then a one was sent

               if (M_1W_PORT & (1<<M_1W_BIT))!= 0 then

                   rxbyte = rxbyte |0x80         //least significant bit first

               endif
                                       
               delay_10us DLY_50

      asm_start

               incf loop_m_1W_r_byte_func_local
               btfss loop_m_1W_r_byte_func_local,BYTE_SIZE
               goto loop8        

     asm_end
                               
       return rxbyte
               

endproc

I love 1-Wire devices, just have never had to use one in anger and
only played with the RTC and Thermocron devices.

For the UART - I suggest purchasing either Serial Pic-N from Square-1
(you can download the code free, but let me put it this way - Olin
wouldn't approve of their assembler writing methods, and without the
book trying to work out what Mauve.asm versus Blue.asm is a little
difficult - obviously it has been done so you buy the books)

You could also buy Jan Axelsons books, she has some code on her
website. The bouns here is that I think she now has a book that
combines RS232 and USB (differential) in one go.

Colin
cdb, .....colinKILLspamspam@spam@btech-online.co.uk on 2/04/2009

Web presence: http://www.btech-online.co.uk  

Hosted by:  http://www.1and1.co.uk/?k_id=7988359







2009\04\02@002913 by Benjamin Grant

flavicon
face
en.wikipedia.org/wiki/Comparison_of_synchronous_and_asynchronous_signalling


On Thu, Apr 2, 2009 at 12:12 AM, solarwind <x.solarwind.xspamKILLspamgmail.com> wrote:

{Quote hidden}

> -

2009\04\02@015000 by Marcel Birthelmer

picon face
>
> 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).

2009\04\02@073851 by olin piclist

face picon face
solarwind wrote:
> 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.

For a UART the bus starts in the idle state.  Characters are sent with a
start bit preceeding the data bits.  The start bit is the opposite polarity
from the idle state.  The data bits are then sent.  Since both ends agree on
the bit timing, the receiver synchronizes its clock to the leading edge of
the start bit, then knows when the data bits are.  For 8 bit characters,
this leaves 8 1/2 bit times from the leading edge of the start bit to the
middle of the last data bit.  Reception will still be fine if the two ends
are off by 1/4 bit by the middle of the last data bit.  That is .25 / 8.5 =
3%, which is well within crystal, ceramic resonator, and even well tuned R/C
oscillator capability.  There is at least one stop bit between characters to
guarantee the line is in the idle state at the start of the next start bit.
This is why it takes 10 bit times to send 8 bits over a UART.

USB works on this similar known bit speed principle, but is a lot more
complicated.  This is all in the USB spec, which is freely avialable.

1-wire timing works similarly again, but has extra complications due to its
bi-directional nature.  Again, see a spec for details.  The data sheet for
most chips using it will describe enough detail.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\04\02@074057 by olin piclist

face picon face
solarwind wrote:
> Wow. Thanks. Asynchronous seems a lot more complicated.

Depends on what level you mean.  In a PIC asynchronous is easy if you have a
UART.

> What is the
> advantage of using an asynchronous system?

No clock line.

> Is USB asynchronous?

Yes.  This is all described in great detail in the USB spec.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\04\02@075921 by olin piclist

face picon face
Olin Lathrop wrote:
{Quote hidden}

I should also have mentioned manchester encoding.  That's a way to encode
clock with data each bit on a single line.  It's used a lot in radio because
the line spends half the time low and half the time high.  I'm sure the is
much on manchester on the web if you want to know more.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\04\02@084840 by Harold Hallikainen

face
flavicon
face
There have already been some good descriptions of UARTs posted. I thought
I'd point out that they are derived from mechanical UARTs in teleprinters
like those made by Teletype Corporation. I used to use Teletype model 15
printers for ham radio. These used a 5 bit code (Baudot). The transmitted
data consisted of a start bit, 5 data bits, and 1.5 stop bits. A lot of
UARTs will still do 1.5 stop bits. The printer had a "selector magnet."
This magnet held in an armature when the line was in the mark condition,
which was the idle condition, with 60mA flowing through the coil (more on
this later). The armature kept a shaft from rotating. The shaft was driven
through a clutch from a synchronous motor driven off the AC line. Some
units had DC motors with governors. When a start bit came along (a "space"
condition), the magnet dropped out and the shaft was allowed to turn. At
various positions during the rotation of the shaft, the position of the
selector magnet armature was sampled. If the magnet was pulled in, a lever
was put in the mark condition. If it was released, a lever was put in the
space condition. In this manner, five levers were positioned during the
rotation of the shaft. When the shaft finished its rotation, the selector
magnet was pulled in for the stop bit, and the shaft would be stopped (the
clutch would slip). The five levers drove 5 "vanes" that went across the
front of the printer. These were pivoted in back. The front could be
either up or down for the mark and space condition of each of the bits.
Levers on the moving carriage transferred the position of these vanes to
slotted curved bars below the type basket. These bars also had one of two
positions for mark and space for each bit. One slot would line up on all
the bars when a particular character code was sent. This allowed another
bar that was attached to a particular type bar to fall into the slot. A
"bale" (I'm trying to remember all the terms we used for the parts of
these things) came forward during the stop bit and would catch the type
bar that had fallen through the slot, pulling it forward, and causing the
type to fly up and hit the paper through a ribbon, printing the character.

There were two types of selector magnets: Pulling and Holding. A Holding
magnet would have a cam push the armature up to the electromagnet just
before the sample time of each bit. The cam would then drop the armature.
If it stuck, there was current, and the line was in the mark condition. If
the armature dropped, it was a space bit. On pulling magnets, the cam did
not do that, so you needed higher current to pull the armature in.

If you used pulling magnets, the two coils were usually in series and
would run at 60mA for mark. If you used holding magnets, the coils could
be in parallel for 60mA or series for 20mA. On my 60 word per minute
machines, each bit was 22ms, and the stop bit was 31ms.

By the way, the terms "mark" and "space" came from Morse's original
telegraph, I believe. His original telegraph had a moving paper tape and a
pen. When there was line current, the paper would be marked. When there
was no line current, the paper would not be marked, causing a space. A
telegraph operator would read the marks and spaces (forming dots and
dashes) to read the telegram. However, telegraph operators were able to
read the telegram by just listening to the sound of it. So, the whole
thing was simplified by getting rid of the pen and paper, just giving a
telegraph sounder. Anyway, mark and space from the 1860s carries over to
UARTs today.



Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2009\04\02@104420 by William \Chops\ Westfield

face picon face

On Apr 2, 2009, at 4:41 AM, Olin Lathrop wrote:

>> What is the advantage of using an asynchronous system?
>
> No clock line.

In particular, this permits simpler and cheaper cabling, and allows  
the data signal to be sent over media that could not preserve a clock  
signal, or could not preserve a clock signal without sacrificing  
bandwidth to do so, such as an audio frequency acoustically coupled  
modem.

BillW

2009\04\02@122118 by solarwind

picon face
Thank you to everyone - I understand this a lot better now.

2009\04\03@114250 by Herbert Graf

flavicon
face
On Wed, 2009-04-01 at 23:12 -0500, solarwind wrote:
> Wow. Thanks. Asynchronous seems a lot more complicated. What is the
> advantage of using an asynchronous system? Is USB asynchronous?

Well, you save a clock line, that's a pretty big advantage when dealing
with serial protocols (2 wires vs. 1 wire).

Pretty much all "modern" serial protocols either embed in the data
something that allows the endpoint to generate/sync a local clock (i.e.
USB), send a lower speed clock (i.e. DVI/HDMI sends the pix clock, a PLL
on the receiver bumps that up internally to the serial clock) or do both
(PCIE sends a reference clock, but some end points don't use it).
Considering the speeds involved (~5Gbps for protocols like PCIE, SATA,
and USB3) it's just not feasible anymore to send the clock reliably.

The benefit of course is that with modern PLL/DLLs it's possible to
account for skew between lines. This is used with PCIE where every
"lane" is actually treated as a completely separate line. Even though
the data is sent in parallel (assuming more then an x1 link: bit 0 is
sent on lane0, bit 1 on lane 1, etc) the skew between lines can easily
be a clock period (even more). The end point treats each lane
separately, so it adjusts the skew on each line to ensure that
internally all the data "arrives" at the same time to the rest of the
chip.

Even "parallel" synchronous buses use this technique. DDR for example
groups each set of 8 bits together with it's own data strobe. This
allows for skew between each set of 8 bits to be compensated for (you
still have to length match each group of 8 bits).

All of this neatness allows for less stringent layout requirements on
the board designer. In the "parallel" days (i.e. PCI) you had to ensure
that every single data/control/clock line were within a small margin the
same length (hence the "squigglies" that were so common, you still see
them on memory buses) . This became very unwieldy as bus widths
increased. These days you still have length matching requirements, but
for the speeds involved they are quite lax.

If you want to learn more I'd recommend wiki, it's a wonderful resource
that often gives pointers on more technical info.

TTYL

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...