I2C-Interface - Philips Semiconductors / NXP Semiconductors

Philips Semiconductors

12C Specific information Programming the 12C Interface

EMBEDDED SYSTEMS

When intedigent devices need to communicate

mgs-afforded by’robust se&l mterchip

T he Inter-Integrated Circuit Bus

protocols.

(“1% Bus” for short) IS a two-

wire, synchronous, serial inter-

face designed pnmanly for

commumcation between intel-

ligent IC devices. The 1% bus offers sev-

eral advantages over ,.traditlonal” seri-

al interfaces such as LMicrowlre and

RS-232. Among the advanced features

of 1% are multimaster operauon, auto-

matic baud-rate adjustment, and .‘plug-

Jnd-play ’ network extensions.

,Mention the 1% bus to a group of

Amencan engmeers and you’ll likely get

hit with an abundance of blank stares.

I say Amencan engmeers because un-

tll recently the 12C bus was pnmanly a

European phenomenon. Withm the last

year, however, Interest m I‘C in the

Unite ,d States has risen dramatIcally.

Embe tdded systems designers are real-

zmg the cost. soace. and Dower sav-

The idea of serial Interconnect be-

tween integrated clrcults IS not new.

Many semconductor vendors offer de-

vtces desIgned to ?alk” via serial links

with other processor. Current exampies

include Microwire (Xatlonai Semcon-

ductor), SPI (~Motorolaj, and most re-

cently Echelon’s INeuron chps. In all cas-

es, the goal is the same: to reduce the

wiring and pmcount necessary for a par-

allel data bus. It simply does not make

Mitch 1s a senior strategzc development

enguzeer for Intel and can be contact-

ed at 5000 W Chandler Blud.. Cban-

dler AZ 85226 or at mkabn@sedona.

zntel.com

Mitchell Kahn

economic sense to route a full-speed

Unfortunately for most serlal-bus-

capable devices, the choice of a bus

parallel bus to a slow penpherai.

protocol wdl dictate the CPU architec-

ture. For example, onlv two CPU ar-

chltectures implement an on-chip 1%

port. If your choice of architecture pre-

cludes use of these architectures, then

your only opuon IS to tmpiement the

protocol in software.

The sobare lmpiementatlon of the

1% protocol discussed m this article

came about as a result of an ~mphclt

challenge during a staff meetmg. One

of our managers proposed that we hire

a consultant to write a software 1% driv-

er tar the Intel 8OCl86EB embedded

processor. Being somewhat new to the

69

group. I took excepuon (although not

verballv!) to his suggestIon. .A weekend

of intense hacking later, I presented the

first prototype of the driver. My reward?

1 got to write a generic version of the

dnver for general distnbutlon.

Design Tmde-offs

Three distmct tasks are mvolved m im-

plementmg the 12C protocol: watching

the bus, waltmg for a spectiic amount

of time, and driving the bus. This be-

came apparent when I flowcharted 1

byte of a typical bus transaction: see

Figure 1. The time delays associated

with creatmg the bus waveforms would

normally have been relegated to the

8OCl86EB’s on-chip timers. I could not,

however. assume that the end users of

my code would be able to spare a urner

for the software 12C prt. I had to forego

the elegance (and to some extent ac-

curacvj of the on-chip timers for the

sledgehammer approach of software

timing loops. Luchlv, the IlC protocol

IS extremely forglvmg with regard to

ummg accuracv. The declslon to use as-

sembly tnstead of a high-level language

stemmed drectly from the need to con-

trol program-execunon time. I had ne;-

ther the tme nor the m&anon to hand-

tune high-level code.

Havmg made the decision to use as-

sembly language, I faced mv neaxt prob-

lem: Could I make the code portable?

Intel offers a plethora ot CPU and em-

bedded-controller architectures. Would

it be possible to make the code some-

what portable between disparate as-

sembiv languages? I found mv answer

m the use of macros.

Dr Dobb j-journal. _fune 1992

Philips Semiconductors

l*C Specific information Programming the i*C Interface

AH the basic bu1ldmg blocks of thj

I? protocol (watching, welting, and dc

In9 can be compartmentalized into dk

tmct macros. The algorithms that makl

up the IlC driver are written with thesg

macros as the fmmework. You don

need co understand the mtncac1es of thg

I? protocol to port these routines-

you just need to know how to makf

your CPU watch, Walt. and do.

For example, a 4,7_uS delay IS a corn

mon event during a transfer. The macn

%Wazt_4_ i_u.S implements lust such

delay by usmg the 8086 LOOP instruc

t1on with a couple of NOPs for tunmg

see Example l(a). Total execuuon t1mf

LS readily calculated from mstrucuon m

ing tables. The same macro IS ported t(

the 1960 architecture 1n Example l(b:

Although I am a neophyte when I

I I

Drive SCl_ Low ,

1

Assert Nth Data

51t on SDA

+7

Wad 2.35 pS

I. ,

No

comes to i960 programng, I hJd no

problems portmg the core macros.

Hardware Dependencies

A few word5 about the target hardware

are 1n order before I discuss the code.

Any 1mplementatlon of the I?C protocol

requires two open-drain (or open-col-

lector), bidirectional port pins for the

Serial Clock (SCLJ and Serial Data C SDA)

lines. The code 1n this article was de-

s1gned for the 8OCl86EB embedded pr@

cessor, which has two open-dram ports

on-chip. The two pms, ~2.6 ECL) and

P2.7 (SDA), are part of a larger &bit

port. Processon wIthout opendram I/O

ports can easdy implement I’C wKh the

addition of an eZxtemal open-collector

Iacch.

Two spec1aMuncuon registers, P2PIN

and P2LTCH. are used to read and wnce

the state of the port pms. The 8OCl86EB

allows the spec1aMunct:on registers to

be located anywhere m either memo-

ry or I/O space. For this 1mplementa-

non, I chose to leave the registers 1n

I/O space, even though this iimted my

choice of instructions. The 80186 ar-

chitecture does not provide for read-

modify-wnte instructIons 1n I/O space

(an AND to I/O, for example): 1t can

only load and store (IN and OUT?. So

why did I iirmt myself? Agam, I had to

assume the lowest common denoml-

nator for our customers when design-

1ng my code.

Building the Fmmewark

Early on 1n development. I decided to

parution my code macros according to

physical processes mvolved in the 12C

protocol. Code not d1rectiy mvoived m

lm&ng the acnons of a hardware 1%

port was not wntten as macros. For ex-

ample. the code necessarv to access the

stack frame IS not written as a macro,

whereas the code needed to toggle the

clock line is. Thus was done to Isolate

Architecturedependent code sequences

from the more generic 1% funcuons.

lMacros were also not used for ‘.gray ar-

eas” such as the shtimg of serial data.

which IS both architecture dependent

and physical m nature. The 1% func-

tions that passed the litmus test fell m-

to the three aforementioned categories

of watchmg, waiting, and domg.

The .walting” macros provide a fixed-

mm~mum time delay They are impie-

mented usmg a simple LOOP $ delay.

The LOOP instructIon decrements the

CX register, then branches to the target

(in thus case 1t.self3 tf the result 1s non-

zero. The delay 1s (n-1)*15+5 clocks,

where n 1s the starting value in the CX

register. All the delays were calculated

assuming a ~~-MHZ clock rate (62.5

nanoseconds per clock). The code still

works at lower CPU speeds because the

1% protocol only specifies mmimum

tlmmgs. In fact, the delay macros are

only ~‘accurate enough.” providing tlm-

mgs as close as I could get to the spec-

ified minimum without undue tunmg.

The “watching” macros are ‘spin-on-

bit” polling loops. These pieces of code

wait for a transItion on the appropnate

12C line to occur before allowing execu-

t1on to contmue. There are two polling

macros for each of the two I’C sIgna

lines; one for high-to-low transitions and

one for low-to-high transitions. The

%*DEFINE(Wait_4_i’_uS) i

IIWV cx, 5

loop $

nOP

noP

; 4 clocks

; 4*15+5 = 65 clocks

; 3 clocks

; total = 75 clocks

; 15 * 62.5ns = 4.69uS (close enough)

0-4

defme(Waltz_4_7_uS,’

Ob:

lda 0x17, r4

cmpdeco 0, r4

bne.t Ob

# instruction nay be Issued in parallel

# so assume no clocks.

# compare and decrement counter in r4

I if !=O branch back (predict taken

# brancn)

# ?he cmpdeco and bne.t Cogecher take 3

# clocks In parallel Cnmum.

#

# 0x17 (25 decxml) l 3 = 75 clocks

# at 16MHz :h~s 1s 4.69uS

Example 1: cu) 8OCl8G tmplementatzon oj.4 7_US utazt macro: (b) 8096OCA

implementation of 4 7-1~5 wazt macro

70 Llr Dobbs Journals June 1992

Philips Semiconductors

12C Specific information Programming the 12C Interface

polling of the SCL line that gives rise I

an importanc feature of 12C: automatit

bit-by-bit baud-rate adjustment. Any df

vice on the IzC bus may hoid the clot

line low m order to stall the bus fc

more rime (a serial wait state). The otl

er devices on the bus are then force

to poll the SCL line uric11 the slow d<

vice releases control of the clock.

The %Get_SDA_&t macro also fal

under the category of “watching.” 11

function is simply to return the state c

the SDA line without waiting for a trar

sition. %Get_SDA_Bit LS used pnmanl

to pull the serial data off the bus whe

the clock is valid.

The .‘domg” macros control the stat

of the clock and data lines. As with th

polling macros. there are four types-

one for each transition of the XL c

SDA lines. The .‘domg ’ macros ar

named to reflect the physical operation

they perform. For example, %Drzve

SCL_Low always drives the SCL line t

a low state. %Relea.se_SCL_Higb, on th

other hand, relinquishes control of th

SCL line, which may then be pulIed hig

or driven low by another device on th

bus. A read-modify-write operation I

used for the bit manipulation so mat th

other 6 bits of Port 2 are not affecte

by the 12C operations.

Getting on the Bus

Three procedures were created usm

the macro framework. I’ll describe or

ly the master transmit (Listing One, pag

I I

stop

Figure 2: Flowcba??jx- PC transmrt

procedure.

106~ and master receive functions (List-

ing Two, page 1081, as they represent

the needs of most 12C users. The slave

procedure is long and intricate and will

not be described here.

An 12C master transmission proceeds

a.5 follows:

I. The master polls the bus to see if it

is in use.

2. The master generates a start condi-

tion on the bus.

3. The master broadcasts the slave ad-

dress and expects an acknowledge

(ACK) from the addressed slave.

4. The master transrmts 0 or more bytes

of data, expecting an ACK following

each byte.

5. The master generates a stop condi-

tion and releases the bus.

The stack frame for the master trans-

mit procedure, I~CXA.A~~, includes a

far pointer to the message for transrms-

sion, the byte count for the message,

and the slave address. Far pointers and

far procedure calls are used in all the

procedures. No attempt was made to

conform to a specific high-level lan-

guage caUing convention, although such

a conversion would be trivial. The pro-

cedures save only the state of the mcxd-

shed segment registers.

The master transmit procedure per-

forms error checking on the passed pa-

rameters before attempting to send the

message. The maximum message length

is set at 64 Kbytes by the segmentation

of the 80186 memory space. This re-

strictton could be removed by mciud-

ing code to handle segment boundanes.

The transmit procedure also checks the

direction bit tn the slave address to en-

sure that a reception was not erro-

neously indicated. Errors are reported

back to the calling procedure through

the AK regrster. (The exact code is in

Listing One.)

The first step in sending a message is

getting on the 12C bus. The macro

oM~ec~_~or_Br&+-ee simply polls the

bus to determme if any transactions are

in progress. If so, the transmit proce-

dure aborts with the appropriate error

code. If the bus is free, a start condition

IS generated, The start condition is de-

fined as a high-to-low transition of SDA

with SCL high followed by a 4.7_uS

pause. These waveforms are easily gen-

erated with the %Dnve_SDA_Low and

% WaU_4_ 7-d macros.

All communication on the Ik bus be-

tween the stop and start condiuons, in-

cluding addresstng and data, takes place

as an &bit data value followed by an

acknowledge bit. This lead to the nat-

ural nested loop structure for the body

of the procedure: see Figure 2.

71

The inner loop IS responsible for

transmitung the 8 bits of each data byte.

Each transmitted bit generates the ap-

propriate data (SDA) and clock (SCL)

waveforms whiIe checking for both se-

rial wait states and potential bus colli-

sions. A bus collision occurs when two

masters attempt to gain control of the

lh-ee distinct tasks

are involved in

implementing the

watching the bus,

waiting for a specijiic

amount of time, and

driving the bus

bus simultaneously. The 12C protocol

handles collisions with the simple rule:

“He who transmits the first 0 on the SDA

line wins the bus.” To ensure that we

(the master transmit procedure) own the

bus, the SDA line is checked whenev-

er transmitting a 1. If a 0 is present, then

a collision has occurred (because an-

other master is pulling the line low),

and the transfer must be aborted.

Control is turned over to the outer

loop after the 8 bits of data (or address)

have been transmitted. The outer loop

immediately checks for an acknowledge

from the addressed slave. The transfer

is aborted if an acknowledge is not re-

ceived. At the end of the ACK bit the

message length counter IS decremented.

Control is returned to the inner loop if

more data remains, otherwrse a stop con-

dition is generated and the master mu-is-

rmt procedure terminates.

Registers are used for tntermediate re-

sult storage throughout the body of the

procedure. For example, the AH reg-

ister is used to hold the current value

(either address or data) bemg shifted

onto the SDA line. This elimmates the

need for local data storage within the

procedure.

On the Receiving End

The steps involved in an I’C master re-

ceive transaction are almost identical to

those in transmission:

1. The

is in use.

2. The master

master the bus to see tf it

generates a start condi-

L3 Dobbk Journal June 1992

Philips Semiconductors

12C Specific information Programming the 12C Interface

non on the bu5

j The ma5ter broxica5ts the 5iave ad-

dress md aspects XI ‘\CK from th

.iddre55ed slave

+ The master recene5 0 or more bvte

ot dam and \ends <m XK to the >lav

Jtter each Me. The ma5ter signal

the bdst bake bv not 5endmg an ,\Ch

5 The ma5ter generace J \cop cond

non &md reiea5e5 the bus

.I far pointer to the receive butfer I

pasxci on the stack to the ma5ter rc

cetve procedure. The remainder ot th

pammeter5--slave addres5 and me>

sage count-xe ldentlcai between th

~0 procedures The received me55ag

length 15 fiixed At 6+ Kbvtes. +qun bt

c3use of 5egmentation The error-chech

mg, bus-a~~aMxi~tv >ensmg, Jnd \tan

condltlon generJtlon sectIons ot th

receive procedure xe lifted verbxlr

from the tran5mlt code

The structure of the receive proce

dure differs 5hghtly once the start con

b. I

I-

51

I Start

Byte = l*C address,

No ACK Send ACK

1

Byte ++

N=l

93

stop

Figure 3: Flowchar? Jor IX receufe

procedure

&Ion hss heen generated. 5ee Fqglre

3 The 5b~ve -1ddresa IS tran5mltted u5-

mg one iteration ot the rran5mlt proce-

dure5 outer loop Control 15 pa\5ed to

the receive loop once the 5lave dcknow-

ledges Its addre5s

The receive Imp 5tructure 15 patterned

&er that of the trdnsmlt procedure. The

Inner loop controls the Ltockmg of the

SCL line and the 5hlhq ot rhe 5txxdl do-

ta otf the SDA lme Into the CPU Eight

LteKlhons ot the mer loop are performed

ro receive each bvte The outer loop

>tores the received bate II-I the buffer.

decrements the byte count, then sencL>

an XK to the slave. The la5t data byte

IS sqgaited by not 5endq an ACK

Using the Procedures

Ll5tmg Three (page 110) \hows J short

progrxn that u5e5 both the ma5ter trxx-

rnlt and tnaster receive procedure5 The

cxil to procedure IX_XMT dlspiavs tie

lvord ‘WS-” on a four-character. 5ev-

en-segment dl5piav controlled bv the

%A1064 1% compatible dispiav driver.

The time of dav IS read tram the

fYFS%3 real-time clock by the cait to

procedure IX_RECV

Please note that Interrupts must be

di5abled durtng the execution ot both

procedures. .&n mterruptlon at an m-

oppomme time c when the ma5ter IS not

In control of the clock) could cause the

bus to hxq It you need to service m-

terrupts perIodically, then enable them

only when the clock 15 driven low.

These procedure5 have heen rested

on a wide armv ot 1% device5 mngmg

trom senat EEPROMs to vow svnthe-

slzer5. .So compatlbllitv problems have

heen seen to date.

Enhancing the Code

l’w kIcked around many &25 for en-

hxxxng the 1% procedures. ‘t’ou could.

All the basic

building block oj*

the 12Cprotocol

(watching, waiting,

and doin& can be

compatimentalized

into distinct macros

for example, replxx the tmimg loop5

\vlth umed uxemipt5 That wry, the CPL’

could perform useful work durmg the

pxi5es .&iong the 5ame ime5. the paus-

es could be scheduled using a real-

time kernel, agam improvIng CPti

throughput. Flnaltv, vou could add a

hgh-level language calling 5tructure.

The u5e of tImed mtemlpts Jdd5 an

order of magnitude to the complextv

of the code, but n,ould be worth It for

high-pertormance. real-time 5ystems.

Conclusion

1% IS not the onlv game m town when

In comes to serial protocols. HopeMy,

some ot the technques presented here

wil carry over Into the development of

other ,xmuiated” senai protocols, such

JS those targeted at the home-automd-

tlon market. Who knows, maybe some-

dav J snippet of mv code mdv find 1t.5

way Into a trulv Intelligent dishwasher.

I’ll be waltmg

References

Z2C Bus SpeczJic~~twz. PhIlips Corpora-

tion c undated)

Reprinted with permission of Dr.

Dobbk Journal, 1992

Entwe ccmfeflts copyright * 1992

by M6T Pubitsh#ng, IX

unless otnelwlae notao o” 3peclflC artIclea.

All rights resected.

Philips Semiconductors

a North American PhIlIps Company

811 E. Arquas Avenue

P 0. Box 3409

SurtnVvale, Callfornta 94088-3409

72

l*C Specific information Exploring l*C

S erial data buses are a well-

proven tool in embedded

systems. When you are com-

municating with slow per-

ipheral devices, serial buses

are often often more convenient and less

expensive than parallel buses. Addi-

tionally, a serial interface featuring a

UART or similar intermediary chip

can also serve to isolate the CPU from

noise and line glitches that might bring

down the house if they were to occur on

the prczessor bus. Peripherals can usu-

ally be controlled over a much greater

distance by a serial bus. The serial ap-

proach offers greater

noise immunity. resilience and

The price you pay for the conve-

nience is a slower transmission rate and,

possibly, the need for added interface

circuitry at higher voltages. Many pr-

ipheral devices, however, are not in con-

stant communication with the CPU and

are not greatly affected by a slower bus.

On the hardware side, any added inter-

face circuitry required for serial-bus

support is frequently compensated for

by the resulting simplicity and

pinout of the serial peripherals. tighter

CHOOSlN6 THE PROPER ROUll

H aving decided that a serial bus

makes sense for your applica-

tion, your next task is to select

the most appropriate bus and protocol.

Here, as with rapid transit, your choice

should be determined by your destina-

tion. Contrary to what some people may

tell you, the choice of bus and protocol

depends at least as much on the nature

of the system’s software as it does on the

manufacturer’s data sheets.

Consider, for example, the serial-pe-

ripheral interface (SPI) and multidrop

The choice of bus

and protocol

depends at least as

much on the

system’s software

as it does on the

manufacturer’s

data sheets.

serial buses. Both buses are popular, but

each exhibits severly constrained per-

formance in large networks. SPI, as em-

bodied in the Motorola 6800 family,

was designed primarily for one-on-one

exchanges between two devices. Simi-

larly, the multidrop approach used in

various 805 I family members as well as

in the 68HC 11 and various UART

chips hnds its broadest expression in

RS485/422 halfduplex transmissions.

Multidrop has no deterministic arbitra-

tion scheme between multiple masters,

leaving it mainly suitable for single-

master multiple-slave situations. (For

more on multidrop, see Jack Woehr’s

article, “Multidrop Processing, ” Em-

bedded Systems Programming, March

1990, pp 58-67-ed.) A different ap-

proach is to use a three-wire protocol

called MicroWire, available from Na-

tional Semiconductor in Santa Clara.

Calif., which is fine for use with addres-

sable peripherals, but requires an indi-

vidual chip select for each device ad-

73

lips Semiconductors

l*C Specific information Exploring l*C

Exploriizg

IC 2

dressed. The added wiring offers no

advantage to developers, and the bus of-

fers nothing towards achievmg multi-

pie-mastermg capabilities.

One of the more versattle options

available to developers IS the PC bus

promulgated by Philips/Signetics m

Sunnyvale. Calif. IT allows you to set

up a multtple-master. multiple-slave

commumcattons bus wtth conflict arbi-

tration. usmg only twtsted-patr wirmg

to connect the processors and peripher-

als. Philips/Signettcs has moved tosup-

port this protocol (which is quote popu-

lar in Europe) with a large assortment

of interesting doodads. and is actively

Figure 1

Generation of acknowledge.

---v- ---

_.- - B - - - -

Open-collector

configuration

means that the

output stage can

only pull the node

to ground.

encouragmg other manufacturers to

jotn m the fun. If your next design fea-

tures a mrcroprocessor that supports

PC or you are prepared to implement

PC in software using a PIA as this arti-

cle illustrates. your reward could be a

decreased chip count and lower power

consumption-along wtth a comfort-

able distributed-programming model

for peripheral devices.

PC is more flexible than the proto-

cols noted above. since only two wires

are required to service a large network

of addressable masters and addressable

slaves. A third wire may be added if in-

terrupt service is required. though Phi-

lips/Signetrcs mrcroprocessors featur-

ing PC support feature on-chip cir-

cuttry and are capable of interruptmg

the processor upon receipt of a valid

address.

HOW 1% WORKS

T he PC bus consists of two lines:

serial clock (SCL) and serial

data (SDA). The beauty of the

PC bus is that each of these lines is bi-

directional. Bidirectional means that

everything on the bus 1s equal, unlike

most other serial-peripheral busses such

as SPI or MicroWire, which have dedi-

cated inputs and outputs. Each PC

transaction line (SCL and SDA) is an

open collector of output and input. The

74

Philips Semiconductors

l*C Specific information Exploring l*C

pullup reststor is external.

Open-collector (actually, they are

CMOS. so &open dram” is more appro-

priate) contiguratron means that the

output stage can only pull the node to

ground. A passive resistor pulls the node

high, which means that any number of

open collector outputs can be connected

together with no deiiterious results. be-

cause tt IS impossible to pull more cur-

rent through the reststor than any one

output will produce. Tying outputs to-

gether will produce disastrous results if

the same procedure is tried with stan-

dard TTL outputs. If some of the out-

puts go high and some are low. the cur-

rent IS unlimited and the logic level of

the output ~111 be in an indetermmate

state. Tying open-collector outputs to-

gether is also known as “wtre ORmg” be-

cause if either A or B goes low, so does

the single-output line.

The PC bus speed is specified at a

maximum SCL rate of 1OOkHz SCL,

which, admittedly, is not blazingly fast.

The speed limit stems from the meager

ability of a pullup resistor to source cur-

rent to a long distributed line of pert-

pherals. The lo-microsecond period al-

lows plenty of time to charge the

parasitic capacitance of the wires. (The

maximum spectfied wtre capacttance ts

400 pF.1

PUITING IT TOGETHER

A Ithough FC supports multi-

ple-master operation, here we

use single-master, single-slave

transactions to keep the example code

simple. The master. as you might imag-

me, IS defined as the unit that initiates

the data transfer and generates the

SCL srgnal. (In a multimaster system,

each master would be responstble for

generating its own SCL signal.) In our

exampIe. based strongly on the destgn of

one of our company’s smgle-board com-

puters, the processor doesn’t directly

support I’C. Instead, we’ve implement-

ed the IX bus using a couple of the pins

on an 8255 peripheral L/O chtp. Conse-

quently, the bufk of the example appii-

cation code 1s simple setup and house-

keeping routines. (Steven R. Wheeler’s

example appiicatlon iistmg was a bit

too long to run in this issue. interested

readers may download It ,fi-om the li-

brar,v 12 of CLMFORUM on Compu-

Serve or j-om the Embedded Systems

Programmmg bulietm board service at

(415) 905-2689-ed.1

By definition. a slave can be any pro-

cessor or peripheral that responds to the

master. Slaves all have unique, 7-bit ad-

dresses that are based on the device type

and the wiring of address pins on the

chip. All I*C peripherals have the top

nibble of an address built in. For the

PCFgj74 I/O-port expanders we’re us-

Figure 2

Start and stop conditions.

SDA

SCL

Start stop

75

Philips Semiconductors

l*C Specific information Exploring l*C

Expbriig

IC

2

ing as examples, the address is OlOOxxx.

The xxx indicates the address selected

by the state of the three address pins on

the peripheral.

PC serial transactions are always

eight bits of data from the transmitter

followed by a ninth ACK bit from the re-

ceiver. The first step in any PC data

transfer is to send the address of the

slave on the SDA line. This act might

seem confusing, since we seem to be

mixing 7-bit addresses with g-bit data.

In practice, it’s quite easy to work with:

addresses are always seven bits long,

and the eighth bit is used to determine

whether the operation is a read or a

write. For example, upon transmitting

01ooo0O1 to the PCF8574, the slave, as-

suming it exists on the bus and is

strapped to address Ooo, will respond

with a low on the SDA line after the

master has finished with its last (eighth)

data bit. The master leaves the line

high. If it doesn’t find a slave with ad-

dress 10000, the data line ~111 remain

high and a failed communication at-

tempt can be detected.

If a slave is connected, it begins put-

ting data on the SDA line as soon as it

has detected that the eighth bit is set

(which is a read request). The SDA line

is driven to the data level when the SCL

line is low. Data is read when SCL is

high, so SDA must not change when

SCL is high. This protocol leads to a

simple definition of the start of an PC

transaction-SDA goes from high to

low when the clock is high.

The end of a transaction is equally

simple to detect: SDA goes from low to

high when SCL is high. This cycle

leaves SDA and SCL in the high state,

which is necessary if any other open-

collector PC peripheral wants access to

the bus. Figure 2 illustrates the start

and stop conditions of an FC bus

transaction.

ADDITIDNAL DESIGN RDDTES

A s you’ve seen, the PC protocol

is easy to work with and rela-

tively simple to implement,

even if you’re not using a processor that

directly implements it. If you’re not

planning to use Philips/Signetics mi-

croprocessors with onboard PC support

(such as the 68070 or various members

of the 805 1 family), you can still use the

wide variety of available peripheral

chips.

The number of integrated circuits

using the PC serial bus is increasing all

the time. Application-oriented inte-

grated circuits that support PC include

a voice sythesizer, a transc&er for IR

remote control, several digital tuning

circuits for computer-controlled televi-

sion, several audio processors, PLL fre-

quency synthesizers, tone generators,

and frequency synthesizers. General-

purpose integrated circuits using PC in-

clude LCD drivers, digital-toanalog

converters, SRAMs, EEPROMs, and a

RAM clock/calender.

PC is very popular in Europe, where

Philips has been aggressively marketing

this flexible method of extending pe-

ripheral support to control projects, and

it is currently catching fire on this side

of the Atlantic. It seems reasonable to

expect that, given the burden of printed-

wire requirements for embedded sys-

tems based on increasingly wider chip

buses, more and more designers seeking

economy of means will be attracted to

the economy of PC.

Steven Sarns is the president of Vesta

Technology in Wheat Ridge, Cola, He

is a member of Mensa, Intertel, and the

Michigan Society of Professional En-

gineers. Sarns is also a founding mem-

ber of the Denver chapter of the Forth

Interest Group.

Jack Woehr is a senior project manager

at Vesta Technology Inc, in Wheat

Ridge, Colo. He is a Chapter Coordin-

atorfor the Forth Interest Group and is

currently a member of the X3Jl4 Tech-

nical committeefor ANS Forth. He can

be reached by E-mail as jax@wll.sf

.ca.us or as VESTA on GEnie.

Reprinted with permission from

EMBEDDED SYSTEMS PROGRAMMING, September 1991

0 I991 MILLER FREEMAN PUBLICATIONS

76

Philips Semiconductors

l*C Specific information Bit-Banging Serial Ports

Bit-Banging

Serial Posts

T hey say that necesstty IS

the mother of inventron.

and it certainly seems to

be the case in embedded

systems work. No sooner

do you accomplish the tmposstble in one

project than your boss or customer asks

you to do it agam, only faster and

cheaper this time. Even when you’re

working with low-cost mtcrocontrollers.

there’s still that mcenttve to make

things cheaper through magtc software.

Performmg mrracies through soft-

ware trickery IS a skill that a11 embed-

ded developers must cultivate. An op-

portumty for me to practice such tricks

came m the form of a project using the

Signettcs 8x75 I mtcrocontroller. The

8x75 1 is an 805 1 dertvattve that has no

internal serial port-no attachment of

SBUF shift registers to RxD and TxD.

no diverston of timers to baud rate pac-

mg, no serial interrupts. But the chip is

low-prtced and offers a small-fcotprmt,

and hence IS desirable in many applica-

ttons. Where the price or size outweighs

the need for a simple sertai port, one

must be butlt out of firmware by appro-

priately controlling a single bit m a port.

The practice is affecttonateiy known as

tibu-bangmg.”

The approach I’ll describe here has

the advantages of being simple and fast.

There is no transmtt state-machine, no

spectai provtston for start and stop bits.

2nd it takes less than two dozen ma-

chine cycles for each bit. It has a further

Advantage that the data doesn’t need to

be specrafly orgamzed for transmtttmg.

That 1s. the bits that are adjacent m the

transmit data stream don’t need to be

adjacent when they are stored m mem-

ory. This soiutton IS for a transmttter

only, but I have used a stmtlar procedure

for receiving.

The shift (or

rotate) operation

is the first thing

that comes to

mind when you’re

designing code to

provide a serial

data output.

My project was required to operate

dt 9600 baud. This rate gives a per-bit

time of 104 mtcroseconds. or IO4 cycles

if you’re using a 12-AMHz part. The ap-

plication in question had plenty of other

acttvtties as well as a sertal port (such as

reading a serial analog-to-digital con-

verter. performing averages. and so on ),

so it was imperative that the sertal port

handling take an absolute munmum of

ttme. Since I chose to execute in a tixed-

time ioop (to avotd interrupt overhead),

rt was dfso a godi that the code take a

fixed amount of time regardless of the

current transmrt state.

THE STRUCTURE POINTER SOLUTION

G enerally, the shift (or rotate)

operation is the first thing that

comes to mind when you’re de-

signing code to provtde a sertai data out-

put-the format of the data suggests

such a scheme. With this approach.

however. special states and a counter are

needed to provide the start and stop bits

dnd to sequence through the set of bytes

77

to be transmitted.

The method presented here provides

an array of structures (in the cede or

PROM space) that defines the transmit

sequence bit by bit and uses a pointer to

this array as the only controlling eie-

merit. This means that only two bytes of

scarce internal RAM is used.

Philips Semiconductors

i*C Specific information Bit-Banging Serial Ports

The structures are referenced con-

secutlvely. Each gves the source of a bit

to be transmitted and a flag to indicate

whether the pointer should be increased

to point to a new bit. The transmission is

terminated by having a structure that

refers to an *idle” bit and does not in-

crease the pointer. Transmission is initi-

ated by changing the pointer to point to for the work described here. The 8x75 1

the first structure. Start and stop bits does not support external RAM. so the

are not distinguished from data bits. small model is used. (If the transmit

The bit update prtion of the code is data resided in external RAM. the algo-

constant-time, and the pointer update rithm could be applied, but would be

can be easily padded if necessary to expected to take a little longer to

achieve this part of the goal. execute.)

Franklin’s C5l compiler was used THE DECLARATIONS

T he structure that provides indi-

vidual bit definitions is:

// tranat bit-reference structure

struct BR ;

unsigned char Index :

unsigned char mask :

unsigned char bump :

No memory is allocated by this defini-

tion-it is essentially a typedef. The ac-

tual allocation and initialization are

provided by the definition (in a header

file, send _ seq.h, in this case) of the Bit-

Refarray:

code struct BR BitRef[41] = ’ 1 ;

wherethedetails will be given in a mo-

ment. The pointer is defined as:

I/ pointer to BitRef structure array

data struct BR code *BR_ptr

In Franklin’s C5 I, the declaration

tokens are interpreted as follows. In the

struct BR declaration. the token code as-

signs the BitRef array to program mem-

ory (which is then accessed with themovc

instruction).Inthe *BR_ptrdeciaratIon,

the token codeimpliesthatBR_ptrisex-

cluslvelya pointertotheprogramspace.

so~trequiresonlytwo bytes to becom-

pletely defined. The token data causes

the compder to store the pointer value m

7a

Philips Semiconductors

l*C Specific information Bit-Banging Serial Ports

internal RL41M. (Since I was using the

small model, this would have been the

default storage anyway.)

The Index entry in each structure al-

lows the serial bit to be selected from an

array of bytes called transmlt[4] in my

case. The transmtt array can. if desired,

be set up to literally overlay all of the

internal memory, so that the maximum

&random access” can be achteved. This

was not necessary in my c3se.

The physical port pm to be exercised

IS defined:

/* transmit 1s on P3 3 *I

sblt TransBlt = OxB3

THE STRUCTURE INITIAMATION

E ach bit to be transmrtted is de-

fined by an index and mask.

These are irntiaiized rn the Bit-

Ref structure so that characters can be

formed as desired in the output btt

stream. The index IS the offset wtthin

the transmit array. The mittaiizatton n-r

my case, for a sequence of 40 bits mak-

ing up four characters. was:

code struct BR 8itRef[41] = ,

11 index mask bump comnent

3 b01000000 1. I 0 start bit

'I b00000001 , I, /'I 06

1 b00000010 I, I/ 07

1 b00000100 I, f/ 08

1 b00001000 1. 1 09

1 b00010000 1. /I 010

1 b00100000 1. I/ 011

3 b10000000 I, (1 1 fixed

3 b10000000 1. '1 1 fixed

3 b10000000 I, / 1 stop bit

3 b01000000 I, '/ 0 start bit

3 , b01000000 , 1. I/ 0 fixed

3 b10000000 1. /I 1 stop bit

3 b10000000 0 /I 1 idle bit

(The *‘masks- are given in binary nota-

tion. [See “.A Binary Upgrade jbr C, ”

pp. 60-62.-Ed.] Because of my assem-

bler and hardware background. thts no-

The “bump” is a

flag that continues

the transmission.

When it finally

reaches 0, the

serial output

sequeflce will

stop.

tation 1s natural for me tn bit mask

references.)

The *‘index” refers. as menttoned. to

the element of “transmit” in which the

bit restdes. Some mitializatton code has

guaranteed that the upper two bits of

transmlt[3] wtll be IO. so that they can

be referred to for start and stop bits and

for any tixed-vaiue bits that happen to

be m the data stream (in my case, the

fixed bits are used to indicate data byte

order).

The *bump” IS a flag that continues

the transmtsston. When rt IS finally 0,

the serial output sequence ~111 stop.

THE CODE

T he code fragment that accom-

plishes the transmtssion IS:

(a) VansBit =

(bit)( transmit[ BLptr-1index ]

8 BLptr-)mask )

(b) if ( BR_ptr-)bump )

BR_ptr++

The program sequence for sectIon (a)

looks like this:

BR_ptr-1index

-- looks up current index, then used in

transmit[index]

-- to get byte with desired bit.

then ANDed with mask

BR_ptr-)mask

-- to get zero~nonzero value. which

(bit)(value 8 value)

-- 1s then cast to a bit for output

TransBlt = bit

-- to port pin, the ultimate goal.

The pointer IS lncrcdsedin (b),depend-

tngon the value of BR__Ptr-jbump. 2~s in-

dicated earlier. this is aiwavs one except

in the last structure, so the serial trans-

mrsston always proceeds to the defined

end. The statement:

BR_ptr = &BitRef[40]

in lnitiaiization ~111 keep the transmtt-

ter off durmg startup, and:

BR_ptr = BitRef

IS used to initiate a transmtssron

sequence.

79

Philips Semiconductors

12C Specific information Bit-Banging Serial Ports

The previous transmitting code corn-

plies. with only a Me manual assls-

tance, to:

The assembly language code reveals

that the mechamsm is pretty efficient.

This method is in use in one of my cli-

ents’ prducts and has proved effective.

TransEit = (bit)( transnnt[

BR_ptr-Findex ] 8 BR_ptr-Unask )

WV DPL.BR_ptr+OlH

MIV 0PH,Bfl_!~tr

CLR A

WC A.@A+DPlR

GlT4ANGlNG WGGKS

T his bit-banging solution serves

to provide serial transmission m

an embedded system that has

no hardware specifically dedicated to

[he function. Though alternate and