Eindrahtbus - wie angehen ?

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).

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

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