I²C & Bit-Shifting

English version.

In letzter Zeit wurde ich häufiger über I²C, beziehungsweise dem damit oft einhergehenden Bit-Shifting gefragt. Konkret meine ich damit den Code der OLED-Lib und dem des Wii-Nunchuk. Beide Geräte unterstützen den I2C-Bus, welcher Thema dieses Eintrages ist. Als Antwort habe ich meistens eine kurze Erklärung, sowie den Verweis auf den Wikipedia-Eintrag zu I²C gegeben. Hier will ich aber etwas genauer darauf eingehen, wie man I²C und Bit-Shifting tatsächlich auf mehreren Controllern nutzt.

setup

(Sorry für das schlechte Bild, hatte im Moment nur meine Handykamera)

Entwickelt wurde der BUS in den 80ern von Phillips. Der genaue Name lautet Inter-Integrated Circuits Bus (IIC), woraus schnell die Abkürzung I²C (i squared c) wurde. Oftmals liest man auch die Abkürzung TWI, diese steht für Two-Wire-Interface. Die Grundzüge sind:

  • Jedes Gerät hat seine eigene 7-bit Adresse. Dies bedeutet es können bis zu 2^7=128 Geräte angeschlossen werden.
  • Eine genaue Taktgeschwindigkeit, um die Daten senden/empfangen zu können.
  • Zwei Leiter, SDA, welcher den Takt vorgibt, und SCL, die Datenleitung.
  • Einen Master, welcher den Takt vorgibt und den Bus administriert.
  • Mehrere Slaves, welche dem Master unterliegen.

Es kann auch mehrere Master geben, Zugriff auf den BUS hat aber immer nur einer, weshalb man sich bei der Verwendung mehrerer Master etwas überlegen muss, damit jeder darauf zugreifen kann – Stichwort: Multi-Master.

Der elektrische Aufbau

Für dieses Beispiel nutze ich die folgenden Bauteile:

Stk. Komponente Ausführung Beschreibung
1 Arduino UNO Master
2 Arduino Nano Slave
2 Widerstand 1kΩ I2C Pull-up
2 Widerstand 220Ω Vorwiderstand LED
1 Widerstand 10kΩ Taster Pull-down
1 Potentiometer 10kΩ
1 Taster

Der folgende Schaltplan zeigt, wie der Aufbau aussehen soll. Wichtig ist, dass man hier nur das Arduino UNO mit Spannung über den USB-Port, den VIN-Pin oder den 7-12V-Anschluss versorgt. Die beiden Nanos dürfen mit keiner externen Quelle versorgt werden. Der Grund ist, dass man mit diesem Aufbau die Schutzmaßnahmen, sowie die automatische Wahl der Versorgung der Boards umgeht. Des weiteren sollte man in diesem Aufbau an keinem der Boards zu viele zusätzliche Geräte anschließen, da alles über den +5V-Pin des UNOs versorgt wird. Der Aufbau ist für dieses Beispiel konzipiert.

shematic

Wer mehrere Geräte an die Powerline (+5V) anschließen will, muss eine zusätzliche 5V-Versorgung verbauen, welche genung Strom für alle Geräte liefert und außerdem in jedem Fall einen stabilen Output hat. In diesem Fall darf man auch das UNO nicht mehr extern mit Spannung versorgen. Will man das UNO (in diesem Fall den Master) dennoch mit einem USB-Gerät kommunizieren lassen, so muss man auf einen externen FTDI-Adapter zurückgreifen, wobei man ihn dann nur mit RX, TX & GND des Masters verbinden darf. Die Logik des Aufbaus folgt dann dem folgenden Schaltplan:

shematic_2

Die beiden Pull-up Widerstände werden gebraucht, weil der BUS LOW-active ist. Das bedeutet, dass die Daten nicht durch eine 1, sondern durch eine 0 dargestellt sind (ähnlich zu einem Bar-Code, wo die weißen Balken die Daten repräsentieren). Die meisten erhältlichen I2C-Geräte haben die Widerstände bereits verbaut, weshalb man sich darum keine Gedanken mehr machen muss.

Der Code

Wie immer findet man das Programm auf GitHub.

Dort findet man drei Verzeichnisse: Master, Slave_Reader und Slave_Writer. Die Idee meines Beispiels ist, dass der Master Daten vom Slave_Reader anfordert und diese dann dem Slave_Writer zur Verfügung stellt. Diese Daten sind der digitale Wert eines Taster und der analoge Wert eines Potentiometers. Der Ablauf sieht wie folgt aus:

  • Der Master stellt einen Request an den Slave_Reader.
  • Der Slave_Reader bekommt diesen, nimmt die Daten auf (digitalRead() & analogRead()), konvertiert diese und schickt sie dem Master.
  • Der Master konvertiert die Daten und schickt sie an den seriellen Monitor, damit man sie am PC lesen kann.
  • Als nächsten Schritt schickt der Master die unkonvertierten Daten an den Slave_Writer.
  • Dieser erhält die Daten, konvertiert sie und bringt zwei LEDs entsprechend zum leuchten.

Mit dem Wort „Konvertierung“ meine ich Bit-Shifting. Doch was ist das?

Bits & Bytes

Um zu vertstehen, warum wir Bit-Shifting benötigen, muss man wissen, dass der I²C-Bus maximal ein Byte größe Nachrichten versenden kann. Man kann zwar mehrere 1-byte-Nachrichten hintereinander schicken, doch eben nur nacheinander. Ein Byte ist acht Bits lang, und ein Bit repräsentiert den kleinsten möglichen Zustand auf einem Rechner (sei es nun ein Mikrocontroller oder PC).

Als binäre Zahl dargestellt ist ein Bit also entweder eine Null oder eine Eins. Als Variable auf dem Mikrocontroller wird ein Bit als bool-Variable dargestellt (1-0, true-false, HIGH-LOW). Ein Byte ist wie bereits bekannt eine Kette aus 8 Bits, die daraus resultierende höchste Zahl ist 255. Wem das Konzept der binären Zahlen fremd ist: Es folgt ein kurzes Beispiel:

Die Zahl 0 als Byte dargestellt wäre eine einfache 8-stellige Kette aus Nullen: 00000000. Sind alle Stellen mit Einsern belegt, so ergibt sich die Zahl 255, oder eben 11111111. Die Zahlen dazwischen ergeben sich über die Summe aus 1 & 0 mit der folgenden Logik:

2^7=128 2^6=64 2^5=32 2^4=16 2^3=8 2^2=4 2^1=2 2^0=1 Summe
0 0 0 0 0 1 1 1 7
1 0 1 0 1 0 1 0 170
1 1 1 1 0 0 0 0 240

Nun lässt sich auch erkennen, warum es binäre Zahlen heißt; das Produkt resultiert immer aus der Potenz mit Basis 2. Des weiteren ist das Bit rechts immer das mit dem niedrigsten Stellenwert (least-significant-bit lsb) und das Bit links mit dem höchsten (most-significant-bit msb). Auf diese Weise können alle Zahlen dargestellt werden, man benötigt lediglich genug Bits. Daher stammt unter anderem die Namensgebung des 64-Bit-Betriebssystems. Mit solch einem Prozessor können 64 Bits (8 Bytes) gleichzeitig berechnet werden. Als Zahl betrachtet sind das 2^64=18446744073709551616 mögliche Zustände.

Generell bedeutet das „B“ in msb und lsb jedoch Byte und nicht Bit.

Auf dem AVR-Controller, welcher auf dem Arduino verbaut ist, ist eine Integer-Variable 2 Bytes groß. Das muss man wissen, denn auf anderen Maschinen (PCs, etc.) ist ein Integer 4 Bytes groß. Man kann also folgendes festhalten:

byte a = 255;           // Von 0 bis 255, 1 Byte: 2^8=256
int b = 32767;          // Von -32767 bis 32767, 2 Bytes (1 Vorzeichenbit): 2^15=32768
unsigned int c = 65535; // Von 0 bis 65535, 2 Bytes: 2^16=65536
/*  
   Das erste (linke) Bit ist im Regelfall immer das
   Vorzeichen-Bit. Durch das Keyword 'unsigned' kann 
   dieses als Datenbit genutzt werden.
*/

Jetzt sieht man auch die Problematik: Mit dem I²C-Bus kann man wie bereits erwähnt nur 1-Byte lange Nachrichten senden. Einen Integer zu senden funktioniert nicht so einfach, wie man es gerne hätte, denn er ist einfach zu lang. Das führt uns zum eigentlichen Thema:

Bit-Shifting

Der Grundgedanke um das Problem zu lösen ist: Teile den 2-Byte großen Integer am Slave in zwei 1 Byte große Pakete auf, schicke diese nacheinader und setze sie am Master wieder zusammen. Klingt einfach, ist es auch.

Hierfür stellt uns der C++ Standard auch die nötigen Werkzeuge zur Verfügung. Wir brauchen die folgenden Operatoren:

<< Nach links shiften
>> Nach rechts shiften
& Bitweises UND
| Bitweises ODER

Zum besseren Verständnis folgt eine kurze Erklärung der Funktion der Operatoren.

Nach links shiften
110010011 << 2 = 001001100
110010011 << 4 = 100110000
110010011 << 6 = 011000000
/* 
   Die Bits werden um die nach dem '<<'-Operator angegeben Zahl
   nach links verschoben. Am rechten Ende werden Nullen angehängt.
*/
Nach rechts shiften
110010011 >> 2 = 001100100
110010011 >> 4 = 000011001
110010011 >> 6 = 000000110
/* 
   Die Bits werden um die nach dem '>>'-Operator angegeben Zahl
   nach rechts verschoben. Am linken Ende werden Nullen angehängt.
*/
Bitweises UND
1100 & 1010 = 1000
1111 & 0000 = 0000
1111 & 1010 = 1010
/* 
   Das bitweise UND gibt nur dann eine Eins, wenn zwei Einsen addiert werden.
   In jedem anderen Fall ist das Ergebnis Null.
*/
Bitweises ODER
1100 | 1010 = 1110
1111 | 0000 = 1111
1111 | 1010 = 1111
/* 
   Das bitweise ODER gibt nur dann eine Null, wenn beide Bits Null sind.
   In jedem anderen Fall ist das Ergebnis eine Eins.
*/

Mit diesem Wissen erklärt sich auch, was im Programm des Slave_Reader passiert. Dort findet man die folgenden Zeilen:

byte msb = (integerValue >> 8) & 0xFF;
byte lsb = (integerValue) & 0xFF;

Das most-significant-byte ist das linke der beiden. Ich rücke also den Integer bitweise um 8 Stellen nach rechts, wodurch die nun linken 8 Bits Nullen sind. Weil man nun trotz allem noch 16 Bits hat UNDe ich bitweise mit 0xFF (binär: 11111111). Auf diese Weise fallen die ersten 8 Bits weg. Im nächsten Schritt widme ich mich dem least-significant-byte – dem rechten Byte. Hier reicht es, einfach die linken 8 Bits zu löschen. Dies erledigt man wieder mit dem bitweisen UND von 0xFF.

Dem ’schöneren‘ Aussehen des Programms wegen schreibe ich die zu sendenden Bytes in ein Byte-Array. Man muss darauf achten, dass dieses Array am Master als auch am Slave die gleichen Daten an den gleichen Indizes hat. Also Integer_A an Stelle 0 & 1, Integer_B an Stelle 2 & 3, usw. Beim tatsächlichen Senden der Daten mit Wire.write(); steht die Zahl für die Größe des Arrays.

byte buffer[3] = {0};
buffer[0] = digitalValue; // Boolsche Variable, benötigt nur 1 Bit Platz
buffer[1] = (analogValue >> 8) & 0xFF; // analogValue ist ein Integer
buffer[2] = (analogValue) & 0xFF;
Wire.write(buffer, 3);

Betrachtet man nun den Code vom Master, so findet man die Zeile

Wire.requestFrom(slaveReader, 3);

, welche die Funktion requestHandler() am Slave_Reader triggert. Die Zahl 3 steht wieder für die Größe des Pakets in Bytes. Der Master fordert also den Slave auf, ihm Daten zu senden. Hat der Slave das getan, so werden die Daten mit den folgenden Zeilen gelesen.

while(Wire.available())
    for (int i = 0; i < 3; i++)
        buffer[i] = Wire.read();

Nun muss man lediglich die zwei Bytes des Integers wieder zusammenfügen. Dies erledigt man kurz und bündig in einer Zeile:

analogValue = (buffer[1] << 8) | buffer[2];

Was passiert hier? Das most-significant-byte befindet sich im Array an der Stelle 1, das lsb an Stelle 2. Deshalb schiebe ich das msb um 8 Stellen nach rechts, erschaffe dadurch eine 16-Bit Binärzahl in der sich an den rechten 8 Stellen lauter Nullen befinden. Diese überschreibe ich mit dem bitweisen ODER mit dem lsb. É voilà, der Integer ist wieder ganz.

Nachdem der Integer am seriellen Monitor ausgegeben wurde gehen wir noch etwas weiter und senden das Array an den Slave_Writer. Durch die drei Zeilen


Wire.beginTransmission(slaveWriter);
Wire.write(buffer, 3);
Wire.endTransmission();
    

im Programm des Masters wird die Verbindung zum Slave hergestellt, es wird das Paket gesendet, und die Verbindung wird getrennt. Die Funktion receiveHandler() im Sourcecode des Slave_Writers wird daduch getriggert und beginnt die Daten zu lesen. Über das gleiche Bit-Shift-Verfahren wie im Master wird der Integer wieder hergestellt. Letztendlich werden die beiden LEDs entsprechend angesteuert.

Die Variable slaveWriter beinhaltet lediglich die hexadezimale Zahl 0x02, welche in Dezimalschreibweise für 2 steht. Kurz: Der Slave_Reader hat die Adresse 0x01 = 1, der Slave_Writer die Adresse 0x02 = 2. Die Adressen können frei gewählt werden.

Letzte Worte

Geräte, welche an dem I²C Bus angeschlossen sind müssen immer mit Spannung versorgt sein. Ein deaktiviertes Gerät sollte deshalb auch nicht am Bus angeschlossen sein. Der Grund ist, dass das Gerät dann Spannung aus den beiden Busleitungen bezieht. Das Resultat ist ein blockierter Bus oder ein defektes Gerät.

Ich habe versucht, alles relevante zu beschreiben, was man wissen muss, um Daten mit dem I²C Bus zu senden. Falls dennoch Fragen offen sind: Ein Kommentar oder die Doku.