Es ist schon einfacher, neue Geräte zunächst mit dem PC zu steuern. Insbesondere die relativ kurzen Turn-Around-Zeiten und das komfortable Debuggen ist sehr hilfreich. Zum Testen von I²C-Devices habe ich mir folgende Werkstatt zugelegt:
Entwicklungsumgebung
Ich -als Gelegenheitsprogrammierer- benutzte die aufgeführten Werkzeuge nur aus einem Grund: Ich bin mit Ihnen vertraut. Ich habe festgestellt, dass fast alle modernen Werkzeuge nahezu alle Anforderungen aus der Sicht einen Gelegenheitsprogrammierers erfüllen. Sie unterscheiden sich nur in der Art, wie sie dies tun. Hier sind dann eher persönliche Vorlieben von Bedeutung als technische Besonderheiten. Als Hobby-Entwickler habe ich auch gar nicht die Zeit, sich um viele Alternativen zu kümmern.

Für mich sind folgende Argumente wichtig: PC, Windows, möglichst preiswert bis kostenlos, wenig Fehler, ausreichender Umfang. Vor einigen Jahren bin ich auf objektorientierte Programmierung umgestiegen. Immer dann, wenn diese Option besteht, möchte ich die Vorteile dieser Methode nutzen. Ich bevorzuge Visual Basic von Microsoft. Microsoft Basic kenne ich seit Ende 1970-er. Es gab viele Versionen, immer mit überschaubaren Änderungen. Das machte es einfach mit der Entwicklung Schritt zu halten. Basic schottet das Betriebssystem wirksam ab. Insbesondere versteckt Visual Basic erfolgreich die Unzulänglichkeiten der Windows-Dokumentation. Außerdem hat VB eine Syntaxprüfung während der Eingabe. Die vielen geschweiften Klammern bei der Alternative "C" und dessen Derivaten machen mich nervös.

Beim Mindstorms NXT setze ich Lejos ein. Ein JAVA-Implementierung für dieses Gerät (hat zwar auch geschweifte Klammern, ist aber objektorientiert (das einzige objektorientierte Sprache für den NXT)).

Bei den µC habe ich bisher nur mit den Atmel AVR-Chips gearbeitet. Auch hier gibt es nur den Grund: Gewohnheit und Zeitmangel sich mit anderem zu beschäftigen. Die verschiedenen AVR-Versionen haben sehr ähnliche Komponenten. Hauptsächlich die Zusammenstellung der Komponenten variiert. So kann man zum Entwickeln einen Chip mit einer UART nutzen und Debug-Informationen per RS232 versenden und beim Einsatz auf einen anderen kleineren Chip mit weniger Komponenten wechseln.

AVR-Studio kann man benutzen ohne irgendetwas anpassen zu müssen. Insbesondere muss man keine Makefiles bauen und anpassen. Es bietet aber die Möglichkeit fast alles zu konfigurieren (auch die Nutzung einer selbstgestrickten Makefile ist möglich). Außerdem kann man als Compiler den AVR-gcc nutzen (den kannte ich schon) und direkt einen Programmer ansteuern, ohne Umwege über Ponyprog, etc.

USB-to-I2C-Adapter
Irgendwann habe ich dieses Modul gesehen und auch gekauft, in der Hoffnung, hiermit insbesondere die selbst entwickelten I2C-Devices ansteuern zu können. Man muss auf die feste Taktfrequenz von 100 kHz achten! Die AVR haben im Regelfall eine Taktfrequenz von 8 MHz. Da bleiben nur 80 Prozessortakte für einen I²C-Takt. Das sind etwa 60 Befehle, da einige zwei Takte benötigen. Zieht den notwendigen Overhead zur Register-Sicherung und Rückspeicherung bei Interrupt-Service-Routinen ab und bedenkt man, dass man nur knapp eine halbe Taktzeit zur Verfügung hat (SDA muss bei der nächsten Clock-Flanke stehen), bleibt nicht mehr viel. Auch nicht wenn, der Takt auf 16 oder 20 MHz erhöht wird.

Das Problem ist hier nicht die Datenübertragung an sich. Das TWI- oder das USI-Modul im AVR erledigen dies auch bei hohem Takt im Hintergrund. Das Problem ist die kurze Zeit für die Reaktion auf ACK oder zum Senden eines Antwortbits.

Der I²C-Standard sieht für diese Fälle das sogenannte Clock-Stretching vor. Hierdurch ist der I²C-Slave in der Lage, die Taktrate bei Bedarf künstlich herab zu setzen. Doch leider ist dieses Feature optional und wird von dem Modul nicht unterstützt.

Für normale Anwendungen ist das allerdings i.d.R. kein Problem, wenn man die Datenbereitstellung bzw. -ermittlung nicht in den Service-Routinen vornimmt. Hier darf nur übertragen werden. Nicht unterbrechbare ISR sind ebenfalls Pflicht.

Ebenfalls ist zu beachten, dass die Länge eines Datenblocks 60 Byte nicht übrschreiten darf. Der interne Puffer ist nicht länger.

USB-to-I2C-Adapter Selbstbau
Es gibt auch diverse Vorschläge für den Selbstbau eines Adapters auf ATtiny-Basis (z.B. diesen). Irgendwann einmal, wenn ich viel Zeit habe ...

RS232-to-I2C-Adapter
Dann fand ich einen Selbstbauvorschlag für einen RS232-to-I2C-Adapter. Genau das, was man zum Entwickeln benötigt: Kontrolle des jeder einzelnen Leitung. Ergänzt man einen zweiten MAX232 kann man auch noch TxD und RxD der seriellen Schnittstelle bereitstellen. Das ist vorteilhaft, wenn gleichzeitig Debugging-Informationen per UART übertragen werden sollen. Nebenbei bemerkt: TxD lässt sich auch gut zum Auslösen eines Reset am µC nutzen. Einfach den Reset-Pin mit TxD verbinden. TxD liegt normalerweise auf High. Wenn  man nun 0x00 über die serielle Schnittstelle überträgt wird TxD für 9/Baudrate Sekunden auf Low gelegt (9 = Startbit + 8 Datenbits). Bei 19200 Baud sind dies knapp 0,5 mSec.

Gleichrichter, größerer Siebkondensator und ein Steckernetzteil machen aus dem ganzen ein unabhängiges Gerät.

Parallport-Adapter
Eine andere Variante ist auf der Ponyprog-Seite unter Benutzung eines Parallelports beschrieben. Hier eine Kopie der Abbildung:
 I²C-Parallelport-Adapter

mySmartUSB MK3
Es gibt eine Reihe von Programmiergeräten für AVR-Chips. Zunächst habe ich mich mit Ponyprog und einem einfachen Adapter für die serielle Schnittstelle begnügt. Dies war auf einem AVR-Evaluationsboard von POLLIN  integriert. Leider konnten die meisten Dinge nicht direkt mit dem Board gemacht werden. Besser dachte ich, müsste es doch mit ISP gehen.

Von dem mySmartUSB MK3 beindruckten mich die vielen Möglichkeiten und der kleine Preis. Insbesondere wurde die Einbindung in das AVR-Studio und ein I2C-Interface versprochen. Dem war aber leider nicht von Anfang an so. Mittlerweile klappt die Verbindung mit dem AVR-Studio einwandfrei. Jetzt brauche ich mich hier nur noch mit einem Tool zu beschäftigen und die Bedienung merken.

Dazu habe ich mir dann ein paar Steckbrett-Adapter gelötet.

Mit dem I2C (Stand 8.8.2010) hakt es noch ein wenig. Zwar soll die neue Firmware alles richten, aber die Dokumentation lässt noch wichtige Fragen offen. Z.B. welche der rund 40 Pins soll man nutzen?

Software-Bibliothek
Mein ganzer Stolz! Es gibt eine Version für die NET 4.0 Runtime Library. Sie besteht im wesentlichen aus einer Basisklasse, die alle wichtigen Funktionen für die I2C-Kommunikation bereitstellt. Für die beiden Adapter gibt es je eine abgeleitete Klassn, die auch die speziellen Funktionalitäten der einzelnen Adapter berücksichtigt. Ein Timer mit einer höheren Auflösung als der Standard-Timer, eine Exception-Klasse und eine Klasse für die typsichere Repräsentation der Signalzustände runden die Bibliothek ab. Natürlich gibt es auch eine Dokumentation.

Klassendiagramm

Download Bibliothek
Download Dokumentation
 
Zum Testen: eine Applikation, die die Bibliothek nutzt um einen SRF02-Ultraschall-Entfernungsmesser anzusteuern (Download).

Screenshot SRF 02

Datenblätter
Eines der wichtigsten ist die I²C-Dokumentation von Philips (jetzt NXP):
Hier wird sehr ausführlich die Theorie der I²C-Kommunikation behandelt.

Hinzu kommen die Datenblätter der Chip-Hersteller. Bei Atmel heißen das Interface übrigens TWI (Two Wire Interface). Einige Chips haben direkt ein TWI-Modul (Bespiel ATmega8), andere benutzen das sogenannte USI-Modul (Universal Serial Interface) zur Kommunikation (Beispiel ATtiny45).

Erwähnenswert ist noch die Atmel Application Notes "AVR312: Using the USI module as a I2C slave". Dokumentation und auch Code, wie man mit dem USI-Modul einen I²C-Slave realisieren kann. Der Beispiel-Code hat aber einen gravierenden Fehler (Details siehe hier).