Mehrere AVRs an einen Bus

Also meine Idee war einen einfachen Bus herzustellen.
Wie unten im biold zu sehehn hängen 3 Slave-Controller an einem amster.
Dies können untereinander nicht kommunizieren, soviel ist klar.

Die eigentlich Idee ist, dem Hauptcontroller Arbeit abzunehmen.
Da ich eine GPS-Maus verwenden möchte, dachte ich mir, dass ein Co-Prozessor schon die ganzen Strings der Maus entschlüsselt, und zurechtschneidet, und dann z.B. nur die Position ausgibt, oder die Geschwindigkeit.

Deshalb, also wenn der Prozessor gerade Zeit hat, die INformationen zu verarbeiten, oder diese jetzt benötigt, enabled er den entsprechenden Controller, der über einen Interrupt dann den Wert üder RS232 ausgibt.

ODer man könnte es so machen, dass jeder Slave.Controller eine Adresse erhält, und der haupt-controller dann diese Andresse sendet,. so dass der Slave-C weiß, das er od nicht gemeint ist.

Ja, vermutlich geht das über I2C einfacher, aber ich möchte günstige AVrs, wie den AT90S2313 oder sogar 2323 verwenden.

Benötige ich dann für jeden Controller einen MAX, oder reicht es wenn sie Untereinandner so kommunizieren und nur für den PC einen MAX zusammen benutzen?

MFG Moritz

Wenn Du 2 - 3 Euro mehr zahlst, dann könntest Du Meg8 mit I2C nehmen. Vorteil wäre das du keine weitere Hardware (Bustreiber etc. brauchst). Bis 3m ist I2C eigentlich recht problemlos. Allerdings müsstest du dich dann mit der Slave-Programmierung beschäftigen und das ist gerade beim Einstieg nicht ein erhöhter Schwierigkeitsgrad.

Von Software I2C-Slave Programmierung rate ich ab. Damit hab ich keine gute Erfahrung gemacht da dies einfach zuviel Performance kostet. Ein Slave sollte immer Hardware-I2C benutzen. Daher verwende ich bei meinen Karten RN-Speak, RN-Motor nun auch nur noch Hardware I2C des Mega 8.

Alternativ bietet sich der RS485 Bus an, siehe unter den Artikeln. Der ist schon für mehrere Slave gedacht und kommt ab 2 Leitungen aus. Allerdings braucht man dazu einen Max 485. Hier hat glaub Kjion die meiste Erfahrung.

Oben genanntes Schaltbild müsste eigentlich funktionieren. Allerdings muss Master halt die Slaves freigeben so das die sich nicht in die Quere kommen. Und zudem können sie so schlecht gegenseitig kommunizieren.

Besser wäre ein Ringleitungskonzept wie es auch hier im Forum schon mal in einem Thread angesprochen wurde. Einfach die Controller in Reihee schalten. Also TX des ersten auf RX des zweiten. Dann TX des zweiten auf RX des dritten und zuletzt TX wieder auf RX des ersten.
In dem Fall müssten die Controller die Daten empfangen und schaun ob diese für ihn bestimmt sind. Könnte man durch eine Kennung machen.
Sind die Daten nicht für einen bestimmt, dann werden die einfach unverändert zum nächsten übertragen. So geht das wieter bis sie am Ziel sind.
Kommen die Daten unverändert beim Absender wieder an, dann war der Empfänger nicht da!

Eine andere Möglichkeit in Bascom wäre einfach die verwendung mehrerer RS232 Ports. Bascom kann recht einfach per Software jeden Port zu einer RS232 Schnittstelle machen.

Und dann gibt es noch SPI und 1 Wire-Dallas Bus, mit denen hab ich aber noch nicht sonderlich Erfahrung.

Erwähnen möchte ich noch das die Möglichkeiten des AT90S2313 beschränkt sind, die 2K hat man schneller voll als man denkt. Also nicht zu große Projekte mit diesem Controller planen.

Gruß Frank

Ich bin hatl noch ein voller Einstieger, kennst mich aus dem Thread mit dem Programmieradapter :-)

Also die möglichkeiten mit mehreren RS232 ausgängen finde ich interessant. da werd ich mich mal schlau machen.
Aber da es ja hier wirklich nur Slave Prozessoren sind, die nur senden sollen, wenn sie gefragt werden, reicht das so wenns es läuft.
Einen weiteren wollte ich zur überwachung der Abstandssensoren oder des Linienverfolgern nehmen. Einen vielleicht für ne Funksteuerung etc.

MFg Moritz

Über das SPI ist es noch einfacher ...

Nu, dann beschreib es doch mal etwas genauer. Die Vorteile beispielsweise.

Was ist denn SPI?

Das ist der Bus, der auch zum programmieren benutzt wird. MOSI, MISO, SCK und Pin SS sind dafür zuständig. Auch der ist wie I2C hardwaremäßig in den AVR´s implementiert. Allerdings hab ich kaum Software gesehen wo der genutzt wird

Seit wann ist denn I2C in AVR's hardwaremäßig integriert?

Schon immer in allen neueren AVR´s! Zum Beispiel in allen Mega´s! Es nennt sich dort nur "TWI"
Ist aber genau das gleiche

Also kann ich dort mit dem TWI auch I2C-Bausteine ansprechen?

Ja aber sicher! Ist doch absolut identisch mit I2C. Das geht über die TWI-Register.

Cool!
Warum versuche ich eigentlich schon seit Monaten ein I2C-Protokoll zu programmieren? ;o)
Danke für diesen Hinweis! :o)

Moment, was ist jetzt hier was?
SPI, TWI, I2c?
Wie spricht man die Busse denn an?
Print?

MFG Moritz

SPI verwendet die selbe Schnittstelle wie ISP. Braucht 4 Leitungen (MOSI, MISO, SCK, SS). Ist auch hardwaremäßig in den AVRs vorhanden - kann also ohne gropße Performanceverluste verwendet werden.

I2C und TWI ist DAS SELBE Bussystem. Phillips hat I2C entwickelt - Atmel darf aus Lizenzrechtlichen Gründen I2C (Inter IC Connection) nicht verwenden. Also nennen sie es einfach TWI (Two Wire Interface). TWI/I2C benötigt nur zwei Leitungen.

Im Prinzip ist es egal, welche man verwendet. SPI sollte etwas höhere Datenraten erlauben und außerdem dürfen hier die Längen der Verbindungen etwas größer sein. I2C ist eigentlich nur für die Verbindung von Chips auf der selben Platine gedacht - die Leitungslängen sollten recht kurz sein (einige 10 cm) - je nach Busgeschwindigkeit.

Für beide Bussysteme gibt es Chips, die sich darüber ansteuern lassen. SPI hat den Nachteil, dass jedes Gerät über eine extra Leitung angeschlossen werden muss, d.h., 4 Leitungen bruachst du für einen Slave - für jeden weiteren Slave brauchst du eine weitere Leitung (Enableleitung). Dahingegen wird über I2C ein Slave nur über seine Adresse angesprochen. Dh. der Bus kommt mit nur 2 Leitungen aus, egal wieviele Slaves.

Viele Grüße
Flite

Zitat:

---

I2C ist eigentlich nur für die Verbindung von Chips auf der selben Platine gedacht - die Leitungslängen sollten recht kurz sein (einige 10 cm) - je nach Busgeschwindigkeit.

---

Ich denke das ist ein weit verbreitetes Gerücht. Ich habe nun schon mehrfach gelesen das offiziell 3m zugelassen sind.

Offiziell ist die Länge des I2C Bus bestimmt nicht in einer Meterangabe bestimmt. Laut Spezifikationen darf das SCL und das SDA System maximal eine Kapazität von 400pF haben. Zu dieser Kapazität zählen die Kapazitäten der Anschlusspins, sowie die Leitungskapazität. D.h. die zulässige Länge ist abhängig von der Anzahl der Busteilnehmer, von deren Pinkapazität (also auch vom Package) und vom verwendeten Kabel/Leitungsführung auf der Platine. Das das ganze mit 3 Meter Länge noch funktioniert ist durchaus möglich. Darunter leidet dann aber evtl die 'Datensicherheit'. Es kommt auch immer darauf an, in was für einer Umgebung man das Gerät betrieben möchte. In Industriehallen mit großen Maschinen fängt man sich über ein langes Kabel viel mehr Störungen ein, als über ein kurzes. Tatsache ist, dass es dafür gedacht war, um mehrere Chips in einem System zu verbinden (z.B. Videorecorder, ...). Es sollte nicht dazu dienen, Daten über größere Entferungen zu übertragen. Dafür gibt es andere Bussysteme vie RS485, CAN, LIN, ...

Ach ja: noch ein Vorteil von I2C: Im Gegensatz zu SPI kann man mit I2C einen Multimaster Bus realisieren.

Viele Grüße
Flite

Hi Flite,

du hast sicher Recht das der I2C-Bus eigentlich zur Kommunikation innerhalb eines Gerätes entworfen wurde und die Kabellänge nicht so sehr lang werden sollte.
Aber ich denke man sollte die User nicht mit der Angabe "20 cm" verschrecken. Diese Angabe wird nirgends offiziell so genannt, zumindest hab ich das nirgends in den Datenblättern gefunden.
Ich habe auch schon mehrfach von 3m gelesen, sogar schon von 20 Metern (was mir dann doch etwas viel erscheint).
Nach meinen Erfahrungen sind kurze Kabellängen von unter 1m selbst bei höheren Datenraten völlig problemlos, sogar ein Handy in der Nähe sollte da kaum ein problem darstellen. Ich habe auch schon ein ganzes Zimmer per I2C-verkabelt, waren sicher zwei mal 7m Kabel. Auch da gab es nicht die geringsten Probleme.
Aber wie du schon sagst, es kommt auch auf die Geschwindigkeit der Datenübertragung und die Störquellen an. Natürlich auch auf das Kabel, bei meiner Zimmerverdrahtung war es normales Telefonkabel.

Mit SPI hab ich nicht so viel Erfahrung. Etwas unverständlich ist mir, warum SPI bei der Programmübertragung (per ISP) oft so störanfällig ist. Kannst du dir das erklären?

Hallo Frank,

du hast schon recht. Wie gesagt. Philips spezifiziert weder 20cm noch 3m. Es kommt eben auf die oben genannten Parameter an. Ich selbst habe auch einige Schaltungen bei mir laufen, die über normale Flachbandkabel auch mit I2C über mehrere Meter funktionieren.

Ich wollte nur 'Gast' erklären, dass es sich bei den wenigen 10cm. nicht um ein Gerücht handelt, sondern dass es von einigen Faktoren abhängig ist. Funktionieren tut es meistens schon und wenn dann doch mal wegen einer Störung das Teil ausfällt, dürfte es bei einem Roboter ja keine so schlimmen Folgen haben. Bei kommerziellen Geräten oder sogar medizinischen Geräten muss man hierauf schon etwas mehr achten, aber das hat hier ja wohl keiner vor ;-)

Die Fehleranfälligkeit von ISP kann ich mir auch nicht wirklich erklären. Ich hatte das selbe Problem mit dem STK500. Alle 10 Programmierversuche ist einer fehlgeschlagen. Anscheinend kann man die Geschwindigkeit der Programmierung über das neue AVR Studio einstellen. Wenn man hier eine langsamere wählt funktioniert es anscheindend einwandfrei.

Ich selbst programmiere meine AVRs mit einem Parallel ISP mit HCT. Das ging bei mir bisher einwandfrei. Da hatte ich noch keine Probleme.

Viele Grüße
Flite

Also um mehrere Avr´s zu verbinden, mit einem Master, ist denke ich SPI das beste/einfachste. Braucht zwar mehr Pins wie I2C, es ist aber um einiges einfacher einen Avr als SPI slave zu programmieren als mit I2C. Sprech da aus erfahrung denn ich hab bis jetzt nichts Vernünftiges im Netz über Microcontroller als I2C Slave gefunden, geschweige denn Codebeispiele für Basic oder C.
Erklärung zu SPI und bisschen Code für avr-gcc gibts bei
www.mc-project.de .
Gruß Muraad

Zum Hardware-I2C: Gibts da fertige(und dokumentierte) Routinen für AVR-GCC, die man irgendwo 'runterladen kann?

^^ *ohne Worte*

Zitat:

---

Zitat von Gottfreak

Zum Hardware-I2C: Gibts da fertige(und dokumentierte) Routinen für AVR-GCC, die man irgendwo 'runterladen kann?

---

Die Frage ist durchaus berechtigt. Es gibt im Internet auch viele Bibliotheken welche I2C-Funktionen integriert haben. Etwas schwieriger ist es Bibliotheken mit dem hardware I2C-Bus (also TWI) zu finden.
Aber dürfte es inzwischen auch geben. Vielleicht kann ja mal einer der C-Experten hier was zu sagen. Finde es schade das immer wieder zur C-Programmierung aufgerufen wird und User dann mit den Fragen allein gelassen werden.

Übrigens ist die Master-Programmierung nicht so sehr komplex, hier spielt es kaum eine Rolle ob der Hardware I2C oder eine Software-Implementierung benutzt wird. Schwieriger ist es mit der Slave-Programmierung, da ist der Hardware I2C des AVR sehr empfehlenswert.
Allerdings ist es sehr schwierig Code im Netz zu finden, so das man sich da auch etwas Mühe geben muss. Da der Slave-Code doch mit etwas Aufwand verbunden ist, wird er derzeit noch gut von den jeweiligen Programmierern gehütet.

Gruß Frank

Eine Frage die periphere hier her passt. Ich plane in meinem Segelboot neben der RN-Control auch 3 der 2-fach Fahrtreglerkarten von stupsi für Getriebemotore >10A einzusetzen und diese sollen per I2C mit der RN-Control verbunden sein. Wie gehe ich am sinnvollsten vor um im System beim Testen und Debuggen nicht nur Code in die RN-Control, sondern auch in die mega jeder 2-fach-Fahrtreglerkarte zu schreiben. Bei Parametern ist wohl das EEROM der geeigneste Speicher da der flash nicht zu häufig überschrieben werden kann, oder wie liegen hier die Grenzen?
Idealer weise müßte die RN-Control über die ISP-Schnittstelle der mega8 diese programmieren? Also daten vom PC erhalten und durchreichen?

Zitat:

---

Bei Parametern ist wohl das EEROM der geeigneste Speicher da der flash nicht zu häufig überschrieben werden kann, oder wie liegen hier die Grenzen?

---

"Nicht allzu häufig" ist relativ. Die Anzahl der Schreib-Lösch Zyklen steht gleich auf der ersten Seite im Datenblatt.
Beim ATMega16 sind 10.000 für den Flash- und 100.000 für den EEProm Speicher angegeben.
Mit Daten die du selber in den Controller hochladen willst, wirst du da wohl bei beiden Speicherarten nicht so schnell Probleme bekommen.

Zitat:

---

Idealer weise müßte die RN-Control über die ISP-Schnittstelle der mega8 diese programmieren? Also daten vom PC erhalten und durchreichen?

---

Vierlleicht klappt das ja mit Bootloadern und Programmierung über die serielle Schnittstelle .
Ich meine ich hätte neulich irgendwo gelesen, dass es in Bascom Befehle gibt mit denen man relativ einfach "Software-UARTS" simulieren kann.

Damit könnte das RN-Control dann an der seriellen Schnittstelle Programmcode entgegennehmen und über irgendwelche anderen Pins und Software-UART an die entsprechenden Sub-Controller weitergeben.
Allerdings müsste man dem RN-Controll dann irgendwie klarmachen an welchen Sub-Controller er den Code weitergeben muss und wenn das RN-Control selber auch über die serielle Schnittstelle programmiert werden soll wird es wohl noch komplizierter.

Soweit ich das verstanden habe, wartet ein Bootloader auf eine bestimmte Daten-Sequenz um zu unterscheiden, ob es nur serielle Daten sind oder neuer Programmcode.
Wenn diese Sequenz für die verschiedenen Controller unterschiedliche ist oder eine zusätzliche Adresse enthält, könnte ich mir schon vorstellen, dass man dieselben Daten an alle Controller schickt und nur der richtige fühlt sich angesprochen.

Dafür müsste man aber nicht nur die Bootloader selber anpassen, sondern auch die Programmiersoftware auf dem PC.

Ich glaube es wäre einfacher und praktischer die seriellen Anschlüsse von allen Controllern zentral an eine Stelle zu legen und da dann entweder für jeden einen eigenene Stecker oder einen Umschalter anzubringen.
Beim seriellen Anschluss sind es ja nur 3 Leitungen pro Controller und man kann die seriellen Anschlüsse dann ausser zum Programmieren auch gleich zum debuggen verwenden.

Hallo recycle

Du hast schon recht, das Flash und der EEROM haben wahrscheinlich hinreichend häufige Wiederbeschreibbarkeit. Betreff des Themas Parameterübergabe habe ich mich nicht richtig verständlich gemacht. Sorry.
Hier gelten 2 verschiedene Szenarios:
1. Entwicklungsumgebung:
Standort Werkstatt daheim. Hier ist der PC der mit ausreichend seriellen und parallelen Schnittstellen versehen innerhalb von PonyProg Programme und Daten zu den diversen Controllern runterladen und ins Flash brennen kann in dem man einfach die serielle und die parallele Schnittstelle die PonyProg beim I/F zum megaxx anspricht umkonfiguriert und so das richtige Ziel-Subsystem anspricht. Gleichfalls ist es hier lösbar Datentabellen im Flash, im EEROM oder im SRAM zu pflegen.

Die diversen Controller steuern die diversen mechanischen und elektronischen Vorrichtungen.

Der kritische Teil nach meinem Befürchten ist aber der Betrieb im Feld, sprich am Seeufer, der natürlich in der Werkstatt programmiert, getestet und verbessert wird. Deshalb erläutere ich hier unter Punkt 2:

2. Zielumgebung:
In der Zielumgebung ist kein PC vorhanden, dort ist das Segelboot mit einem I2C Bus welcher das Segelboot mit der Steuereinheit in der Hand des Benutzers verbindet. Die Steuereinheit ist ein LCD-Display mit Tasten, einem mega124 und einem I2C I/F welches es mit der RN-Control und ihrem I2C Bus verbindet. Jedes der Subsysteme inkl. der LCD-Displayeinheit haben natürlich eine eigene Adresse an diesem I2C-Bus.
Über den I2C Bus kann der mega124 im LCD-Display, der Steuereinheit, als Busmaster, jedes der Systeme am I2C-Bus adressieren und Daten überspielen. Die Frage aber ist, wie stelle ich sicher das die überspielten Daten beim Empfänger nicht flüchtig gespeichert werden?

Ein für meine Lösung erschreckendes Szenario wäre das ich die RN-Control um diverse parallele Schnittstellen erweitern muß um so zwischen der RN-Control und jedem megaxx eine ISP-Verbindung bereit zu stellen! Das wären im Fall meines Segelbootes 5 solche parallele Schnittstellen mit 5 ISP-Kabeln die zu 5 ISP I/F der jeweiligen megaxx der Subsysteme führen!

Der mega124 würde also auf Grund der Benutzereingaben über die Tasten am LCD-Display Daten per I2C-Bus an die RN-Control senden, die RN-Control würde diese Daten im SRAM Zwischenlagern und dann die geeignete Verbindung in einer Sterntopologie, RN-Control Zentral, Subsysteme und LCD-Display in Sterntopologie per Zusatzboard an der RN-Control mit 5 parallelen Schnittstellen das ISP-I/F des betreffenden Controllers ansprechen und die Daten in der im Flash abgelegten Tabelle des jeweiligen megaxx der Subsysteme aktualisieren. Muß das so sein?

Gibt es eine Möglichkeit einen megaxx Controller über sein eigenes im eigenen Flash liegendes Programm in sein eigenes Flash eigenständig Daten die er z.B. im Sram gepuffert hat, zu brennen? Wenn ja, so entfiele die Notwendigkeit die ISP-Verbindungen zwischen der RN-Control zu den diversen Subsystemen zu implementieren. Die jeweiligen megaxx würden selber ihre Daten im eigenen Flash aktuallisieren.

Zitat:

---

Gibt es eine Möglichkeit einen megaxx Controller über sein eigenes im eigenen Flash liegendes Programm in sein eigenes Flash eigenständig Daten die er z.B. im Sram gepuffert hat, zu brennen?

---

So eine Möglichkeit kenne ich nicht. Da du aber über diese Verbindung wahrscheinlich nicht richtig programmieren(ich weis ja nicht, was deine Display-Einheit kann) sondern nur Parameter einstellen willst, bietet sich tatsächlich das EEPROM an. Da kannst du Parameter, die über den I2C-Bus (zur Laufzeit)geändert werden, abspeichern und nach jedem Reset wieder auslesen(viele Entwicklungsumgebungen bieten sogar die Möglichkeit, Variablen direkt im EEPROM zu deklarieren.).

Hallo Gottfreak

Ich verwende Bascom, ich gehe davon aus das geht. Ich hab schon vermutet das es auf den EEROM hinausläuft. Übrigens, völlig richtig, es sind nur Parameter. Danke

Ich würde auch zum EEprom raten.
Ich weiss nicht genau was du für Daten sicherst, aber manchmal kann man Kompromisse machen. Bei einem meiner letzten Projekte hab ich Daten immer nur periodisch im Eeprom abgelegt. Da sich die Daten mehrfach am Tag geändert haben, wollte ich nicht jedesmal das EEprom neu beschreiben, sondern habe dies nur bei jedem zwanzigsten EIntrag gemacht. Dadurch ist der Datenverlust zumindest beschränkt.

Gruß Frank

Hallo Frank

Die Fahrtregler verwende ich um Segel zu betätigen, sowie um Deckaufbauten zu bewegen. Bei allen diesen Funktionen ist es wichtig am Seeufer, bevor man das Boot zu Wasser lässt, alle Einstellungen zu justieren, da beim Zusammenbau alle Schote, also Seile/Schnüre, die den Mast fixieren und die Segel steuern nicht wieder exakt die Position haben wie beim letzten Mal. Somit definiert man wieder die Referenzpositionen und bestimmt die Verstellbereiche. Da ich hier die 3 Impulse der Inkrementalwertgeber auswerte um Positionen anzufahren oder mit auswerte um technische Defekte im Betrieb zu erkennen, müßen die Parameter welche die verschiedenen Funktionen in ihrer Ausführung bestimmen angepaßt werden. Außerdem ist das ein iterativer Prozeß bei dem man ständig trimmt und verbessert. Auch muß man Funktionstests ausführen um dabei die Parameter zu optimieren. Diese Freiheit ist für die Akzeptanz am See entscheidend. Ein Verlust dieser Daten im Betrieb kann das Segelboot zum kentern und zum Wassereinbruch führen, sowie durch die Kraft der eingesetzten Dunkermotoren das Boot zerstören. Das verlangt die Daten nicht flüchtig zu speichern. Ja, um alle diese Justagen am Seeufer ohne PC durchzuführen ist ein LCD-Display mit Tastenfeld ideal.

Allerdings plane ich, wenn die Funktionen über einen physikalisch vorhandenen I2C-Bus zwischen LCD-Display und Boot funktionieren, diese Schnittstelle durch Funkübertragung zu ersetzen. Jetzt wird das LCD-Display zum mächtigen Fernwirkinstrument, sowie zum idealen Werkzeug als Multifunktionsdisplay welches erlaubt das Boot zu jedem Zeitpunkt vom Ufer aus durch die gesendeten Telemetriedaten zu überwachen und interaktiv abzufragen, sowie von Ferne zu programmieren. Die Möglichkeiten für den Schiffsmodellbauer sind einfach gigantisch und würden bei Schleppern, oder Kriegsschiffmodellen, welche umfangreiche Sonderfunktionen haben tolle Möglichkeiten eröffnen.

Hab grad ne Seite mit C Bibliotheken gefunden, die sehr interessant sind.
http://www.procyonengineering.com/avr/avrlib/

"I2C Serial Interface Function Library
This library provides the high-level functions needed to use the I2C serial interface supported by the hardware of several AVR processors. The library is functional but has not been fully tested yet and is still expanding. Thanks to the standardization of the I2C protocol and register access, the send and receive commands are everything you need to talk to thousands of different I2C devices including: EEPROMS, Flash memory, MP3 players, A/D and D/A converters, electronic potentiometers, etc."

Da gibts sogar was für GPS, IDE/ATA, Graphik LCD usw. Die Seite ist überhaupt sehr interessant hab sie grad erst gefunden.
Muraad

Hi,

fertige routinen gibts direkt von Atmel.
App Note 311: TWI Slave
App Note 315: TWI Master

der Code ist zwar für den IAR Compiler, aber mit
ein paar anpassungen geht er auch für den GCC.

bei Interesse kann ich auch mal ein beispiel hier posten.


mfg
Thorsten

Also ich denk Interesse an Code ist hier (bei mir) immer da O:)
Gruß Muraad

So habs mal zusammengesucht.

In der Datei ist die angepasste App Note
(TWI_Master.h), das Beispiel von Atmel (main.c)
und ein Testprogramm von mir (twi.c)