Mehrere Controller verbinden?

Hallo zusammen,
habe heute mal wieder eine Verständnisfrage, da diese Frage mehrere Bereiche abdeckt, Elektronik und Programmierung, weis ich nicht genau wo ich sie stellen soll, hab mich dann für dieses Forum entschieden.

Ich verwende einen Mega32 als Hauptcontroller. Dann habe ich noch einen Mega8, der zur Steuerung einer Motorbrücke (L298) verwendet werden soll.

Nun möchte ich, dass der Mega32 dem Mega8 Richtung und Geschwindigkeit der Motoren mitteilt, der Mega8 steuert diese dann per PWM usw. an

Nur wie realisiert man so eine Kommunikation? Hab im Rn-Wissen Bereich bereits gesucht und I²C / bzw SPI Bus gefunden. Nur leider habe ich keine Idee wie ich so eine Schaltung aufbaue, geschweige denn diese richtig anzusteuern.

Wäre für ein paar Tipps sehr dankbar.

LG
Daniel

Du kannst das doch auch einfach per RS232/ UART machen. Einfach die beiden Controller RxD und TxD vertauscht verbinden, geht das per "print" und "input".
Viele Grüße,
William

ist das denn schnell genug?
grade bei zeitkritischen Anwendungen wie Motorsteuerungen?

Und vorallem wären dann bei dem Mega32 die Rx und Tx Ports belegt, die brauch ich ja noch für den PC.

Schnell genug ist das schon. Auf jeden Fall schneller als dein Motor aufgrund seiner Trägheit auf PWM Änderungen reagieren könnte. Vom Mega32 brauchst du nur den TxD zum anderen Controller verlegen.
Wenn dein Mega32 auch noch Daten zum PC senden soll, dann kannst du einfach seinen TxD Anschluss verzweigen und also an den PC und an den Mega 8 anschließen (wurde mir vor kurzem hier im Forum so erklärt). Dass der PC nicht auf die Befehle reagiert die eigentlich nur an den MEga8 gesendet werden sollten, kannst du ja per Software regeln.
Aber per TWI ist das bestimmt eleganter, vielleicht erklärts ja hier noch jemand...

Zitat:

---

ist das denn schnell genug?

---

Naja, wie schnell ist "schnell genug"?

da wären schon konkrete Angaben sinnvoll, wie lange es denn dauern darf bis eine vom Mega32 abgeschickte Nachricht vom Mega8 empfangen wurde.

naja ich habe da wie gesagt keinerlei Erfahrungen mit, wie lange würde es denn dauern?

Beispiel:
Roboter fährt auf ein Hindernis zu, Mega32 bekommt vom Sensor die Meldung da ist ein Hindernis, dieser sendet dem Mega8 die entsprechenden Befehle zu (Nothalt z.B.)

Noch eine andere Frage, kann man über den Rx bzw Tx Port auch mehrere Controller steuern, würde das gehen, wenn ich einfach mehrer anschließe oder wie darf man sich das vorstellen. Man könnte ja eine Routine einbauen, die auswertet an welchen Controller die Sendung gerichtet ist. So könnte man das ja auch machen, wenn die Sendung zum PC gehen soll.

Hoffe man kann mir folgen :)

---
Update:
---
Könnte ich dann auch an einem Ozi mehrere Controller hängen? So könnte ich viel Platz sparen auf den Motorsteuerungsplatinen.

Zitat:

---

Zitat von daniel.weber

Noch eine andere Frage, kann man über den Rx bzw Tx Port auch mehrere Controller steuern, würde das gehen, wenn ich einfach mehrer anschließe oder wie darf man sich das vorstellen. Man könnte ja eine Routine einbauen, die auswertet an welchen Controller die Sendung gerichtet ist. So könnte man das ja auch machen, wenn die Sendung zum PC gehen soll.

---

Das müsste eigentlich gehen.
Aber du kannst ja auch einen AtMega162 nehmen. Der hat jeweils zwei RxD und TxD Anschlüsse.

mfg

Das mit dem mehrere Controller steuern ist möglich,
mit einem Quarz/Oszillator kannst du allerdings nicht mehrere Controller betreiben.

Zitat:

---

Beispiel:
Roboter fährt auf ein Hindernis zu, Mega32 bekommt vom Sensor die Meldung da ist ein Hindernis, dieser sendet dem Mega8 die entsprechenden Befehle zu (Nothalt z.B.)

---

Reicht locker.
Denkansatz:

Dein Bot hat eine bestimmte Masse.
Der Antrieb (Motor mit Getriebe etc.) braucht rein Mechnisch eine gewisse Zeit um zum Stehen zu kommen.
Diese Zeit liegt meist weit über der für die Komunikation.
Darum brauchst du dir also keine sorge zu machen.

Zitat:

---

Noch eine andere Frage, kann man über den Rx bzw Tx Port auch mehrere Controller steuern, würde das gehen, wenn ich einfach mehrer anschließe oder wie darf man sich das vorstellen. Man könnte ja eine Routine einbauen, die auswertet an welchen Controller die Sendung gerichtet ist. So könnte man das ja auch machen, wenn die Sendung zum PC gehen soll.

---

Die Frage hat Willa dir eigentlich schon beantwortet.
Du schaffst dir einfach ein eigenes Protolkoll.
Zb. Startwert,Adresse (Also wer angwesprochen wird),Befehl,Daten etc.,Stoppwert.
Also ganz ähnlich wie bei I2C



@christopher1

Zitat:

---

mit einem Quarz/Oszillator kannst du allerdings nicht mehrere Controller betreiben.

---

Warum denn nicht ?

Sicher kannst du mehrere Controller mit einem Takt betreiben.
Takt auf "Extern" stellen und einspeisen.
Das kann sein das ein TTL-Generator alle Controller taktet.
Kann aber auch sein das einer seinen Quarztakt bzw. internen Takt mit allen anderen Teilt wenn man ihn anzapft.(Xtal kann auch nen Ausgang sein.
Natürlich muß man sicherstellen daß das Taktsignal auch sauber bei allen beteiligten ankommt.
Lange leitungen sind da nicht angesagt.

Diese Methode ist vorteilhaft wenn man verschiedene Controller zeitkritisch synchronisieren muß.
Für die hier angestrebte anwendung ist das allerdings eher weniger nötig.
Da reicht es wenn jeder Controller einen "Baudratenfreundlichen Takt" besitzt.

Sorry, hab das selbst noch nicht probiert, aber schon öffters gelesen, dass das nicht/schlecht klappt, aber man sollte halt nicht alles glauben ;-)

RS232 nehme ich auch, das klappt super :D

Hier ein anderer Thread:
https://www.roboternetz.de/phpBB2/ze...932&highlight=

Gruß Stefan

Zitat:

---

Zitat von Christopher1

Sorry, hab das selbst noch nicht probiert, aber schon öffters gelesen, dass das nicht/schlecht klappt, aber man sollte halt nicht alles glauben ;-)

---

Ja,das es bei vielen nicht klappt liegt daran das sie von idealen Bauteilen ausgehen wie sie im Lehrbuch stehen die aber nur zur Veranschaulichung herhalten könen.
In der Realität hat man auch "reale Bauteile" mit realen Werten.
alle Bauteile haben die klassischen Drei Komponenten.

Widerstand.
Kapazität
Induktivität.

Auch die einfache "Leitung" zwischen Zwei Punkten hat sie.

Der Widerstand ergibt sich aus Material,Querschnitt und Länge.
Die Kapazität aus Fläche und entferung zu anderen Potentialen.
Und die Induktivität aus der fähigkeit zur Leitung und des Materials.

Alle zusammen ergeben ein RCL-Ersatzschaltbild für eine "simple" Leitung das nicht mehr so simpel ist.

Wie stark die einzelenen Elemente zum tragen kommen hängt von der Art des Stromflusses ab.

In unserem Falle wollen wir einen Takt im Bereich von eingen Mhz übertragen und damit sind wir im Bereich der Hochfrequenz (HF)

Hier spielt eine einfache Kupferbahn schon schnell mal Filter "und" Sender so daß das Nutzsignal kaum "Lesbar" beim Empfänger ankommt.


Wer einen Oskar sein eigen nennt kann ja mal mit einem Controller einen Takt erzeugen und ihn darstellen.
Direkt am Ausgang sieht alles noch "ok" aus (sofern der Tastkopf stimmt)
Ja und dann kann man mal nach Herzenslust unterschiedliche Leitungen mit unterschiedlichen Längen/Verlegearten ausprobieren und nachmessen was am anderen Ende noch so herauskommt.

Wer gut ist kann am Signal erkennen was für ne Strippe,wie lang genutzt wurde und damit bei "Wetten Das ?" auftreten :lol: :lol:

Hi!
ich nehme an du programmierst in BASCOM (jedenfalls gibt es da einige Beiträge/ Fragen von Dir)

Die Entscheidung welcher Controller sich angesprochen fühlen soll kannst du so ganz einfach lösen:

Code:

---

    Dim Geschwx As Integer
    Dim Geschwy As Integer
    Dim Geschwxstr As String * 5
    Dim Geschwystr As String * 5
    Dim Geschwxy As String * 5
    Dim Isitx As Byte
    Dim Isity As Byte

 
Input "" , Geschwxy                  'Irgendeinen Datenstring per UART empfangen
Isitx = Instr(geschwxy , "X")        'Wenn ein "X" im String ist, dann wird die Variable "IsItX" auf 1 gesetzt
Isity = Instr(geschwxy , "Y")        'Wenn ein "Y" im String ist, dann wird die Variable "IsItY" auf 1 gesetzt


If Isitx = 1 Then                    'Wenn ein X im String war, dann...
  Geschwxstr = Mid(geschwxy , 2)    'Schneide die erste Stelle (das "X") des empfangenen Strings ab.
  Geschwx = Val(geschwxstr)        'Konvertiere den Rest des Strings in einen Integer
End If

If Isity = 1 Then                    'Das gleiche für Y
  Geschwystr = Mid(geschwxy , 2)
  Geschwy = Val(geschwystr)
End If

---

Dieser Code ist aus meinem Joystickprojekt, aber die wichtigsten Befehle und was sie so machen kann man ja erkennen.
Gruß,
William

Hi,
was habt Ihr eigentlich alle gegen I2C ??? Warum von hinten ins Knie schießen ?
Um mit einem Master mehrere Slaves zu steuern, gibt es eine saubere Lösung: Jeder Slave Controller hat eine eigene Adresse und gut ist.
Entweder Peter Fleurys Library verwenden oder mal bei den Atmel gucken (Docs AVR 311 und AVR315).

Gruß
pctoaster

@Willa
vielen Dank die Möglichkeit hatte ich mir schon so gedacht. Mal schaun, ob ich das hin bekomme :)

---
stimmt mit dem Ozi, rein theoretisch müsste es gehen aber man sagt ja das der Ozi so nah wie möglich am Controller liegen muss, wenn ich da nun eine 20 cm lange Datenleitung zwischen baue, führt das nur zu "Kuddelmuddel" dann werd ich wohl die Platine ein wenig größer gestalten müssen, damit der Ozi noch Platz findet.
---

Vielen Dank für die zahlreichen Antworten! :)

LG
Daniel

@PCToaster

Zitat:

---

was habt Ihr eigentlich alle gegen I2C ???

---

Wer hat was gegen I2C gesagt ?
Ich habe jetzt extra nochmal das Topic nachgelesen und finde nix.
Also wofür jetzt der Alarm ? ;)




@Daniel

Zitat:

---

stimmt mit dem Ozi, rein theoretisch müsste es gehen aber man sagt ja das der Ozi so nah wie möglich am Controller liegen muss, wenn ich da nun eine 20 cm lange Datenleitung zwischen baue, führt das nur zu "Kuddelmuddel" dann werd ich wohl die Platine ein wenig größer gestalten müssen, damit der Ozi noch Platz findet.

---

Nicht gleich alles durcheinander werfen.

Die Aussage mit den kurzen Leitungen betrifft Quarze am Controller.
Die sollen nahe am Chip liegen damit die Leitungskapazitäten nicht dazwischen funken bzw. die "langen Strippen" als Antennen fungieren.


Was ich meinte ist den Takt entweder "abzapfen" und puffern oder generell extern generieren.

Zitat:

---

Zitat von Ratber

@PCToaster

Zitat:

---

was habt Ihr eigentlich alle gegen I2C ???

---

Wer hat was gegen I2C gesagt ?
Ich habe jetzt extra nochmal das Topic nachgelesen und finde nix.
Also wofür jetzt der Alarm ? ;)

---

Na, ja in diesem Thread scheint nur über RS232 als Kommunikationsweg diskutiert zu werden (obwohl der Threadersteller mit I2C als Möglichkeit angefangen hatte). Und das ist gerade für diese Anwendung ja wohl das ungeeigneteste. Deshalb mal meine Vermutung, daß I2C in diesem Thread irgendwie unbeliebt ist.
Also: Warum macht ihr das mit RS232 ? Wenn man die RS232 standardmäßig verbindet, gibt es nur einen Empfänger und einen Sender. Wenn es dann noch ein Kontroller mehr werden soll, was dann ? Für alles andere muß man mit RS232 tricksen. RS232 ist auch für weitere Strecken gedacht und nicht um schaltungsintern verschiedene Komponenten zu verbinden.
Ganz davon abgesehen würde ich mir diese Schnittstelle lieber für die Kommunikation mit dem PC freihalten.
I2C nimmt man für schaltungsinterne Kommunikation. Die Kommunikation ist hier auch schneller. Die Verbindung erfolgt einfach 1:1. D.h. alle Master und Slaves werden mit SDA und SCL parallel geschaltet.

Der Alarm diente hier nur dazu, Daniel hier von einer Sackgasse fernzuhalten ;-)

Gruß
pctoaster

Zitat:

---

Aber per TWI ist das bestimmt eleganter, vielleicht erklärts ja hier noch jemand...

---

Das hab ich gleich in meinem zweiten Post geschrieben. Aber es erklärt ja anscheinend niemand.... Wie wärs mal mit ner Schritt für Schritt Anleitung für Menschen die keine Experten in Programmierung/ Elektronik sind? Die Informationen die ich mir dafür rausgesucht hatte helfen mir nicht, ich finde einfach keine verständliche Step by Step Anleitung. Da mach ichs lieber mit rs232 und spare ein paar Stunden Recherche.

Viele Grüße,
William

Zitat:

---

Na, ja in diesem Thread scheint nur über RS232 als Kommunikationsweg diskutiert zu werden (obwohl der Threadersteller mit I2C als Möglichkeit angefangen hatte). Und das ist gerade für diese Anwendung ja wohl das ungeeigneteste. Deshalb mal meine Vermutung, daß I2C in diesem Thread irgendwie unbeliebt ist.

---

Das ist aber seeeeeehr weit hergeholt.

In diesem Tread wird nichts über RS422/485,Feldbus,CAN...etc. gesagt also sind alle RS422/485,Feldbus,CAN...etc. -Feindlich ?

Darf ich jetzt auch den Knopf für die Sirene drücken ?

Also immer schön geschmeidig bleiben. ;)

Zitat:

---

Also: Warum macht ihr das mit RS232 ? Wenn man die RS232 standardmäßig verbindet, ..................Die Verbindung erfolgt einfach 1:1. D.h. alle Master und Slaves werden mit SDA und SCL parallel geschaltet.

Der Alarm diente hier nur dazu, Daniel hier von einer Sackgasse fernzuhalten

---

Wie gesagt,alles ejne Frage der Anwendung.
wir sind noch nicht fertig mit der Sache also können wir am Protokoll noch rumhäkeln.

I2C ist ein fertiges Bussystem mit adressierung aber wie lange die Leitungen werden sehe ich noch nicht und Multimasterbetrieb ist nicht so ohne.

Was die erweiterbarkeit von RS232 angeht so ist das kein akt mehrere Empfänger an einem Master zu betreiben.
Horchen und empfangen können viele solange man die Signale nicht abwügt.


Und zur Geschwindigkeit ist noch anzumerken das die Kabelkapazitäten bei I2C ein Problem darstellen also wird man mit steigender Leitungslänge mit der Geschwindigkeit runtergehen müssen.
Da wir die Längen noch nicht kennen....Rest bekannt.




Jedenfalls sollte man erstmal herausfinden was genau gefordert ist bevor man Klimmzüge macht und sich wirklich in eine Sackgasse verrent.



PS:

Ich arbeite selber sehr gerne mit I2C.
Daher kenne ich auch die Fallstricke. ;)






@Willa

I2C mal eben erklären geht nicht.

@willa, da fängt man z.B. hier mal an
https://www.roboternetz.de/wissen/index.php/I2C. Was fehlt da noch?

@rather, klar gibt es noch CAN, RS485 usw. Aber die I2C ist im ATMega32 doch schon hardwaremäßig drauf und lacht einem förmlich an, wenn man in das Datenblatt schaut.

Was die Entfernung betrifft, habe ich zugegebenermaßen meine Glaskugel angeworfen und gesehen, daß Daniel Bascom verwendet und u.a. deshalb Probleme mit den Ressourcen des ATMega32 hat. Daher vermutlich Mega8 in der Nähe oder auf der gleichen Platine. ;-)
Man könnte natürlich die Frage stellen, warum er das nicht alles mit dem ATMega32 macht ....
Mit I2C habe ich bis jetzt nur EEprom Verbindungen realisiert. Der Crack bin ich da also nicht. Aber ich finde diese Schnittstelle recht problemlos. Multimaster braucht er doch nicht. ATMega32 ist Master, der Rest Slave.
Außerdem haben mit RS232 viele Leute hier ebenfalls Probleme. Gaaanz so einfach scheint das ja dann doch auch nicht zu sein. ;-)

Gruß
pctoaster

Zitat:

---

Außerdem haben mit RS232 viele Leute hier ebenfalls Probleme. Gaaanz so einfach scheint das ja dann doch auch nicht zu sein.

---

Ja, Probleme mit allem haben viele aber in diesen Fällen (RS232) liegts eher an der Umsetzung der Komunikation als an der Infrastruktur (Sprich Verkabelung).

Zitat:

---

Mit I2C habe ich bis jetzt nur EEprom Verbindungen realisiert. Der Crack bin ich da also nicht. Aber ich finde diese Schnittstelle recht problemlos. Multimaster braucht er doch nicht. ATMega32 ist Master, der Rest Slave.

---

Da sind schon einige Fallstricke drinne die auch regelmässig diskutiert werden.

Ich reisse se mal ganz kurz an.

Entfernungen sind eine Sache für sich.
Solange man auf einer Länge unterhalb 1m bleibt und keine Störgrösen auftrten ist alles recht Easy.
Ursprünglich ist TWI aka I2C aka I-Quadrat aka IIC also Inter-IC Bus als Geräteinterner Bus für den Unterhaltungssektor (Hifi/Video usw) gedacht gewesen also für ein behütetes (Geschirmtes( Umfeld.
Daher auch die besagten 400pF für die Leitungskapazität.
Sollte man wenigstens im Hinterkopf haben


Was das "Problemlos" angeht stimme ich dir zu da ja eigentlich schon alles vorgegeben ist.(Protokoll usw.) aber ein gleichwertiges "Master/Slaveprotokoll" ist auf einer Seriellen ebenso einfach machbar.
Der softwareaufwand ist natürlich da denn TWI gibts ab den Megas in jedem Controller in Hardware wärend man sich das für ne Serielle selberstricken muß.

Was den Controller als Slave angeht so muß man allerdings etwas vorsichtig sein.
Eine softwareemulation hinauf bis zu den Tinys ist in den meisten Fällen witzlos sobald neben dem "Slave" noch was wesentlich anderes läuft.
Bei den neueren Modellen ab Mega ist es leichter da sie auch einen Hardwareslave usw. bieten.
Da bieten mittlerweile alle Sprachen entsprechenden Support an.
Ich nehme das übrigens auch gerne.


Was die Resourcen unter Bascom angeht so sollte man das vorsichtig beurteilen.
Rein von der Sprache und dem Compilat her steht Bascom den anderen nicht viel nach.
Wie man das ja kennt führen bekanntlich viele Wege nach Rom und das auch beim Programieren.
Allerdings ist Bascom eine Typische Einsteigerdroge...äh...Sprache und Anfänger gehen mit den Resourcen in jeder Sprache gleich schlecht um.
Das gibt sich aber mit der Zeit :D


Beispiel aus meiner eigenen Bastelei:

In mir wuchs mal der Wunsch nach einer simplen Universallüftersteuerung mit Temperaturregelung.

Wunschliste:

Erfasster Temperaturbereich 10-70° Auflösung 1-2°
Lüfter wird per PWM (Nachgeschaltete Transe) angesteuert.
Es soll eine eigene Kennlinie auf die Lüfterdrehzahl gelegt werden.
Diese soll einfach per Serieller updatebar sein.
Ein Anlaufschutz sollte auch drinne sein.
Das Ganze bitte klein und preiswert.
Und noch einige andere Kleinodien.

Der Erste entwurf war ein Verhau der schon einen M16 erfordete (Code rund 10k).
War mir aber zu sperrig und zu teuer.
Dann hab ich das Ganze etwas Vereinfacht und in einen M8 gestopft.
War mir auch noch zu groß.

Dann hab ich die Struktur überarbeitet und die bequemen Makros durch einfache Befehle ersetzt.(Bruchrechnen einmal anders)
Schon passte er in einen Tiny26 und ich hatte noch 56 Byte (Glaube ich) frei.

Nach einigen weiteren optimierungen passte der ganze Krempel tatsächlich in einen kleinen 8-Poligen Tiny mit 1K Speicher.

Klein und Billig.

Das ganze dann als SMD und schon passt der Fuzzi in ein etwas längeres Sub-9 Steckergehäuse und die Versorgungsbuchse gleich mit.

Als die Tiny25/45/85 vor einigen Jahren kamen und der Preis passte hab ich die Soft einwenig erweitert (8k in nem 9-Poligen wollte ich schon immer haben) und einen etwas kräftigeren preiswerten Mosfet (SMD) verbaut um auch etwas größere Lüfter steuern zu können.
Das Tachosignal wird nun auch ausgewertet um entsprechend reagieren zu können.

Ich könnte jetzt mit den kleinen 8k-Controllern natürlich wieder meiner ersten entwürfe fahren aber wer will schon sowas ? ;)


Hier (woanders auch) im Forum sehe ich so manches Mal recht umständlichen Code aber irgendwann ensteht bei den Leuten eine gewisse Erfahrung und der Drang noch mehr Funktionen in den Speicher zu quetschen so das sie ganz von alleine damit anfangen den Code zu optimieren.
Is ganz natürlich und ich mache es ja auch so.

Zitat:

---

Man könnte natürlich die Frage stellen, warum er das nicht alles mit dem ATMega32 macht ....

---

Das ist seine Sache da will ich gar nicht reinreden.

Manchmal ist verteilte intelligenz ganz gut bzw. Spezialisierte chips.

Ich war mal auf der suche nach einer RTC (uhrenchip) die mehr bietet als die Üblichen DS13x7 oder PCF8xxx.
Schön wäre ein chip gewesen der auch einen DCF-Decoder bessesen hätte und fähig ist die antenne zu schalten.
Ich hab rumgefragt,gabs aber nicht.
Nur Unmengen an dummen Sprüchen in gewissen Foren
Also hab ich mir selber einen gestrickt.
Einen Tiny13 der schon von Hause aus mit wenig auskommt.
Waum das DCF nicht mit dem eigentlichen controller auswerten (Macht er ja quasi nebenbei) ?
Nun,der Uhrenchip sollte immer laufen wärend der Rest Zeitweise vom Netz geht aber die passende Zeit sollte sofort Verlässlichl sein.(Letzte Aktualisierung nicht älter als 24h) und nicht erst nach 3 Minuten.

Wie schon gesagt, viele Wege führen nach Rom :lol:

Hi Daniel,

Zitat:

---

Zitat von daniel.weber

.. einen Mega32 als Hauptcontroller ... der ... dem Mega8 ... mitteilt, der ... steuert ... an ...
.. wie realisiert man so eine Kommunikation? ... I²C / bzw SPI Bus gefunden. ... keine Idee wie ich so eine Schaltung aufbaue,

---

Die Sache ist nicht so kompliziert. Kompliziert wirds nur, wenn die Ratschläge heissen "... es erklärt ja anscheinend niemand ... ich finde einfach keine verständliche Step by Step Anleitung ...". Meist ein Hinweis auf fehlende Bereitschaft oder Fähigkeit zum Lesen und eben kein Ratschlag. Ich weiss nicht recht, ist das Forum ein Vorlese-Klub?

Generell solltest Du die doc´s von Atmel lesen (ok, 200 - 300 Seiten in Englisch sind nicht sooo easy) - dort steht fast alles drin. Und Du wirst sehen, dass das doc vom m32 und das vom m8 viele deckungsgleiche Informationen enthält. Deine beiden mega´s haben die T W I - Hardware , Du musst sie nur noch nutzen - das geht genauso "einfach" wie RS 232 - man muss es nur richtig machen und die Betriebsgrenzen kennen. Lies Dich ein und wenn Du dann noch Fragen hast - hier gibt es viele kompetente Menschen die sehr hilfsbereit sind. Ausserdem ist das I 2 C hier ebenso wie das S P I an dieser Stelle im RN-Wissen erklärt - Schritt für Schritt. Man(n) muss nur lesen können.

Ich hatte (auch) ne ganze Weile gebraucht, bis ich (auch) hier gefunden habe, dass der alte Spruch RTFM auch hier gilt. Und hier ganz besonders: die Atmels sind für industrielle Anwendungen gedacht - deshalb stellt der Chiphersteller ziemlich gute Unterlagen bereit. Sonst würden die Entwickler ja schnell auf andere Chips umsteigen. Und Ratber hat total recht und pctoaster auch, letzterer hatte auf die doc´s ja schon kurz und bündig hingewiesen und ich hoffe, Du hast Ratber´s Link auf das RN/I 2 C schon benutzt.

Also nimm Dir die doc´s und die anderen Informationen und viel Erfolg.

Zitat:

---

Die Sache ist nicht so kompliziert. Kompliziert wirds nur, wenn die Ratschläge heissen "... es erklärt ja anscheinend niemand ... ich finde einfach keine verständliche Step by Step Anleitung ...". Meist ein Hinweis auf fehlende Bereitschaft oder Fähigkeit zum Lesen und eben kein Ratschlag. Ich weiss nicht recht, ist das Forum ein Vorlese-Klub?

---

Es geht ja in diesem Thread eigentlich nicht um mich... Manchmal geht es in meinem Leben nur darum, Dinge so einfach und so schnell wie möglich zum (zuverlässigen) Laufen zu bringen. Für meine Zwecke brauch ich TWI nicht, deswegen mache ich einfach das was ich kann: UART benutzen. Grazile Eleganz in der Umsetzung zeig ich beim Eiskunstlauf (und bei der Auswertung meiner Messwerte), nicht immer jedoch beim (mir manchmal lästigem) Aufbau meines Setups.

Viele Grüße,
William

naja also ist ja nicht so, als hätte ich mich noch nicht mit der Thematik auseinander gesetzt. Mein Problem bei den Wikis über TWI ist momentan das recht wenig zum eigentlichen Schaltungsaufbau gesagt wird. Ich habe grob verstanden wie ich das in ein Bascom Programm bringe, allerdings kaum eine Vorstellung wie man es Hardwareseitig aufbaut. Ich vermute mal das irgendwo im Nirwana der 300 Seiten Datenblatt etwas dazu erwähnt wird, ich vermute auch mal, da es sich bei TWI ja um etwas Hardwareseitiges handelt, dass nur bestimmte Ports dafür zu verwenden sind. Im Wiki wird auch nichts von den Ports erwähnt. Na muss ich wohl noch lesen.

Zur Nutzung vom UART, habe ich getestet, funktioniert bedingt... mein Problem ist, dass ich vom Mega32 noch gerne an den PC senden / empfangen möchte, schließe ich aber den Mega8 und den 32 an dann erhalte ich nur Datenmüll, ich vermute das kommt zustande, da beide zur gleichen Zeit senden. UART würde funktionieren, wenn ich den PC komplett vernachlässige und nur die beiden verbinde. Oder stehe ich da nun komplett am Schlauch?

*verwirrt schau* :(

Zitat:

---

Zitat von daniel.weber

naja also ist ja nicht so, als hätte ich mich noch nicht mit der Thematik auseinander gesetzt. Mein Problem bei den Wikis über TWI ist momentan das recht wenig zum eigentlichen Schaltungsaufbau gesagt wird.

---

Dem kann abgeholfen werden.
Lies mal dies durch, das ist recht kompakt und enthält alle nötigen informationen.


Welche Pinne vom Controller für den Hardware-I2C (TWI) zuständig sind kannst du im jeweiligen Datenblatt nachlesen.
Desweiteren ist die dortige I2C (TWI) Sektion nicht zu groß als das man sich darin verlaufen könnte.