Ahoy. Eines vorneweg: Die Forensuche habe ich zur Genüge bemüht, bin aus den unterschiedlichen Ergebnissen jedoch nicht ausreichend schlau geworden, also muss ich nochmal spezifisch um Hilfe bitten. Folgende Situation: - mehrere LED Driver [jeweils mit eigenem Controller, ich dachte an einen ATMega8(8)] sollen in einem Bus verbunden werden, dadurch werden drei PWMs auf dem µC belegt - es ist neben Vcc und GND nur ein Signalkabel vorhanden - eine Master / Slave Topologie soll implementiert werden, in welcher die LED Module die Slaves darstellen, ein separater Master kommt noch dazu Am einfachsten wäre wohl die Implementierung einer einfachen UART, in den Nutzdaten vom Master würde als Präfix die ID des angesprochenen Slaves mitgesendet - fertig. Hier fehlt aber der Rückkanal. Alternativ ginge auch 1-wire, master auf einem AVR dafür schein kein Thema [AVR318], slave hingegen schon eher. Wie oben bereits angedeutet, wären auf dem zukünftigen Slave bereits 3 PWMs zu realisieren - ich fürchte nun, dass es bei der (Software-) Implementierung des 1-wire slave auf dem µC arg eng (Timer, Interrupts ?) werden würde, oder ? Mal ganz naiv gefragt: Gibt es 1-wire slave Bausteine, die man dem µC vorschalten könnte ? Hab bei einer schnellen Suche nichts entsprechendes gefunden [oder nicht als solches erkannt]. Hat jemand ein paar gute Vorschläge dazu ?
Martin Schröer schrieb: > Am einfachsten wäre wohl die Implementierung einer einfachen UART, in > den Nutzdaten vom Master würde als Präfix die ID des angesprochenen > Slaves mitgesendet - fertig. > Hier fehlt aber der Rückkanal. Darf ich fragen, wozu du den brauchst? > Wie oben bereits angedeutet, wären auf dem zukünftigen Slave bereits 3 > PWMs zu realisieren - ich fürchte nun, dass es bei der (Software-) > Implementierung des 1-wire slave auf dem µC arg eng (Timer, Interrupts > ?) werden würde, oder ? 3 PWM macht dir ein Mega8 mit links in Hardware als 8 Bit PWM. Wenns größere Bittiefen sein sollen, dann auch schon mal in Software, wobei das Hauptproblem nicht die Rechenzeit sondern die generelle Taktrate des µC ist. > Gibt es 1-wire slave Bausteine, die man dem µC vorschalten könnte ? Jetzt machst du es aber kompliziert. > Hat jemand ein paar gute Vorschläge dazu ? Ich würd bei UART bleiben und mir überlegen, ob ich überhaupt einen Rückkanal brauche. Momentan seh ich noch nicht, welchen Zweck der erfüllen könnte. Was will ein Master von einer LED wissen, was er nicht sowieso schon weiß, weil er das Kommando dazu abgesetzt hat.
1-Wire ist das falsche Protokoll, da gibt es nur den proprietären Maxim-Kram. Der ist nicht schlecht, aber etwa so geschlossen wie die Apple-Welt. Wenn dir die Datenrate reicht, könnte I2C für dich passend sein, das ist für solche Anwendungen erfunden worden und sollte von deinem Atmel-µC nativ unterstützt werden. Max
Ich schlage einen asynchronen I2C vor (I2C ohne SCL). Das ganze läuft dann über die Hardware-UART des Controllers. Benötigst pro Baustein nur einen zusätzlichen Transistor und einen Widerstand.
Hallo Karl-Heinz. Danke für Deine Antwort. Für die reine LED Steuerung brauche ich natürlich keinen Rückkanal, meine Frage war mehr aus der Neugier heraus, denn die Situation mit dem einzelnen verfügbaren Signalkabel kommt in dem Szenario häufiger vor. Wenn dann mal anstelle von einer LED an dem zu erstellenden Bus z.B. ein Sensor ausgelesen werden soll, wird's interessanter. Karl Heinz Buchegger schrieb: > 3 PWM macht dir ein Mega8 mit links in Hardware als 8 Bit PWM. Meinst Du, dass der dann auch "nebenher" den soft 1-wire slave (z.B. den hier: Beitrag "1-Wire Slave auf AVR") packt ?
@Max, be stucki: Hmm, wenn das mit nur einer Signalleitung ginge ... ist auf jeden Fall einen Blick wert.
Martin Schröer schrieb: > Hmm, wenn das mit nur einer Signalleitung ginge ... ist auf jeden Fall > einen Blick wert. Geht schon. Ist ja nichts anderes als eine normale UART, einfach noch mit einem Transistor dazwischen, damit es keine Kurzschlüsse geben kann. Die Adressierung müsstest du aber von Hand stricken.
Adressierung und physikal. Aufbau über UART: Wenn es eine UART sein soll, dann konfigurier diese doch auf den 9-Bit Modus. Jeder Teilnehmer erhält eine Adresse zw. 0..255 und der Master adressiert die Slaves dadurch, dass der die Adresse+9te-Bit setzt. Die nachfolgenden Daten sind dann für den jeweils angesprochenen slave. Das kann man auf einem Draht direkt realisieren, wenn der UART-Ausgang des Masters auf die UART-Eingänge der Slaves geht. Wenn du jedoch auch eine Rückmeldung von den Slaves am Master einlesesen möchtest, braucht es ein wenig mehr. Am einfachsten stell ich mir da am TX-Ausgang der µCs einen R+pnp-Transistor vor, der widerum eine Leitung mit PullUp gegen Masse zieht. Physikalisch wäre das eine LIN auf Sparflamme im 9Bit-mode. Hohe Datenraten gehen da aber nicht (19,2k auf etwa 10m, ggf. ausprobieren).
Schlau dich mal auf unter dem Stichwort Half-Duplex. Darauf basiert z.B. LIN (19,2k), K-Line(38,4k) (jeweils 1-Leitung) und RS485 (12Mbps, symmetrisch, daher 2-Leitungen). Dazu gibt es jede Menge Treiber-IC's. Ganz simpel geht es, wie meine Vorredner bereits geschrieben haben, mit einem Transistor, ein paar Widerständen und passender Software.
be stucki schrieb: > Ich schlage einen asynchronen I2C vor (I2C ohne SCL). Das ganze läuft > dann über die Hardware-UART des Controllers. Benötigst pro Baustein nur > einen zusätzlichen Transistor und einen Widerstand. Eine Diode statt eines Transistors genügt auch schon.
Max G. schrieb: > 1-Wire ist das falsche Protokoll, da gibt es nur den proprietären > Maxim-Kram. Der ist nicht schlecht, aber etwa so geschlossen wie die > Apple-Welt. Man muß ja nicht die Maxim-Variante benutzen. Oft will man das nicht einmal, weil sie für sehr viele Anwendungen schlicht unnötig komplex ist. Wenn man alle Kommunikationspartner ohnehin selber programmiert, dann spricht nichts dagegen, eine (gegenüber Maxim erheblich vereinfachte) eigene Variante zu implementieren. Am besten eine, die nur genau das kann, was in der konkreten Anwendung tatsächlich nötig ist. Das spart tendenziell Code und Buszeit.
Martin Schröer schrieb: > Am einfachsten wäre wohl die Implementierung einer einfachen UART, in > den Nutzdaten vom Master würde als Präfix die ID des angesprochenen > Slaves mitgesendet - fertig. > Hier fehlt aber der Rückkanal. Kannst ja auch den Hin- und Rückkanal auf eine Leitung legen. Das sollte funktionieren, wenn die Slaves nicht asynchron von sich aus zu senden beginnen, sondern nur, wenn sie vom Master aufgefordert werden. Schaltung habe ich dafür nicht, aber mit ein paar Dioden und Widerständen sollte sich da bestimmt was basteln lassen.
Alexander, das klingt interessant. So in der Art von Round Robin ... das merke ich mir mal. Danke für den Fingerzeig.
Neben dem asynchronen I2C ohne SCL könntest Du Dir auch den 124-Bus anschauen: Beitrag "mehrere MC seriell über Datenbus verbinden (1Draht)" >> Hier fehlt aber der Rückkanal. > > Darf ich fragen, wozu du den brauchst? Ein Grund der mir einfällt wäre das Auslesen von Temperatursensoren an den LEDs, bzw. ein Feedback wenn der µC "vor Ort" die PWM wg. zu hoher Temp. der LEDs gedrosselt hat.
c-hater schrieb: > Max G. schrieb: > >> 1-Wire ist das falsche Protokoll, da gibt es nur den proprietären >> Maxim-Kram. Der ist nicht schlecht, aber etwa so geschlossen wie die >> Apple-Welt. > > Man muß ja nicht die Maxim-Variante benutzen. Oft will man das nicht > einmal, weil sie für sehr viele Anwendungen schlicht unnötig komplex > ist. OK, nur hat das Ergebnis mit 1-Wire nicht mehr viel gemein. Das ist aber eher ein Vorteil als ein Nachteil. Nach nochmaligem Grübeln über das Problem würde ich auf normalen UART gehen und diesen asynchron betreiben. Im Normalfall sendet nur der Master und die anderen hören zu. Wenn der Master einen Slave zum Senden auffordert, konfiguriert der Master danach seinen Pin auf Eingang und der entsprechende Slave auf Ausgang. Nach Empfang des Pakets vom Slave dann alles wieder zurück auf Los. Das wird nicht rasend schnell, aber sollte sich ohne größere Schmerzen implementieren lassen. Ich würde noch Längswiderstände an jedem Slave-Pin vorsehen, damit ggf. gleichzeitiges Senden zweier Teilnehmer nicht zu Schäden führt. Max
Bei RS485 hast du 2 symetrische Leitungen, auf denen du auch mittels Master Slave topolgie bidirektional komminizieren kannst. Dafür brauchst du aber einen RS485 treiber IC. z.B. LTC485. Du könntest für deinen Fall einfach eine Leitung weglassen, dann hättest du mittels UART einen 1Wire Bus. Ist dann einfach störanfällig.
Nimm doch gleich LIN. Tiny167 plus LIN Transceiver (zB ATA6625), und das alles auf 12V-Pegel. Damit hast Du dann auch keine Probleme mit Spannungsabfällen. Warum basteln, wenn es millionenfach erprobte Lösungen gibt? fchk
Hi, Hier gibt es doch irgendwo den 1-2-4 Bus. Vielleicht wäre der geeignet. Gruß Martin
Oder Lanc (von Sony). ist auch ein 1wire-Bus, der halbduplex funktioniert, allerdings derart synchron, dass der Master den Takt vorgibt und der Slave die Leitung auf Masse zieht.
Martin K. schrieb: > Hier gibt es doch irgendwo den 1-2-4 Bus. Genau! Peter Dannegger 1 2 4 in der Codesammlung suchen. Ein Draht + Masse, 1 Master, viele Slaves.
Frank K. schrieb: > > Warum basteln, wenn es millionenfach erprobte Lösungen gibt? > > fchk Und hier liegt der Hase im Pfeffer, denn welche der 10^6 verfügbaren Lösung ist - am attraktivsten ? - am leichtesten zu implementieren ? - kommt mit dem geringsten (Bauteile-) Aufwand aus ? - für das Szenario am ehesten geeignet ? - gegenüber exotischen Wünschen am robustesten ? Wie Du siehst, die Welt ist nicht schwarz oder weiss, sie ist oftmals sehr, sehr grau ... was gut ist ;) --- Danke auf jeden Fall für die vielen Vorschläge. Da waren einige attraktive Möglichkeiten bei ... was mich nun vor ein neues Problem stellt: Welche wird zuerst ausprobiert ? ;)
Martin Schröer schrieb: > Frank K. schrieb: >> >> Warum basteln, wenn es millionenfach erprobte Lösungen gibt? >> >> fchk > > Und hier liegt der Hase im Pfeffer, denn welche der 10^6 verfügbaren > Lösung ist ok, ich habe mich missverständlich ausgedrückt. Gemeint war: Warum basteln, wenn es Lösungen gibt, die millionenfach erprobt sind? Bei Industriebussen wie CAN und LIN steckt jede Menge Know-How und Entwicklungsarbeit drin. Die darfst Du ruhig nutzen. fchk
Mach' ich auch glatt. Oder schau mir die vielen Alternativen an. Ich hab keine kritische Deadline. Ich muss keine Industriestandards erfüllen. Ich darf experimentieren, Spass dran haben und aus Fehlschlägen lernen. Ich bin bloss ein Bastler. Und froh drüber. :D
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.