Hi Ich möchte mein gesamtes haus mit einem ATMega 32 steuern. Nun frage ich mich, da ja alle geräte einige Meter auseinander liegen, welcher Bus mit relativ geringem Aufwand, "Längenstabilität" (also dass es auch auf großer Entfernung funzt) und vor allen Dingen große erweiterungsmöglichkeiten haben. Bis jetzt sind mir duch den Kopf geschossen: - I²C - CAN - RS485 Beim I²C bus habe ich jedoch die Meinung, dass ich nicht genug Erweiterungsmöglichkeiten habe, da ich von jedem IC nur 8 Stück (da 3 Adressbits) anschließen kann. Welchen Bus würdet ihr nehmen (auch gerne andere Busse ;-) )? Edit: Bitte in das Unterforum "Hausbus" verschieben. Danke^^
I2C schafft die Länge nicht. RS485 sollte nur verwendet werden, wenn genau eine Station alle anderen abfragt. Sonst CAN. Ansonsten: Forum "Hausbus".
>Welchen Bus würdet ihr nehmen (auch gerne andere Busse ;-) )? Einen Hausbus: http://www.mikrocontroller.net/forum/11
sry, ich hab vergessen den innen Hausbus Unterforum zu setzten desshalb auch oben mein edit. Zum Thema RS 485 würde ich gerne noch wissen, was für ICs man als Slave verwenden kann. Da habe ich noch keine Ahnung. Ist das so ähnlich wie beim I²C-Bus? PS: Danke für das Verschieben!
Hi Mats, "RS485" ist nur die physikalische Schnittstelle, sie erweitert praktisch RS232 auf "Multi- Slave", d.h. ein Master kann dadurch mehrere Slaves bedienen. Leitungslänge hängt von der Datenübertragungsrate ab und kann einige 100m betragen; der Bus muß allerdings an beiden Enden terminiert werden. Achso, nun zu Deiner eigentlichen Frage ;-) Da Du ja eigentlich mit RS232 zu tun hast, müssen Deine Slaves auch eine gewisse Eigenintelligenz besitzen; irgendein ATtiny/PIC sollte es schon sein. Die RS232 <-> 485- Umsetzung erledigt übrigens z.B. ein MAX 485. Ich plane derzeit eine Alarmanlage, in der die Zentrale mit mehreren dezentralen Slaves kommuniziert; ich werde wohl auch einen RS485- Bus nehmen. Gruß, Ralle
vielen Dank. kann ich also auch nen ATtiny nehmen, der dann an nem I²C hängt und darüber daten von I/O Port-Erweiterbausteinen an den Master weiter leitet? bzw. wenn mir die I/O vom ATtiny genügen ja auch diese nehmen...
und da ich irgendwie leider nicht editen kann hier noch ein PS: und wie können die beiden Microkontroller miteinander kommunizieren zbw. wie lege ich transferrate etc fest, etwa so: PortA.5 = 1. bit des packets waitms=1 PortA.5 = 2. bit des packets waitms=1 ... oder wie??? ich bin da noch was überfordert. gibts da irgend einen link? :-(
Anstelle von RS485 bietet sich RS422 an, das passt besser an einen PC. Der RS422 hat ein Leitungspaar in jede Richtung und muss nicht umschalten. Wenn man da noch einen GND und 24V mitlaufen laesst, ist man schon dabei.
Im Grunde genommen hast Du bei RS485 ja software-seitig mit RS232 zu tun. Wenn Dein ATtiny Ein UART hat, dann kannst Du die Kommunikation ihm überlassen. Also einfach die Bytes in das entsprechende Register schaufeln und ab gehts. Wenn Dir die I/Os des ATtiny reichen, dann würde ich die auch nehmen.
Ich benutze RS485 mit einem CAN-Treiber (82C250). Das hat den Vorteil, dass ich einerseits einfach Daten mit der RS232 rausschicken kann und andererseits kein Umschalten der Datenrichtung wie bei RS485-Treibern notwendig ist. Da der "0"-Pegel sich durchsetzt, ist sogar eine Arbitrierung möglich. Beim Senden eines Pakets empfängt man seine eigene Sendung ebenfalls, so kann man feststellen, ob noch ein anderes Modul gesendet hat.
Ist es auch möglich, eine Art I²C over RS 485 zu gestalten? Dabei kann ich ja die Hardware selber bauen und es ist ohne viel Aufwand ein Datentransfer zwischen I/O Epandern sowie anderen Mikrokontrollern möglich.
Ich bin mir nicht ganz sicher ob das funktioniert, weil RX und TX des 82C250 dann zusammengeschaltet werden müssten - ich denke, dass sich dann dauerhaft die "0" durchsetzt - ähnliches Problem wie bei der galvanischen Entkopplung des I²C. Was auf jeden Fall funktionieren sollte: Das I²C-Protokoll per Software nachgebildet und für jede Leitung (SDA und SCL) jeweils 2 Pins benutzt - einer als Eingang, einer als Ausgang. Dann via 82C250 als Differenzsignal übertragen. Arbitrierung und Waitstates wären kein Problem, da (wie schon oben erwähnt) die "0" priorisiert ist. Man bräuchte dann für jeden Baustein 2x 82C250 und die Übertragung würde mit 4 Adern stattfinden.
Versuch lieber nicht, aus solch bizarre Lösungen wie eben beschrieben zu realisieren, bloss um auf schon bekanntem I2C aufzusetzen. Grad weil so ein Hausbus ein bischen länger lebt, wirst du dich sonst garantiert später mal in den Hintern beissen. Ein MCP2515 ist weder teuer noch kompliziert. Ähnliches gilt übrigens auch für RS485 vs. CAN. Auch wenn du heute vielleicht nur einen Master brauchst: Bist du sicher, dass dies in 3 Jahren auch noch gilt?
CAN ist nicht zwangslaeufig geeignet. Die maximale Messagelaenge ist etwa 6 byte. Genuegt das fuer Alles ? Z.
Nochmal zu I2C: Wie viel Reichweite bringt ein Bus Extender? Reicht das dann für ein Haus? btw gibt es ja noch die Multiplexer, welche ich auch bedenke einzusetzen. Edit: haben wohl gleichzeitig gepostet ;-) Also ich glaube das könnte je nachdem was ich verschicke was kurz sein...
Das Problem des I²C kann man nicht durch Bus-Extender oder Repeater lösen. Das Problem ist die Störsicherheit, die bei I²C gegenüber RS485 wesentlich schlechter ist. Bei RS485 (und auch CAN) wird ein differentielles Signal übertragen. CAN ist nicht so weit von RS485 entfernt, bis auf ein normiertes Protokoll und leicht modifizierten Bus-Treibern. A.K.: Warum sollte bei der RS485-Lösung mit den CAN-Treibern kein Multi-Master möglich sein? Das funktioniert bestens.
also ich denke das läuft jetzt auf eine art I²C over Rs 485 hinaus. mal sehen wie sich die schaltung entwicken wird. nochmal vielen Dank für eure hilfe!
@Thomas Kaiser: > Warum sollte bei der RS485-Lösung mit den CAN-Treibern > kein Multi-Master möglich sein? Das funktioniert bestens. Klar geht das. Aber bis man RS485 eine saubere funktionierende Arbitration beigebracht hat, da vergeht m.E. schon etwas Zeit - den einen oder anderen in diesem Board hat das schon zur Verweiflung getrieben. Und seit CAN günstig und platzsparend zu haben ist, fehlt mir da irgendwie der Sinn drin. @Zossi: > CAN ist nicht zwangslaeufig geeignet. Die maximale Messagelaenge ist > etwa 6 byte. Genuegt das fuer Alles ? Ich übertrage damit auch ein komplettes Dataflash, häppchenweise eben, normalerweise inkrementell, aber wenn's sein muss auch komplett. Aber stimmt schon: ist für grosse Datenmengen nicht konzipiert. Sowas ist allerdings für eine Haussteuerung nicht unbedingt typisch.
Vergiss den I2C, das ist ein synchroner Bus. Ein Hausbus sollte asynchron sein, ausser man macht sich die Muehe, auch noch einen Clock zu uebertragen. Differentiell ist eh eine gute Wahl, da es viel stoerungsunempfindlicher sind. Man sollte nur schauen, dass man den GND zusammen mit dem(n) Datenpaar(en) mit verkabelt. Dann gibt es differentielle Transceiver mit mehr und weniger Gleichtaktspannung. Die 7V sind schnell erreicht. Z.
PS: Mit ein bischen Fantasie und einem gerüttelt Mass an Ignoranz allen üblichen Software-CAN-Layern gegenüber sind auch 10 Bytes pro Message drin.
>Was auf jeden Fall funktionieren sollte: Das I²C-Protokoll per Software >nachgebildet und für jede Leitung (SDA und SCL) jeweils 2 Pins benutzt - >einer als Eingang, einer als Ausgang. Dann via 82C250 als >Differenzsignal übertragen. Muss ich da auf irgend ein Faktor der Länge (der Datenpackete und Kabellänge) etc. wie beim Can-Bus achten oder kann ich einfach im Protokoll das I²C verwenden? Des weiteren ist die Frage, ob ich diese "Knotenverbindung" machen muss oder ob ich auch beispielsweise ein 100 Meter langes Kabel zu einem Slave und von da zu 10 weiteren Slaves je ein 10 Meter Kabel legen kann. Wie ist es mit diesen "Abschluss-Widerständen", muss ich die auch verwenden und wenn ja (bei der Sternstruktur) wo? (http://www.netzmafia.de/skripten/netze/netz1.html)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.