[Home] [Downloads] [Search] [Help/forum]

Gammon Forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  Electronics
. -> [Folder]  Microprocessors
. . -> [Subject]  Comparison of transfer protocols
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?

Comparison of transfer protocols

Postings by administrators only.

[Refresh] Refresh page


Posted by Nick Gammon   Australia  (19,672 posts)  [Biography] bio   Forum Administrator
Date Mon 07 Feb 2011 03:54 AM (UTC)  quote  ]

Amended on Sun 21 Oct 2012 06:17 AM (UTC) by Nick Gammon

Message
Introduction


This thread summarizes the various transfer protocols that are documented elsewhere on this forum.

In the descriptions below the number of wires needed to connect assumes a ground return (otherwise the 1-wire interface would be a 2-wire interface, etc.). Also any power connections are not counted. So for example if you need to drive a LCD display with I2C (nominally a two-wire connection) you actually need four wires: ground, power, SDA (data), SCL (clock).

Timings are taken with my test setups, other devices may run faster or slower depending on the circumstances. However they could be taken as a comparative guide. Timing figures are rounded to the nearest hundred.

Speed summary


Fastest to slowest, in 8-bit bytes per second.


  • SPI - 333,300
  • I2C - 10,000 (up to 40,000 by changing the clock rate)
  • Parallel - 5,500
  • Serial - 3,840 (at 38,400 baud) (however 11,520 at 115,200 baud)
  • One-wire - 1,500


Speeds are a guideline, they can vary dependent on the data being sent and the processor speeds etc.

One-wire


Wires

One:

  • Data. Needs a pull-up resistor to +5v (nominally 4.7K).


Connectivity

Master to slave(s) only. All devices are wired together (that is the data lines are all connected).

Number of devices

Potentially unlimited, as each device has a 64-bit unique address wired in at manufacturing time. Presumably resistance and capacitance on the cable run to the devices would impose a practical limit.

Timing

This depends on the application somewhat, as you may need to send an 8-byte device address, or may not. However on average, 1500 bytes per second.

Application

Temperature sensors, package tracking, serial numbers on devices (eg. ink cartridges).

Notes

Devices can be self-powered (by "borrowing" power from the data line) thus making them easily imbedded in things like packages for tracking purposes without needing batteries or external power. The master can initially discover the addresses of all connected devices by using a "discovery" protocol.

On the Arduino any (free) port can be used for One-wire communication as the protocol is implemented in software.

More info

http://www.gammon.com.au/forum/?id=10902


I2C (Inter-Integrated Circuit) or "Two-Wire"


Wires

Two:

  • SDA (serial data)
  • SCL (serial clock)


Connectivity

Multiple masters and multiple slaves. All devices are wired together (that is the SDA and SCL lines for each device are connected). Any device an initiate communication with any other.

Number of devices

Maximum of 119 devices, since there is a 7-bit address (128 values) and the following ones are reserved:


  • Address 0 - for broadcasting to all devices
  • 120 to 127 - for future use


Timing

To send an address followed by a single data byte: 4700 bytes per second. The speed improves if you send multiple data bytes because then the address is only sent once. The internal libraries on the Arduino impose a limit of 32 bytes per transaction, so potentially you could get around 10,000 bytes per second (for example, sending a line of text to an LCD display).

You can speed up the I2C clock (up to 4 times the default) so your transfer rate might rise to 40,000 bytes per second.

Also if you broadcast (send to address 0) then you could potentially send to many devices (118 ones other than yourself) which makes it a lot faster than using other protocols to send data to individual devices separately.

Application

Communications between processors, devices (eg. LCD screens) and specialized chips. There are "port expander" chips available which use I2C to control up to 16 ports, so you could (say) turn on or off 16 LEDs with a single I2C address. Other applications are memory chips, so that you can communicate using I2C to a chip which might store 32 Kbytes of RAM (for data logging, for example). Many of these expander chips allow you to choose a subset of addresses by jumpering pins, so you might have up to 8 memory chips on an I2C line, for example.


Notes

Since any device an initiate communication (which can generate an interrupt) you could have things like keyboards, alarms etc. connected which communicate when required.

On the Arduino Uno analog ports 4 and 5 are used for I2C communication.

More info

http://www.gammon.com.au/i2c




SPI (Serial Peripheral Interface)


Wires

Four:


  • SCK (Serial Clock)
  • MISO (Master In, Slave Out)
  • MOSI (Master Out, Slave In)
  • SS (Slave Select)


If you only plan to use one slave, that slave could have SS "hard-wired" low to save a wire. This might not work for all devices as some may look for the high-to-low transition of SS to start processing data.

Connectivity

One master and one slave. However extra slaves can be added by sharing the SCK/MISO/MOSI lines between each slave, and giving each one a dedicated SS line. The SS is pulled low to "activate" a particular slave. Transmission is always full-duplex, meaning that during the time taken to transmit one byte, a byte is always sent in both directions.

Number of devices

No particular limit, however you need a separate SS (slave select) line per device, so you will eventually run out of pins which can be used for SS (especially as you will have used 3 pins already for SCK/MISO/MOSI). Thus for one device: 4 pins, two devices: 5 pins, three devices: 6 pins, and so on.

Timing

Around 333,300 bytes per second can be transferred (sent and received).

Each transfer takes around 3 microseconds, and during that time one byte is sent from master to slave, and simultaneously one byte is received. Of course, the bytes may only be relevant in one direction, in which case the other one could be zero or something you don't care about.


Application


  • Programming the processor (in-circuit programming) in the case of the ATmega chips during startup
  • High-speed transfer of data (eg. Ethernet cards, SD memory cards)
  • Communication with other SPI-enabled devices (eg. LCD screens)
  • Communication between different processors
  • External memory chips, or IO expander chips


Notes

The raw SPI protocol does not guarantee that the data is being received. It could be going into "thin air". Nor is there any error checking (like CRC checks). You probably need to build some sort of acknowledgement and/or sumchecks into your protocol. For example, the receiver of data could echo back the received byte on the next transfer, and the sender could check that it got back what it just sent a moment ago. A better approach might be to echo back a "running sumcheck". Otherwise it would be possible for data to be lost and the sender not realize it. (For example, a non-existant slave might appear to be sending an 0xFF byte if the wire is pulled high by a resistor. Thus the master couldn't be sure if the slave was echoing 0xFF or just ignoring it).

On the Arduino Uno the following pins are used for SPI:


  • 10: SS (slave slect), however other available pins could also be used for additional slaves
  • 11: MOSI (master out, slave in)
  • 12: MISO (master in, slave out)
  • 13: SCK (serial clock)


The Arduino can be put into slave mode if necessary to communicate with an SPI master.

Due to the high speed of transfer, data would be limited to short cable runs.

More info

http://www.gammon.com.au/spi



Serial (RS232)



Wires

Two:


  • Tx (transmit data)
  • Rx (receive data)


For "hardware hand-shaking" other wires can be used such as RTS (request to send), CTS (clear to send), DSR (data set ready), DTR (data terminal ready).

The Tx wire of one end is wired to the Rx wire of the other end, and vice-versa.

For purely one-way communication (eg. output to a monitor) then only one wire would be needed.

Connectivity

Two peers. That is two devices are connected by connecting the send pin on one to the receive pin on the other, and vice versa. Both ends can transmit data independently of the other, whenever they want to. Historically a "computer terminal" would have a keyboard, which would send the typing from the operator, whenever that occurred, at the same time displaying data from the "mainframe" whenever that arrived.

Number of devices

Two.

Timing

Very dependent on the "baud rate" chosen. The RS232 is a "timed" protocol, so the transfer rate depends on the clock rate chosen. Typically it is some power of 2 multiplied by 300 (eg. 300, 600, 1200, 2400, 4800, 9600, 19200, 38400) bits per second. If the data format is 1 start bit, 8 data bits, no parity, and 1 stop bit (totalling 10 bits), then the data transfer rate is one tenth of the baud rate. So for example, if you chose a baud rate of 38400 then you could transfer 3840 bytes per second.


Application


  • Terminals connected to a computer
  • Devices like barcode scanners, RFID tag readers, LCD screens
  • Communication between different processors
  • Keyboards, mice, printers, etc. (although these tend to use USB these days)
  • Data loggers (eg. multimeters)


Notes


On the Arduino Uno the following pins are used for RS232 serial:


  • 0: Rx (incoming data)
  • 1: Tx (outgoing data)


More info

http://www.gammon.com.au/forum/?id=10894





Parallel



Wires

Often 10 or more:


  • 8 data bits (one wire per bit in each byte)
  • Clock (pulsed when data is to be transferred)
  • Acknowledge (pulsed when data has been received)


Possibly also:


  • Ready (active if receiver ready)
  • Out of paper (active if printer out of paper)
  • Read/write (for two-way communication)



Connectivity

Master to slave (eg. computer to printer).

Number of devices

Two.

Timing

Somewhat dependent on the rate at which the sender clocks out the data, and the receiver acknowledges it. As a guide, 5500 bytes per second could be achieved.


Application


  • Printers
  • Devices like LCD screens
  • Communication between different processors
  • Communication with special chips (eg. sending data to a memory chip)


Notes


On the Arduino Uno there are no particular pins dedicated to parallel communications.

Some LCD display boards implement a "4-bit" parallel interface where you send out half a byte (4 bits) followed by the other half. This is twice as slow, but requires less pins.


More info

http://www.gammon.com.au/forum/?id=10903

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


5,721 views.

Postings by administrators only.

[Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Web site powered by FutureQuest.Net]