Tag zusammen, ich bin bei der Planung meiner Hausautomatisierung jetzt bei einer zentralen Lösung mit Relais und Stromstoßschaltern gelandet und stehe vor der Herausforderung rund 200 Ein- oder Ausgänge mit einem AVR (z.B. ATmega 32) zu verbinden. An den Eingängen befinden sich Schalter, Taster und Relais von den Bewegungsmeldern, an den Ausgängen die Relais oder Stromstoßschalter. Meine Idee war es nun die 200 Anschlüsse auf 16 Module mit je 8 Ein und 8 Ausgängen aufzuteilen. Jedes Modul soll eine Adresse bekommen und einen Bus angeschlossen werden. In jedem Modul befindet sich ein Latch, was den Zustand der bis zu 8 angeschlossenen Relais hält und über einen ULN2803A die Relais ansteuert. Soweit ich das verstanden habe reichen die internen Schutzdioden für einen sicheren Betrieb aus. Bei einem Strobe-Signal sollen die am AVR anliegenden Pegel übernommen werden. Ein weiteres Latch soll bei einem Strobe-Signal die Schalter/Taster-Zustände einfrieren und dem AVR bereitstellen. (z.B. so lange die Strobe anliegt?!). Für einen konkreten Schaltplan fehlt mir allerdings die Erfahrung und vor allem der Überblick über die verfügbaren Bauteile. Ich würde gerne auf jedem Modul einen 4-fach DIP-Schalter (oder Jumper) unterbringen, um die Adresse festzulegen. Gibt es da fertige Bauteile, die bei übereinstimmender Adresse "ja, hier ich!" melden? Ich möchte ungerne einen kompletten ATtiny für so was stupides einsetzen. Die größte Unsicherheit habe ich bei der Frage, wie die Strobe und die Adresse mit den Latches verbunden werden sollen. Wahrscheinlich gibt es da eine Standardverschaltung. Ich lasse mir die Schaltung auch gerne noch mal über den Haufen werfen, wenn das nötig sein sollte, ich wollte mich nur schonmal selbst daran versuchen. Ach ja: Unter welchen Umständen muss der Bus terminiert werden - und vor allem wie? Ich würde mich über eine Unterstützung bei dem Projekt freuen, Kai
Angehängte Dateien:
-
Verteiler.png
39 KB
Wie wäre es denn mit einem seriellen Bus, z.B. RS485. Da würde ich jedem Slave einen eigenen Prozessor gönnen. Das ganze mit einem einfachen Protokoll. Damit hast du 2 Busleitungen (+Masse) statt 21 + Masse. Die serielle Verbindung ist außerdem auch störunempfindlicher. Evntuelle Fehlererkennung kann man durch Parity-Bits in Hardware und Fehlerkorrektur per zusätzlichem Zeilen/Spaltenparity erreichen. Damit hat man dann einen 2-Fehler-erkennenden, 1-Fehler-korrigierenden Code erreicht. Bei Rückmeldungen von Slaves kann nochmal zusätzlich vom Master aus festgestellt werden, ob die Nachricht auch fehlerfrei angekommen ist(z.B. CRC oder Prüfsumme zusammen mit ACK zurücksenden). mfg mf
Ich gehe mal davon aus, dass die I/Os und der AVR ortsnah sein sollen (sonst gaebe ein paralleler Bus ja keinen Sinn). Viel einfacher waere es dann wenn Du 82C55 nimmst. Jeder 82C55 hat 24 I/O Ports. Du brauchst also 8 Stueck davon (ja, sind halt nur 192 I/Os). Alle Steuerleitungen werden verbunden, bis auf die Chip Selects, die dekodierst Du mit einem 74HC138 (3 zu 8 Dekoder). Du hast also: 8 Datenleitungen 2 Adressleitungen /RD /WR 3 Adressleitungen zum '138 Insgesamt also 15 Leitungen zum AVR, und Du kommst mit 9 ICs und einem deutlich geringeren Platzbedarf aus.
Moin Moin k.a. wie weit die module entfernt sind, aber vielleicht tuns auch ein paar i2c io bausteine? grüße tassilo
also mal im ernst die latches brauchst du nicht.. uln2803 ist ungeeignet, treibt viel zu wenig, für schütze etc reicht das nicht außerdem brauchst du definitiv noch freilaufdioden wenn das ding länger als nen tag laufen soll.. ich würde dir wirklich dazu raten fertige IO module auf basis von CAN, RS485 oder so zu kaufen und dich nur um die steuerung dieser zu kümmern
Hallo, schau mal hier http://www.e-lab.de/diverse/components.html. Suchen nach "I2C Digital IO". Reichlich davon besorgt und noch ein "EvaBoard" dazu. Eventuell braucht man einen zweiten I2C. Da reicht ja dann eine Softwarelösung. Fertig ist die Laube. Gruß Rene
>Für einen konkreten Schaltplan fehlt mir allerdings die Erfahrung und >vor allem der Überblick über die verfügbaren Bauteile. Wie wäre es mit einem I2C IO Expander z.B.: CAT9555. Da hättest du mit 13 IC's je 16 IO's deine 200 I/Os abgedeckt.
Hallo Kai, der von dir eingestellte Plan (eher Blockdiagramm) ist doch schon recht gut. Ich habe etwas ähnliches gerade aufgebaut um Kabel mit ca. 32 Adern auf korrekten Zusammenbau zu testen. Dazu brauche ich insgesamt 64 I/Os. Das habe ich ähnlich gelöst. Einmal einen 8-Bit Datenbus den ich vom Hauptmodul an alle Module verteile und zusätzlich einen 8-Bit Adressbus den ich ebenfalls an alle Module verteile. Der Adressbus wird über 74238er angesteuert. Am Datenbus angeschlossen befinden sich 74573er als Latches. Das EN Signal für das Latch wird aus einem WE-Strobe Signal und einem CS-Signal erzeugt. Ich führe also 8 CS-Sigale an jedes Modul +WE (+RE). Ein Jumper bestimmt nun welche Adresse das Modul hat. Du könntest das Prinzip auch auf 16-Bit aufbohren. Ich meine im Datenblatt vom 74573 ist sogar ein Aufbau zur Kaskadierung beschrieben. Wichtig bei diesem Prinzip ist halt, dass alles an einem Ort ist. Andernfalls solltest du auf bereits beschriebene Lösungansätze zurückgreifen, bei denen du einen seriellen Bus + uC (ATTiny) zurückgreifst. Andi D. schrieb: > außerdem brauchst du definitiv noch freilaufdioden Da stimme ich zu. Das ist immer sicherer Gruß lowlevel
Erstmal danke an alle für die ausführlichen Anworten! Da ist ja alles mit dabei - von "kannst du so machen" bis "auf keinen Fall". Viele raten ja zu einem Master-Slave-Aufbau mit mehreren Controllern mit serieller Verbindung. Ich dachte die parallele Variante wäre einfacher und fehlerunanfälliger. Es gehen ja keine hohen Datenraten drüber. Das Ganze soll im oder unmittelbar am Schaltschrank aufgebaut werden. Die parallelen Leitungen werden nicht länger als vielleicht einen Meter. Das mit den zusätzlichen Schutzdioden ist notiert! Ach ja, streng genommen brauche ich keine I/Os. Jeder Kanal ist entweder ein Eingang oder ein Ausgang. Ich muss jetzt nochmal alle vorgeschlagenen Bauteile und Aufbauten verstehen. Schöne Grüße, Kai
Kai Giebeler schrieb: > Viele raten ja zu einem Master-Slave-Aufbau mit mehreren Controllern mit > serieller Verbindung. Ich dachte die parallele Variante wäre einfacher Du brauchst am anderen Ende sowieso irgendwelche Elektronik. Dann kann es auch gleich ein kleiner µC sein, der die Übertragung auf Fehlerfreiheit prüft. > Das Ganze soll im oder unmittelbar am Schaltschrank aufgebaut werden. > Die parallelen Leitungen werden nicht länger als vielleicht einen Meter. Je mehr Kabel, desto mehr Möglichkeiten, dass etwas passieren kann.
Gut, dann verfolge ich mal den Ansatz mit EIA-485 als Bus mit entsprechendem Protokoll. Auf die Slave-Module würde ich dann direkt einen ATmega packen. Damit spare mir die Latches, den Adressdecoder und habe noch Platz für etwas Eigenintelligenz. Kann/soll/muss man die Schaltung gegen die EM-Unruhen im Schaltschrank schützen? Ich wollte die Module in je einem Hutschienengehäuse unterbringen. Dann war da noch: > uln2803 ist > ungeeignet, treibt viel zu wenig, für schütze etc reicht das nicht > außerdem brauchst du definitiv noch freilaufdioden wenn das ding länger > als nen tag laufen soll.. Wie sieht denn die optimale Ansteuerung von 24 V/DC-Relais und Stromstoßschaltern aus? Ich würde bei der Menge ungerne einen diskreten Treiber bauen müssen. Danke und schöne Grüße, Kai
Kai Giebeler schrieb: > Wie sieht denn die optimale Ansteuerung von 24 V/DC-Relais und > Stromstoßschaltern aus? Kommt in einem gewissen Rahmen darauf an, wieviel Strom die haben wollen. Mit ein wenig Glück bist du mit einem ULN2803 schon dabei.
Als Stromstoßschalter bin hier hier gelandet: Finder 20.22.9.024.4000 230 mA @ 24 V/DC, wenn ich das Datenblatt richtig verstehe Die Relais: Finder 22.21.9.024.4000 52,2 mA @ 24 V/DC Beim ULN heißt es in den Absolute Maximum Ratings: 500 mA Continuous Collector Current Das passt meiner Meinung nach also ganz gut. Ich versuche jetzt noch rauszubekommen, wie hoch die Leistungsabgabe ist ... Gruß, Kai
LOL @Karl heinz, du bist vielleicht ein Scherzkeks. Für ein paar I/Os über eine Strecke von ein paar Zentimetern ein RS-485 Bussystem stricken? Das macht man sicher mal an nem Nachmittag, ROFL! Das komplette Protokoll mit Fehlerkorrektur und allem! Das Debuggen wird bestimmt auch Ruckzuck erledigt sein! Du ziehst dir die Hosen auch mit der Beißzange an, oder? Und da wundert man sich, wieso niemand Indschenöre einstellen will ... Kai, tu dir einen Gefallen und mach das mit den 8255.
Horst-Otto schrieb: > LOL @Karl heinz, du bist vielleicht ein Scherzkeks. Für ein paar I/Os > über eine Strecke von ein paar Zentimetern ein RS-485 Bussystem > stricken? 1) war RS-485 nicht meine Idee 2) denke ich nicht, dass 200 Ausgänge sich auf ein paar Zentimetern ergeben > Kai, tu dir einen Gefallen und mach das mit den 8255. und was ist jetzt der Vorteil an diesem Dinosaurier?
Karl heinz, hast du schon mal mehr als ein Hello World in BASIC programmiert? Auf der einen Seite hast du einen einzigen Controller, der ein paar I/Os schaltet, auf der anderen Seite ein Netzwerk aus 10 Controllern, mit eigenem Protokoll und Pipapo. Meinst du nicht, daß das ein klitzekleiner Unterschied in der Komplexität, Fehleranfälligkeit und Debugbarkeit ist? Meinst Du, es verlangsamt die Entwicklung, bei jeder Codeänderung 10 Controller zu programmieren und mindestens zwei verschiedene Code Repositories zu verwalten? > 2) denke ich nicht, dass 200 Ausgänge sich auf ein paar Zentimetern > ergeben Du hälst es ernsthaft für ausgeschlossen, 10 ICs auf eine Platine zu packen? > und was ist jetzt der Vorteil an diesem Dinosaurier? Du meinst abgesehen von den Punkten, die ich bereits aufgezählt habe? OK, billiger und schneller sind sie auch noch. Und es gibt wohl einen Grund, daß diese ICs seit 30 Jahren hergestellt werden und immer noch von einem halben Dutzend Hersteller verfügbar sind. Sie haben sich BEWÄHRT. AVRs gibts ja jetzt schon kaum noch zu kaufen. Wenn in 15 Jahren ein Gewitter die I/O ICs killt, dann gibt es immer noch 82C55 zu kaufen. Der ATMegaschlagmichtot ist dann seit 10 Jahren abgekündigt und Neuentwickeln ist angesagt. Hoffentlich hast du wenigstens die Sourcen noch ...
Horst-Otto schrieb: > Karl heinz, hast du schon mal mehr als ein Hello World in BASIC > programmiert? Ha, ha Da muss ich jetzt lachen! Ich denke, ich bin dir ein paar Millionen Lines of Code vorraus. In dem Punkt legst du dich mit dem Falschen an. > Du hälst es ernsthaft für ausgeschlossen, 10 ICs auf eine > Platine zu packen? Aufgrund welcher seiner Aussagen schliesst du, dass alle 200 Ausgänge auf einer einzigen Platine beisammen sind?
Die von mir gewünschte Aufteilung in mehrere identische Module war schon Absicht. Wenn mir ein Modul ausfällt kann ich es einfach tauschen - dafür wären dumme Module eigentlich besser. Alles auf einer Platine wäre ziemlich unsinnig. Das mit dem Programmieren der Einzelmodule hätte ich gerne vermieden, ist aber auch kein k.o-Kriterium. zumal ich besser programmieren kann als Schaltungen zu entwerfen ;)
Angehängte Dateien:
Anbei mal ein erster Schaltplan. Stellt euch statt dem ATmega8515 einen ATmega162 vor, der mit RX0/TX0 mit dem MAX481 (der eigentlich ein MAX485 sein soll) verbunden ist. Die Klemmen für die 24 V, die 5 V sowie den Bus fehlen noch. Ich suche jetzt erstmal eine Software, mit der man die Platine in der richtigen Größe erstellen kann - auf ein halbes Europakartenformat passt das nicht sinnvoll ... Schöne Grüße, Kai
Hi
>Anbei mal ein erster Schaltplan.
Warum benutzt du für die RS485 nicht die UART des Controllers?
MfG Spess
Vielleicht gibt es ja eine fertige c-lib, wo die Daten gleich überprüft werden. Ich hab mir auch schonmal einen Plan gemacht, sozusagen eine PIC-SPS zu machen. Man könnte zur Prüfung die Daten, die vom Master zum Slave gesendet worden sind, wieder zurücksenden. Die Warscheinlichkeit, dass ein Fehler durch einen anderen Fehler wieder rausgenommen wird, ist ja relativ gering. Um Zeit zu sparen, könnte man sagen, dass, wenn der Master keine neuen Daten (die gleichen wie zuvor) sendet, war alles in Ordnung. Karl heinz Buchegger schrieb: > Horst-Otto schrieb: >> Karl heinz, hast du schon mal mehr als ein Hello World in BASIC >> programmiert? > > Ha, ha > Da muss ich jetzt lachen! Ich auch^^ Du tust mir schon fast leid, schon ein zweiter Thread, wo man dir was will ;)
Kai Giebeler schrieb: > In jedem Modul befindet sich ein Latch, was den Zustand der bis zu 8 > angeschlossenen Relais hält und über einen ULN2803A die Relais > ansteuert. Gibt es als ein Bauteil von Micrel: MIC5800/MIC5801 Bustechnisch würde ich persönlich CAN nehmen: du brauchst dich nicht ums Protokoll kümmern, da jedes Modul eine eigene ID bekommt und die Kollisionsgeschichte direkt vom Controller übernommen wird.
Kai Giebeler schrieb: > Stellt euch statt dem ATmega8515 einen ATmega162 vor Warum machst du das ganze nicht Memory-Mapped, wenn du schon einen Controller mit externem Interface einsetzt?
@Kai Anmerkung am Rande, ich habe die Tage einen Protoytpen zum PCB-Pool gejagt, auf dem pro 8 Kanäle ein ATtiny2313 und ein ULN2803 sitzt. Bzgl. der Freilaufdioden, da nutze ich die internen des ULN2803 und zuätzliche Finder Relais mit Entstörelektronik. Zusätzlich gibt es einen weiteren, neunten, ATtiny2313 der sich um Überwachung kümmern kann. Als Anbindung kommt ein MAX489 Full-Duplex RS-485 Treiber zum Einsatz. Klingt erstmal kompliziert und nach Kanonen zum Spatzen erlegen, ist es aber nicht. Ein ATTiny2313 kostet unter 2€, kann man also auch neben ein paar Ersatz ULN2803 auf Halde legen. Und ne ganze MCU pro 8 Ports hat den Vorteil das eben auch nur 8 Ports ausfallen wenn ein Controller stirbt ;-) Insgesamt habe ich pro Modul 8x ATtiny2313 plus ULN2803, nen Quartzoszillator und einen "Master" ATtiny2313(der kann auch weggelassen werden). Das Ganze passt samt Spannungsregler und Steckklemmen auf eine zweiseitige Euro-Platine, die ist dann aber auch gut voll. Gruß, Jan
Spess53 schrieb: > Warum benutzt du für die RS485 nicht die UART des Controllers? Mache ich doch (hatte versehentlich RX0/TX0 statt RX1/TX1 geschrieben). Der ATmega162 hat an PB2, PB3 seinen UART1. Micha schrieb: > Bustechnisch würde ich persönlich CAN nehmen: du brauchst dich nicht ums Habe versucht mich vor CAN zu drücken, da mir hier einfach die Erfahrung fehlt ;) - aber sinnvoll wäre das schon; bevor man sich eine eigene Kollisionserkennung schreiben muss. Micha schrieb: >> Stellt euch statt dem ATmega8515 einen ATmega162 vor > Warum machst du das ganze nicht Memory-Mapped, wenn du schon einen > Controller mit externem Interface einsetzt? Was hätte das für einen Vorteil? Wie genau stellst du dir das vor? Das klingt wieder nach einer parallelen Anbindung mit Adressdecoder und Co ... Danke und schöne Grüße, Kai
Was ich vergessen habe: Alle, ich nenne sie mal Portcontroller, lauschen über den selben RS485 Treiber. Soll aktiv zurückgesendet werden, dient der neunte Controller als Arbiter und koordiniert die Sendeberechtigung. Zum Vergleich ein 8 Port i2c IC kotste gerade mal 20 Cent weniger als ein ATtiny2313 und ist kein bisschen flexibel.
moin moin nur musst du dort erst mal alles in software schreiben... grüße
Hallo, wenn es sich hier doch um Leitungslängen von nur 1-2 Meter handelt, was haltet ihr von 4 niederohmigen Shift Register Leitungen, die von Modul zu Modul gehen. Alternativ Uart 5V in Richtung Master -> Empfänger der Slaves Parallel. Alle übertragungen mit Adresse, Daten und Prüfsumme. Als Rückantwort dient dann eine Ringleitung, die vom Master über einen Widerstand auf +5V gezogen wird. Empfängt jetzt ein Slave eine richtige Adresse mit Daten und RICHTIGER Prüfsumme so wird diese Leitung für eine gewisse Zeit auf GND gelegt. Detektiert der Master dies wurde das Paket richtig empfangen. Wird es nicht detektiert, wird nochmal gesendet. Gruß, Tubie
Tassilo Angus schrieb: > nur musst du dort erst mal alles in software schreiben... Das ist natürlich richtig, hat aber IMHO mehr Vor- als Nachteile. Das wird ja auch keine komplexeSoftware, ich werde sie komplett in Assembler schreiben.
Kai Giebeler schrieb: > Ein weiteres Latch soll bei einem Strobe-Signal die > Schalter/Taster-Zustände einfrieren und dem AVR bereitstellen. (z.B. so > lange die Strobe anliegt?!). http://tinyurl.com/xmega-help
Tubie schrieb: > Empfängt jetzt ein Slave eine richtige Adresse mit > Daten und RICHTIGER Prüfsumme so wird diese Leitung für eine gewisse > Zeit auf GND gelegt. Detektiert der Master dies wurde das Paket richtig > empfangen. Wird es nicht detektiert, wird nochmal gesendet. So ähnlich überlege ich das auf Modulebene zu machen ;-) Je einfacher das Protokoll um so besser, man kann ja mit einem regelmäßigen Refresh arbeiten, und spart sich ein vollwertiges Protokoll mit Kollisionsbehandlung etc.
Jan Schneider schrieb: > Je einfacher das Protokoll um so besser, man kann ja mit einem > regelmäßigen Refresh arbeiten, und spart sich ein vollwertiges Protokoll > mit Kollisionsbehandlung etc. So isses. Bei einem reinen Master-Slave-Protokoll braucht man keine Kollisionsbehandlung. Man muss nur eine gewisse Wartezeit vorsehen, falls ein Slave nicht antwortet, was die Übertragung verlangsamt, aber eine Kollisionsstrategie benötigt auch Wartezeiten und ev. Wiederholungen. Ich habe gute Erfahrungen mit der einfachen Strategie Befehl raus - Slave bestätigt, oder eben das ganze nochmal. Das einzig komplexe dran ist, nicht existierende Slaves nach einer Weile aus der Liste zu nehmen und neu eingeschaltete wieder rein. Das kann man sich aber auch sparen und bis in alle Ewigkeit alle möglichen Slaves abfragen, ob sie nun da sind oder nicht. Gruss Reinhard
Reinhard Kern schrieb: > Das einzig > komplexe dran ist, nicht existierende Slaves nach einer Weile aus der > Liste zu nehmen und neu eingeschaltete wieder rein. ist doch aber auch kein großes Problem mit der von mir oben beschriebenen Methode. Bei normalem ACK eines Datensatzes wird die Ringleitung für sagen wir 50ms auf low gezogen. Wird ein Gerät neu dazugeschaltet, zieht es die Leitung für 1 sec auf low. Das signalisiert eine Änderung am Bus und der Master kann alle Adressen mit einem Attention Signal abklappern. Gruß, Tubie
Man verdrahtet 200 I/O quer durchs Haus in einen Schaltschrank und macht sich dann über ein Bussystem innerhalb des Schaltschrankes Gedanken .. naja ;)
Tubie schrieb: > Reinhard Kern schrieb: > .... Wird ein Gerät neu > dazugeschaltet, zieht es die Leitung für 1 sec auf low. Das signalisiert > eine Änderung am Bus und der Master kann alle Adressen mit einem > Attention Signal abklappern. Hallo Tubie, klar funktioniert sowas, aber ich lege Wert auf Hardware-Unabhängigkeit, d.h. meine Protokolle sollen zumindest funktionieren mit V24 und allen Verwandten wie RS422, RS485 und und, sowie Ethernet (Internet) und USB. Da kann ich also nicht an einer Ringleitung zupfen. Praktisch arbeite ich ausschliesslich mit Senden und Empfangen von Strings, wie die meisten Internetprotokolle auch. Also eigentlich geht das dann mit jeder überhaupt denkbaren Hardware, auch wenn der Slave um den Jupiter kreist, da werden bloss die Wartezeiten etwas länger. Gruss Reinhard
Hallo Reinhard, das Protokoll basiert ja auf Uart, 8 Bit, usw... auch die Pegel sind auch wie auf der RS485. Nur der Rückweg wurde vereinfacht. Klar kann man auch auf dem Bus eine einfache Ack meldung versenden. Der Sender muß hierfür immer wieder auf empfang umschalten, Wartezeiten müssen beachtet werden. Was ist wenn ein Slave Gerät länger für die Antwort braucht (Warum auch immer?) und der Master schon wieder sendet dannm brauchts noch eine Kollisionsüberwachung Und wenn es was selbstgestricktes werden soll, dann warum nicht so? Theoretisch wäre auch eine Lösung denkbar bei der der Master nur sendet und der Slave nur empfängt. Ohne Rückantwort. Sowas in RS485 aufzubauen wäre immer noch am leichtesten. Uart auf 9Bit stellen Adresse mit Bit9=1, Daten mit Bit9=0. Jedes Paket wird sicherheitshalber 3x gesendet und das ganze bei 4800 Baud und eine Überwachung sollte überflüssig werden. Im ersten Post die Parallele Methode hat ja auch keine Überwachung drin. Gruß, Tubie
Tubie schrieb: > Uart auf 9Bit stellen Adresse mit > Bit9=1, Daten mit Bit9=0. Jedes Paket wird sicherheitshalber 3x gesendet > und das ganze bei 4800 Baud und eine Überwachung sollte überflüssig > werden. Im ersten Post die Parallele Methode hat ja auch keine > Überwachung drin. Jeder Slave könnte dann alle 3 betreffenden Pakete für Adresse und für Daten (insg. 6) auf gleichheit überprüfen. Tritt ein Fehler, wird nichts ausgeführt. So bleibt der aktuelle Zustand erhalten und man merkt, dass die Kommunikation nicht richtig funktioniert. Ich habe leider zur Zeit zu wenige Controller da, aber ich würde mich auch an der Entwicklung beteiligen.
Hans-georg Lehnard schrieb: > Man verdrahtet 200 I/O quer durchs Haus in einen Schaltschrank und macht > sich dann über ein Bussystem innerhalb des Schaltschrankes Gedanken .. Was würdest du denn vorschlagen? Alles auf eine Platine? Sobald ich mehrere Platinen/Module habe, muss ich die irgendwie untereinander verbinden. Bus durch's Haus scheidet zumindest aus organisatorischen Gründen aus. Mal 'ne blöde Frage am Rande: Ich überlege mir gerade eine Lösung mit CAN (weil eigentlich bietet der genau das, was ich brauche). Die Module kriegen dann alle einen ATmega162 + MCP2515 soweit klar. Der Master soll jetzt aber den CAN-Bus und Ethernet bedienen. Muss ich jetzt z.B. einen AT90CAN128 nehmen und diesen mit SPI an einen ENC28J60 anbinden, oder kann ich auch zwei Controller (CAN und Ethernet) per SPI an einen normalen ATmega16 anbinden? Danke und schöne Grüße, Kai
Tubie schrieb: > .... Was ist wenn ein Slave Gerät länger für die Antwort braucht > (Warum auch immer?) und der Master schon wieder sendet dannm brauchts > noch eine Kollisionsüberwachung das kann nicht passieren, der Master ist der Master und ist derjenige der wartet. Eine solche Wartezeit tritt übrigens immer auf, der Slave könnte ja ausgefallen oder abgeschaltet sein. > Theoretisch wäre auch eine Lösung denkbar bei der der Master nur sendet > und der Slave nur empfängt. Niemals. Der Experimentator vor dem Bildschirm würde ja bis in alle Ewigkeit nicht erfahren, dass der Slave kaputt ist. Das wäre etwa so sicher wie bei einem Priester, der weiss ja auch nie, ob seine Gebete erhört werden. Technik funktioniert anders. Gruss Reinhard
Hallo Reinhard, hast ja recht. Ich würde es ja auch nur mit Rückantwort machen. Aber sei doch mal ehrlich. Wenn man sich die ganze Kette mal ansieht: Sender <--> Empfänger -> µC -> Transistor -> Relais -> 20m Kabel -> Glühbirne Es sind noch viel mehr Glieder in der Kette, die ausfallen können als die Serielle Verbindung. Bei einer so einfachen Anwendung wie Hausautomation, kann man das doch sehen, wenn eine Birne nicht angeht oder ein Rollo nicht zugeht. Wenn dann müsste man Nägel mit Köpfen machen und den Relais Ausgang an der 230V Seite abgreifen und als Rückantwort geben "Relais hat erfolgreich eingeschaltet" Gruß, Tubie
Tubie schrieb: > ... Bei einer so einfachen Anwendung wie > Hausautomation, kann man das doch sehen, wenn eine Birne nicht angeht > oder ein Rollo nicht zugeht. Hallo Tubie, klar, wenn man das sieht, hat man ja die perfekte Rückmeldung; die Fernbedienung eines Fernsehers geht ja auch nur in eine Richtung. Gruss Reinhard
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.