Forum

Hi,

hab im Urlaub mal wieer nicht die Finger von den µCs lassen können und mich etwas über die Kommunikation zwischen den selben schlau gemacht.
Nun möchte ich etwas basteln und experimentieren. Idee: mehrere z.B. Atmega16 (hab ich gard ne schachtel voll rumfliegen) sollen sich unterhalten - und das möglichst auch auf weitere Entfernung also z.B. überall im Haus verteilt) mit einem möglichst einfachen Bussystem.

Nun bin ich auf diverse Kommunikationsmöglichkeiten gestoßen, die aber alle unzulänglich erscheinen:

1-Wire: schön einfach, aber wie es scheint kann ich meine AVR nicht als Slave programmieren.

TWI/I²C: klingt toll, simpel zu programmiern, aber hat das Problemmit der Reichweite (hab was von 80cm gelesen...) und ob strenförmit erlaubt ist bleibt in den gelesenen Artikeln unklar.

SPI: auch nicht so dramatisch, gibt aber üblen Verdrahtungs-Salat durch die Slave-Select-Leitungen...

RS232: kann leider nur jeweils mit einem Prozessor kommunizieren

RS485: einfacher Bus, mehrere Slaves möglich - aber wenn ich das recht verstanden habe, habe ich den Programmierstress mit den ganzen Kommunikationsprotokollen und der Adressierung (was mir bei anderen Kommunikationsarten wenn ich das Recht verstanden habe mehr oder weniger abgenommen wird.)

CAN-Bus: scheint viele meiner Wünsche zu erfüllen - jedoch gibts kaum Atmel-Controller die das können - und auch da scheint die Programmierung etwas sagen wir mal "stressig" zu sein...

Gibts noch weitere Möglichkeiten, die ich noch nicht gefunden habe - die für mich geeignet und möglichst auf den AVRs zumindest grob vorbereitet sind?
Irgendwo habe ich was von nem Treiber gelesen um das TWI/I²C zu verstärken und längere Leitungen zu erlauben - bin diesbezüglich aber nicht wirklich weiter gekommen was das für Treiber sind und was der Bus dann leisten kann...

Bin für alle Tipps und Ideen dankbar!

Gruß
Carsten

--
Vermeintliche Tippfehler in diesem Posting sind keineswegs Rechtschreibfehler sondern Vorschläge für die nächste Rächtschraiprevorm ;o)

» RS485: einfacher Bus, mehrere Slaves möglich - aber wenn ich das recht
» verstanden habe, habe ich den Programmierstress mit den ganzen
» Kommunikationsprotokollen und der Adressierung (was mir bei anderen
» Kommunikationsarten wenn ich das Recht verstanden habe mehr oder weniger
» abgenommen wird.)

Den Programmierstress hast du mit allen Kommunikationsarten. Teilweise gibt es Programmpakete, die dir den Stress etwas abnehmen. Heisst aber nur, dass jemand anders den Programmierstress schonmal gemacht hast, und du dich in sein Programm reindenken musst (ist auch nicht viel weniger Arbeit)
Nen kompletten TCP/IP Stack gibts auch für Atmel - dann hast du Ethernet. Oder eines der einfacheren Ethernet Protokolle implementieren.

hws

»
» CAN-Bus: scheint viele meiner Wünsche zu erfüllen - jedoch gibts kaum
» Atmel-Controller die das können - und auch da scheint die Programmierung
» etwas sagen wir mal "stressig" zu sein...
»
» Gibts noch weitere Möglichkeiten, die ich noch nicht gefunden habe - die
» für mich geeignet und möglichst auf den AVRs zumindest grob vorbereitet
» sind?
» Irgendwo habe ich was von nem Treiber gelesen um das TWI/I²C zu verstärken
» und längere Leitungen zu erlauben - bin diesbezüglich aber nicht wirklich
» weiter gekommen was das für Treiber sind und was der Bus dann leisten
» kann...
»
» Bin für alle Tipps und Ideen dankbar!
»
» Gruß
» Carsten

Hi hws,

danke für deine schnelle Antwort!
» Den Programmierstress hast du mit allen Kommunikationsarten.
Ja gewisserweise schon - aber beim TWI/I²C z.B. habe ich auf dem ATmega16 ein Hardware-TWI-Interface, wo ich (wenn ichs recht verstanden habe) per Register festlegen kann ob ich Master oder Slave bin, ne Adresse zuweisen kann und er reagiert nur auf die ihm zugewiesenen Daten - das fand ich schon bestechend. das RS485 stell ich mir da deutlich komplizierter vor, weil ich eben zusätzlich zu der Datenkommunikation dafür sorgen muss, dass von allen mithörenden Slaves sich nur der gewünschte "angesprochen fühlt" und alle wieder reagieren wenn wieder ein neues Datenpaket mit neuer Adresse kommt. Und alle durcheinanderplappern sollten ja möglichst auch nicht.
Das mit dem TCP/IP klingt genial, ich hab einiges darüber gelesen - aber das ist mir ehrlich gesagt "nur fürs Hobby" einfach zu aufwändig - da brauchts noch einiges an Hardware drumherum und die Programmieung wird sicher ganz besonders lustig...

Gruß
Carsten

--
Vermeintliche Tippfehler in diesem Posting sind keineswegs Rechtschreibfehler sondern Vorschläge für die nächste Rächtschraiprevorm ;o)

» ein Hardware-TWI-Interface, wo ich (wenn ichs recht verstanden habe) per
» Register festlegen kann ob ich Master oder Slave bin, ne Adresse zuweisen
» kann und er reagiert nur auf die ihm zugewiesenen Daten -

er "klingelt" nur dann, wenn ein Byte für IHN angekommen ist. Was du mit dem Byte machst, ob du es zu einem langen Text auf dem Display zusammensetzt oder sonstwas - das musst du weiterhin selbst machen. Und irgendwann will der Slave mal senden. Wie erkennt der Master das und fragt den Slave ab?

» das RS485 stell ich mir da deutlich komplizierter vor,
» weil ich eben zusätzlich zu der Datenkommunikation dafür sorgen muss, dass
» von allen mithörenden Slaves sich nur der gewünschte "angesprochen fühlt"

DAS ist ja nun nicht das Problem.
Es gibt einen String, der mit STX anfängt und EOT z.B. aufhört. Das 2. und 3 Byte ist die Adresse. Alle Slaves empfangen im Hintergrund per Interrupt. Bei nem STX werden alle wach, prüfen die nachfolgenden Bytes. Und wenn das nicht die eigene Adresse ist, machen die Slaves garnix. Als Interruptroutine kostet das kaum Rechenzeit.

Ist es die eigene Adresse, musst du genauso programmieren wie beim TWI Interface.

hws

Hi,

» DAS ist ja nun nicht das Problem.
» Es gibt einen String, der mit STX anfängt und EOT z.B. aufhört. Das 2. und
» 3 Byte ist die Adresse. Alle Slaves empfangen im Hintergrund per Interrupt.
» Bei nem STX werden alle wach, prüfen die nachfolgenden Bytes. Und wenn das
» nicht die eigene Adresse ist, machen die Slaves garnix. Als

Das heißt also, ich arbeite genauso wie bei der RS232-Kommunikation (schon gemacht) indem ich Strings sende und die Slaves erkennen Anfang und Ende von alleine? - Klingt dann doch interessant für mich - ich müsste dann Quasi wenn ein String kommt genau diesen annehmen und "von Hand" die beiden Adress-Bytes überprüfen - und wenn die passen den Kram weiter verarbeiten? (die Weiterverarbeitung macht mir keine Sorgen - die Adressierungsgeschichte und das Problem "Übertragungslänge", die sich damit ja beide erledigt haben waren mein gedankliches Problem.
Gut, dann werd ich bei der nächsten Bestellung mal ne Handvoll passender Treiber mit bestellen - lass raten: "max485"? ;o)

Danke Dir!

Gruß
Carsten

--
Vermeintliche Tippfehler in diesem Posting sind keineswegs Rechtschreibfehler sondern Vorschläge für die nächste Rächtschraiprevorm ;o)

» Das heißt also, ich arbeite genauso wie bei der RS232-Kommunikation (schon
» gemacht) indem ich Strings sende und die Slaves erkennen Anfang und Ende
» von alleine? -

natürlich nicht von alleine.
Eine RS485 ist auf der µC Seite auch nur eine serielle Verbindung.

Interrupt kommt jedesmal, wenn ein Byte empfangen wurde.
ist byte STX -> nein, dann zurück und nix machen
-> ist STX: nächstes Byte lesen und Adresse feststellen.
ist Adresse korrekt: -> alle nächsten Bytes bis EOT mitlesen und Speichern.


hast du schon jemls ne Interruptroutine programmiert? z.B. nen Timer für ne Uhrzeit?

» Quasi wenn ein String kommt genau diesen annehmen

Es kommt kein String, sondern immer nur ein Byte. Du musst dir Flags setzen, ob es ein String für diese Einheit ist.
Denn nach jedem Empfangenen Zeichen beendest du die Interruptroutine. Und beim nächsten Zeichen fängst du ganz jungfräulich wieder an. Damit du weisst, ob das vorherige Zeichen ein STX war oder ob du gerade mitten in einem auszuwertenden String bist oder ... musst du dir ein passendes Flag setzen und bei jedem Buchstaben abprüfen.


» und "von Hand" die beiden Adress-Bytes überprüfen

ja, nach STX ein Flag setzen und bei den nächsten beiden Interrupts die Adressen vergleichen.

» - und wenn die passen den Kram weiter
» verarbeiten?

Du bekommst jedesmal nur EIN Zeichen. Je nachdem welche Flags du gesetzt hast müssen die Zeichen in einen Puffer oder mit den Zeichen wird garnix gemacht (wenns nicht für die Einheit ist.

Im Hauptprogramm schaust du, ob was im Buffer steht (das ist dann für diese einheit) und wenn was drinsteht, dann guckst du was du damit machen willst.

» (die Weiterverarbeitung macht mir keine Sorgen - die
» Adressierungsgeschichte und das Problem "Übertragungslänge",

Wenn Zeichen EOT kommt, ist der String zuende. Dann wird ein Flag gesetzt im Interrupt und das Hauptprogramm kann daran erkennen, dass jetzt ein kompletter String vorbei ist.

Versuch erstmal interrupts zu verstehen. Bau dir mit einem internen Zeitgeber und Interruptverarbeitung ne Uhr.

hws

Hi,

danke für die ausführliche Beschreibung - klar,mit den Interrupts hab ich schon öfter rumgespielt - kannte ich auch schon von früheren Programmieungen am PC. Die sind also kein Problem.
Ok du hast jetzt die komplette Methode zu Fuß erklärt - hab ich auch kapiert - ich schätze auch so werde ichs machen. Bei meiner letzten Antwort habe ich mal wieder in BASCOM-Strukturen gedacht (die sitzen mir noch sehr im Kopf, auch wenn ich mich inzwischen auch an C herangetraut habe). In Bascom gibt es halt fertige Routinen zur Ein-und Ausgaben von Strings über die RS232 (naja aber diese Routinen werden eben ins Geheim im Hintergrund genauso arbeiten wie das was Du beschrieben hast - nur halt ohne Adress-Bytes...)

gut gut, ich werd mir halt mal ein paar von den max485 kommen lassen und spielen....

Gruß
Carsten

--
Vermeintliche Tippfehler in diesem Posting sind keineswegs Rechtschreibfehler sondern Vorschläge für die nächste Rächtschraiprevorm ;o)

mach mal zum Üben ne RS232 Kommunikation mit dem PC. (kann auch per TTL Level sein, kommt nur drauf an, dass du am AVR Seriellpinchen ein korrektes Signal bekommst)

Auf dem PC läuft Hyperterminal. (besser: Google mal nach Bray Terminal. Freeware - und wenn du's ausprobiert hast wirst du Hyperterm sofort löschen)

Dein AVR empfängt die seriellen Zeichen im Interrupt und schreibt sie in einen Buffer und setzt ein Flag.

Das Hauptprogramm macht nix anderes, als ein Zeichen aus dem Buffer zu holen (FALLS eins da ist) und dieses Zeichen z.B. auf einer LCD anzuzeigen.

Damit hast du schon die Hälfte deiner RS485 Kommunikation geschafft.

STX und OEF werden in der Interruptroutine abgefragt. Ebenso die Adressierung - uud wenn es die passende Adressierung ist, in den Buffer geschrieben. Ebenso ein Flag gesetzt, welches sagt: es ist OET aufgetreten und der String hatte die korrekte Adresse.

Ist es nicht die passende Adresse, wird auch nix in den Buffer geschrieben und das Hauptprogramm findet dort keinen String und kein EOT Flag.

hws

Hi,

Bray-Terminal kannte ich noch nicht -ich habe für solche Scherze immer das AVR-Terminal von der Rowalt-Seite genommen. Genial hierbei, dass man sich die Ausgabe auch Graphisch machen lassen kann, was u.U. übersichtlicher ist als Zahlenkolonnen...

Eigentlich sollten meine ST485 schon heute vom großen C kommen aber irgendwie hat das mit dem versprochenen schnellen Service wohl nicht hingehauen - ich hoffe morgen sind sie dann da - und wenn Frau und Kind mich lassen werd ich direkt mal rumprobieren.... ;o)

Gruß
Carsten

--
Vermeintliche Tippfehler in diesem Posting sind keineswegs Rechtschreibfehler sondern Vorschläge für die nächste Rächtschraiprevorm ;o)