I2C Protocol Subtiliteter – Del 1

I

Denne artikkelen er den første i en serie som beskriver de mer “subtile” aspektene ved I2C-protokollen, opprinnelig utviklet av Philips.

Siden du leser denne serien, antar jeg at du allerede vet hva I2C-bussen er, og du ønsker å unngå smerte når du trenger å bruke den i et prosjekt. I så fall har du kommet til rett sted. Hvis ikke, vil jeg snart legge til litt introduksjonsinformasjon om I2C på nettstedet mitt.

Bare så vi er klare, vil denne serien ikke inkludere dekning av høyhastighetsmodusen, siden denne er vesentlig forskjellig fra utformingen og oppførselen til den vanlige 2-tråds delte bussimplementeringen, og den er heller ikke så vanlig. Det er massevis av utmerket referansemateriale tilgjengelig på nettet som dekker denne modusen.

Her er en rask liste over hva som vil bli dekket i resten av serien:

  • mangler START
  • mangler STOPP
  • Gjentatt START
  • manglende databiter
  • mangler ACK/NAK
  • data etter NAK
  • rygg mot rygg feil
  • pullup motstander
  • bussrepeatere
  • implementering ved hjelp av en full-hardware TWI eller I2C periferutstyr
  • implementering ved hjelp av en USI-tilbehør
  • implementering ved hjelp av en USART-tilbehør
  • SMBus-forskjeller fra I2C

Nå, over til de gode tingene!

For denne artikkelen vil vi fokusere på de 3 typene implementeringer du finner i design i dag: full maskinvare, maskinvare/programvare-miks og full programvare (eller ‘bit-bang’ som det noen ganger kalles).

Mange mikrokontrollere i dag, til og med noen low-end-enheter, inkluderer en full-hardware I2C periferiutstyr. Atmel refererer til deres som TWI, Microchip kaller deres I2C; andre leverandører bruker lignende navn. Når du bruker en fullstendig maskinvaretilnærming, er det faktisk vanskelig å generere noen form for bussfeil med mindre du misforstår hvordan periferutstyret fungerer eller hvordan en korrekt I2C-busssekvens skal se ut. Generelt krever imidlertid denne tilnærmingen den minst inngående forståelsen av selve protokollen.

USI-tilbehøret som finnes i noen Atmel-enheter er et minimalt maskinvaredesign som avhenger av programvareinteraksjon for å gjøre det til en komplett implementering. Dette allsidige periferutstyret kan faktisk brukes til I2C-, SPI- og UART-konfigurasjoner, og er egnet for low-end-enheter der det å legge til alle tre periferiutstyret vil være uoverkommelig. Selv om det krever mer koding enn en TWI eller full-hardware I2C periferutstyr, er det på noen måter mer fleksibelt. Denne tilnærmingen krever en mer dyptgående forståelse av protokollen, da du er ansvarlig for å flytte fra en tilstand til den neste, og det er mulig å gå i feil retning.

Til slutt krever implementering av en 100 % programvaretilnærming en full forståelse av I2C-protokollen. Praktisk talt hver mikrokontrollerleverandør gir applikasjonsnotater og kodeeksempler for å lage en I2C Master-enhet ved å bruke en ren programvareløsning. I motsetning til en UART, er I2C en klokket (i stedet for tidsbestemt) protokoll, så avbrudd i utførelsen av protokollen tolereres godt, slik at avbrudd kan betjenes uten bekymring for tap av data. Den maksimale hastigheten til den programvarebaserte løsningen bestemmes til syvende og sist av CPU-klokkehastigheten, og vanligvis kan en Master-implementering lett nå 400KHz-hastigheten.

En programvarebasert implementering av en Slave-enhet er mye mer utfordrende. Uten maskinvarestøtte må programvaren overvåke både SDA- og SCL-linjene samtidig for å oppdage klokkekanter og kjenne positivt til tilstanden til SDA-linjen før stigning eller fall av SCL. Deteksjon av en START- eller STOP-tilstand vil vanligvis kreve bruk av avbrudd, ellers må programvaren forbrukes 100 % med overvåking av SCL og SDA. Programvarebaserte slaveimplementeringer har en tendens til å være CPU-bundet, og krever flere MIPS for å oppnå til og med 100KHz-drift. Derfor kan det hende at ekte programvare-bare slaveimplementeringer ikke engang eksisterer for noen mikrokontrollerfamilier, og andre kan kanskje ikke nå full 100KHz busshastighet.

Etter at dette hardware- og programvaregrunnlaget er lagt, vil vi dykke dypere inn i selve protokollen i vår neste artikkel. Takk for at du leste!

(Copyright 2010 Robert G. Fries)

About the author

Add comment

By user

Recent Posts

Recent Comments

Archives

Categories

Meta