Gibt es einen passenden BUS zur steuerung vieler Clients über mehrere Meter?

[Marcel B. (the_s616)]

Guten Abend Community

Da dies mein erster Beitrag hier ist,
hoffe ich, dass ich hier im richtigen Unterforum bin.

Nun ein mal zum konkreten Projekt:
Ich möchte mir eine Art Hue selbst bauen,
hierfür möchte ich mir LED Module selbst bauen,
die über einen BUS angesprochen werden und entsprechend LEDs dimmen.
Hier bei stoße ich jedoch auf ein paar Probleme und Fragen,
die ich aufgrund mangelnder Erfahrung nicht so leicht beheben oder 
beantworten kann.

Da ich mich mit der PWM Steuerung nicht so auskenne,
würde ich die LEDs via µCU + DAC + Mosfet dimmen,
doch stelle ich mir hier die Frage, ob eine PWM Dimmung nicht 
effizienter  einfacher  günstiger ist.

Mein Hauptproblem stellt jedoch derzeit die Suche nach einem geeignten 
BUS dar.
Bis auf I2C habe ich noch nicht wirklich mit BUS Systemen gearbeitet, 
doch I2C reicht hier bei weitem nicht aus.
Als Anforderungen an den BUS habe ich folgende:
Leitungslänge bis ca. 25 Meter (ggf. eine Aufteilung direkt am Master)
Slavezahl bis zu 250, in ersten Tests jedoch 11.
Nutzdaten gibt es 10 Byte pro Slave und Befehl.
Da ich gerne bis zu 20 Hz bei der Ansteuerung erreichen würde,
kommen bei angenommenen 250 Slaves bis zu 50kByte/s an Nutzdaten 
zusammen.
Als letztes würde ich gerne die Möglichkeit haben,
Slaves Hotplug fähig einzubinden und via Knopfdruck am entsprechenden 
Slave,
diesem eine im BUS einzigartige Adresse zu zuweisen.
Gibt es diese letzte Möglichkeit überhaupt?
Schließlich muss der Master ja auf einen noch nicht registrierten Slave 
reagieren
und diesem dann seine neue gültige Adresse übermitteln.

Meine letzte Frage zum BUS ist dann noch, ob ein Slave auch auf mehrere 
Adressen hören kann,
um mehrere Slaves zu gruppieren und somit die Datenlast auf dem BUS zu 
reduzieren.

Die Programmierung an sich traue ich mir zu,
doch fehlen mir Kenntnisse über mögliche zu verwendende Komponenten, die 
das ganze erschweren.


Ich hoffe, dass ihr mir helfen könnt und bedanke mich schon mal im 
Voraus.

Mit freundlichen Grüßen
Marcel

[Dergute W. (derguteweka)]

Moin,

Ethernet, DHCP, Multicast?

Gruss

[Rcc (Gast)]

Das mit dem Hotplug ist erstmal größtenteils eine Frage des Protokolls 
das man auf dem Bus fahren will...
Selbst mit SPI sollte sich das alles realisieren lassen wenn man das 
Übertragungsprotokoll intelligent genug gestaltet und die Registrierung 
der Slaves über die applikation macht.

[Falk B. (falk)]

@ The Supercomputer (the_s616)

>Ich möchte mir eine Art Hue selbst bauen,

Ein was?

>hierfür möchte ich mir LED Module selbst bauen,
>die über einen BUS angesprochen werden und entsprechend LEDs dimmen.

DMX512

>Da ich mich mit der PWM Steuerung nicht so auskenne,

Das kann man ändern. PWM ist kein Hexenwerk.

>würde ich die LEDs via µCU + DAC + Mosfet dimmen,

Machbar, aber eher unüblich.

>doch stelle ich mir hier die Frage, ob eine PWM Dimmung nicht
>effizienter  einfacher  günstiger ist.

Wahrscheinlich.

>Leitungslänge bis ca. 25 Meter (ggf. eine Aufteilung direkt am Master)
>Slavezahl bis zu 250, in ersten Tests jedoch 11.

DM512.

>Nutzdaten gibt es 10 Byte pro Slave und Befehl.

Das geht damit nicht, DMX512 hat bis zu 512 Kanäle a 8 Bit.

>Da ich gerne bis zu 20 Hz bei der Ansteuerung erreichen würde,
>kommen bei angenommenen 250 Slaves bis zu 50kByte/s an Nutzdaten
>zusammen.

Ggf. Artnet, das ist eine Ethernetvariante davon. Vorteil. Es gibt auch 
massenhaft Software dafür.

>Schließlich muss der Master ja auf einen noch nicht registrierten Slave
>reagieren
>und diesem dann seine neue gültige Adresse übermitteln.

Nicht zwingend.

>Meine letzte Frage zum BUS ist dann noch, ob ein Slave auch auf mehrere
>Adressen hören kann,
>um mehrere Slaves zu gruppieren und somit die Datenlast auf dem BUS zu
>reduzieren.

Du machst es für den Anfang zu kompliziert.

[Wolfgang (Gast)]

The S. schrieb:
> Ich möchte mir eine Art Hue selbst bauen,
> hierfür möchte ich mir LED Module selbst bauen,
> die über einen BUS angesprochen werden und entsprechend LEDs dimmen.

Was für LEDs hast du dir dafür vorgestellt.

Die WS2812 mit integrierten Controller für ihren seriellen Bus wurden 
doch schon erfunden.

[Stefan (Gast)]

Der CAN-Bus dürfte für dich auch gut passen. Es gibt genügend Controller 
mit CAn und dir wird dort auch einiges schon abgenommen.

[Purzel H. (hacky)]

Als Daisy-Chain : RS485. Alles kein Problem. Auch 50Hz sind kein 
Problem. An jedem Knoten einen AVR der die Umsetzung nach PWM macht. 
Sinnvollerweise schleift man den pwm clock durch, fuer synchronen PWM, 
sonst gibt es interferenz effekte.

[grundschüler (Gast)]

idealer Anwendugsfall für one-wire-bus.

[Christopher J. (christopher_j23)]

Falk B. schrieb:
>> Nutzdaten gibt es 10 Byte pro Slave und Befehl.
>
> Das geht damit nicht, DMX512 hat bis zu 512 Kanäle a 8 Bit.

Kann man denn nicht jedem Gerät zwei Slave-Adressen geben und dann damit 
256 Kanäle à 16 Bit machen?

[Falk B. (falk)]

@Christopher Johnson (christopher_j23)

>> Nutzdaten gibt es 10 Byte pro Slave und Befehl.
>
> Das geht damit nicht, DMX512 hat bis zu 512 Kanäle a 8 Bit.

>Kann man denn nicht jedem Gerät zwei Slave-Adressen geben und dann damit
>256 Kanäle à 16 Bit machen?

Bei DMX512 wird den Empfängern eine Basisadresse zugewiesen und sie 
nutzen dann soviele Kanäle wie nötig. Z.B. Basisadresse 123 mit 5 
Kanälen nutzt dann Kanal 123-127.

[Falk B. (falk)]

@grundschüler (Gast)

>idealer Anwendugsfall für one-wire-bus.

Ist heute Ironie-Tag?

[Reiner_Gast (Gast)]

Zwölf M. schrieb:
> Als Daisy-Chain : RS485. Alles kein Problem. Auch 50Hz sind kein
> Problem. An jedem Knoten einen AVR der die Umsetzung nach PWM macht.
> Sinnvollerweise schleift man den pwm clock durch, fuer synchronen PWM,
> sonst gibt es interferenz effekte.

Naja, so einfach ist es mit dem RS485 nun auch wieder nicht.

Wenn die Transceiver den Bus mit 1 Unit Load belasten, ist nach 32 
Clients Schluss. Es gibt auch noch Transceiver, die mit nur 1/8 Unit 
Load arbeiten, und damit theoretisch 256 Geräte erlauben.

Und bei so vielen Geräten am Bus sind die Pull-Widerstände an den 
Datenleitungen sehr genau zu wählen, damit die 250 Clients erreicht 
werden können.

[Decius (Gast)]

SPI und I2C sind vom Ursprung her Busse die für die Verbindung von IC's 
auf der Leiterplatte gedacht sind. Ein Kommunikationsprotokoll muss man 
sich selbst überlegen. Die Namen SPI und I2C stehen nur für die 
Hardware.

Der Name RS485 steht eigentlich nur für den verwendeten Transceiver, den 
man an den UART des uC anschliesst. Also auch hier muss man sich selbst 
ein Kommunikationsprotokoll überlegen und implementieren. Bei einem Buss 
darf man dabei das Thema Busarbitrierung, also das Management wann wer 
lesend oder schreibend auf den bus zugreifen darf, nicht vergessen.

CAN Bus bezeichnet nun sowohl die Hardware als auch das 
Kommunikationsprotokoll. Das Kommunikationsprotokoll ist im CAN 
Controller realisiert, der Teil des Mikrocontrollers sein kann, und 
somit recht preiswert ist. Als BUS-Treiber schliesst man an diesen 
CAN-Controller noch einen CAN-Transceiver an. Befindet sich der 
Teilnehmer am Ende des Busses muss dieser mit Abschlusswiderständen 
versehen werden, um Reflektionen auf den Bus zu vermeiden.

Das im Controller vorhandene Kommunikationsprotokoll regelt auch die 
Busarbitrierung, und gibt das Format der Messages vor. Ein Gruppierung 
könnte man elegant durch eine Anpassung des Master/Slave Predefined 
Connection Set erreichen. Da muss man den CAN-Bus aber gut kennen und 
verstehen. Einfacher ist es sicher Du würdest Broadcast Messages senden, 
die erstmal jeder Slave empfangen kann. In der Message schickst du neben 
den anderen Daten eine Gruppenkennung mit. Der jeweilige Slave überprüft 
diese Kennung, ist es seine Gruppenkennung, verarbeitet er die Message. 
Ist sie es nicht, verwirft der Slave die Message.

Grundsätzlich denke ich, ist es eine gute Idee, wenn man Dinge so 
benutzt wie es ursprünglich gedacht war. Jedenfalls wenn Du auf 
möglichst wenige Probleme stossen möchtest.

RS485 oder CAN sind sicher möglich. Aufgrund des fehlenden 
Kommunikationsprotokoll habe ich aber RS485-Busse in der Praxis bis 
jetzt noch nicht gesehen. Um die Implementierung des 
Kommunikationsprotokolleinfach zu halten kenne ich RS485, nur als 
Direktverbindung zweier Teilnehmer. Ok, in diesem Fall müsste es RS422 
heissen. Denn RS422 steht für Direktverbindungen, und RS485 für 
Bus-Verbindungen. Elektrisch sollten aber beide identisch sein.

Zusammengefasst wäre also CAN meine Wahl für diese Aufgabe.

[Decius (Gast)]

In form des UART gibt es natürlich auch bei RS485 ein einfaches 
Kommunikationsprotokoll. Aber die Bus-Arbitirierung fehlt.

[Decius (Gast)]

Nur noch als Tip zur weiteren Information. Controller, Transceiver, 
Protokolle was sich dahinter "verbirgt" ist das sogenannte

OSI-Schichtenmodell. ;-)

[Lutz H. (luhe)]

Stefan schrieb:
> Der CAN-Bus dürfte für dich auch gut passen. Es gibt genügend Controller
> mit CAn und dir wird dort auch einiges schon abgenommen.

Gibt es für den CAN  günstige Karten für den PC? Karten die ich gefunden 
habe liegen bei 500 bis 700 Euro.

[Falk B. (falk)]

@ Lutz H. (luhe)

>Gibt es für den CAN  günstige Karten für den PC? Karten die ich gefunden
>habe liegen bei 500 bis 700 Euro.

Es gibt CAN-USB Umsetzer für ~100 Euro.

http://www.can232.com/

[Peter D. (peda)]

Decius schrieb:
> Als BUS-Treiber schliesst man an diesen
> CAN-Controller noch einen CAN-Transceiver an.

Gibbet aber auch onchip:
LPC11C12FBD48/301

[Dr. Sommer (Gast)]

Falk B. schrieb:
> Es gibt CAN-USB Umsetzer für ~100 Euro.
>
> http://www.can232.com/

Der konvertiert ja erst auf RS232, ob damit die maximale CAN-Buslast 
erreichbar ist? Bei diesem Projekt wird man da vermutlich in die Nähe 
kommen. Gibt es eigentlich kein vernünftiges DIY/OpenSource 
CAN-USB-Adapter Projekt welches USB direkt umsetzt und auch volle 
Buslast abkann? Kann doch eigentlich nicht so schwierig sein...

[Volker S. (vloki)]

Dr. Sommer schrieb:
> Gibt es eigentlich kein vernünftiges DIY/OpenSource
> CAN-USB-Adapter Projekt...

Wollte ich auch schon mal machen. Hatte dann aber etwas zu wenig Zeit 
mich in eine neue Controllerfamielie einzuarbeiten, die USB und CAN 
integriert hat. Von den PIC18, mit denen ich mich im Allgemeinen 
beschäftige bietet das leider keiner.

Lösungen mit zwei Controllern (USB-RS232-CAN, USB-RS232-BT) waren mir 
dann zu umständlich, bzw. hatte ich schon (BT). DIY USB Lösungen mit 
zwei Controllern gibt es auch. z.B. http://www.fischl.de/usbtin/

[Falk B. (falk)]

@Dr. Sommer (Gast)

>> http://www.can232.com/

>Der konvertiert ja erst auf RS232,

Nein, die USB-VErsion arbeitet mit einem virtuellen UART.

>ob damit die maximale CAN-Buslast
>erreichbar ist?

Nicht ganz. Für die meisten Sachen reicht es.

"CANUSB uses FTDI USB chip FT245RL and we have developed our own DLL 
which in turn interfaces with the D2XX DLL from FTDI. This threaded DLL 
includes Open, Close, Read, Write & Status functions and will make it 
quick and easy for customers to make their own applications in a snap 
without understanding on how to parse commands and get into how the D2XX 
driver work. Tests with VB6 using this DLL shows that the CANUSB is fast 
and can receive 5000+ frames per second without loosing any frames. 
However due to the Windows USB driver 1mS time slot (gitter) you cannot 
send more than about 1000 messages per second, since the CANUSB needs to 
report back (this apply to sending & receiving, i.e. ping pong 
messages)."


> Bei diesem Projekt wird man da vermutlich in die Nähe
>kommen. Gibt es eigentlich kein vernünftiges DIY/OpenSource
>CAN-USB-Adapter Projekt welches USB direkt umsetzt und auch volle
>Buslast abkann? Kann doch eigentlich nicht so schwierig sein...

Mach mal ;-)

[Volker K. (tobel)]

Wolfgang schrieb:
> The S. schrieb:
>> Ich möchte mir eine Art Hue selbst bauen,
>> hierfür möchte ich mir LED Module selbst bauen,
>> die über einen BUS angesprochen werden und entsprechend LEDs dimmen.
>
> Was für LEDs hast du dir dafür vorgestellt.
>
> Die WS2812 mit integrierten Controller für ihren seriellen Bus wurden
> doch schon erfunden.

@Wolfgang: Volle Zustimmung, das sollte die einfachste Lösung sein.

[Dr. Sommer (Gast)]

Falk B. schrieb:
> Nein, die USB-VErsion arbeitet mit einem virtuellen UART.

Falk B. schrieb:
> "CANUSB uses FTDI USB chip FT245RL
Ah, das ist wohl USB<->Parallel. Auch wenn's geht finde ich so eine 
Lösung schon irgendwie hässlich.

Falk B. schrieb:
> Mach mal ;-)
Bin gerade noch an einem anderen Projekt dran ;-) Aber spannend wäre 
es...

[Dr. Sommer (Gast)]

PS: Scheints doch zu geben:
https://github.com/linklayer/candleLight_fw
https://github.com/fabiobaltieri/open-usb-can

[Purzel H. (hacky)]

Daisy chain bedeutet an jedem Knoten rein und raus. Nicht aufstecken, 
nicht parallel am Bus. Jeder Knoten haette 2 Uart, eins fuer ein, das 
andere fuer raus. Oder wenn man sparen wollte, das UART wird 
umgeschaltet. Aber 2 Transceiver .

[Falk B. (falk)]

@Dr. Sommer (Gast)

>Ah, das ist wohl USB<->Parallel. Auch wenn's geht finde ich so eine
>Lösung schon irgendwie hässlich.

Das sehe ich genau anders herum 8-0. Es ist eine clevere Lösung, welche 
für 99% aller Anwender schnell genug ist und so weit wie möglich auf 
Standardlösungen in Hard- und Software zugreift. Dazu mit 100 Euro noch 
recht preiswert. Ein Mega-Teil ala CANalyzer etc. ist um Größenordnungen 
teurer und für eine ganz andere Zielgruppe.

[Dr. Sommer (Gast)]

Na, alles in einem Mikrocontroller zu machen ist noch günstiger und gut 
möglich, wie an den genannten Projekten sichtbar ist. Die Nutzung von 
dedizierten USB<->Seriell/Parallel-Adaptern wie FT245RL ist für mich 
immer eine Kapitulation vor der Software-Entwicklung - weil das 
Zusammensetzen von Hardware-Komponenten einfacher erscheint als das 
Zusammensetzen von Software-Komponenten (CAN-Treiber + USB-Treiber).

[Falk B. (falk)]

@Dr. Sommer (Gast)

>Na, alles in einem Mikrocontroller zu machen ist noch günstiger und gut
>möglich, wie an den genannten Projekten sichtbar ist.

Wenn gleich vollintegrierte Lösungen oft Vorteile bieten, sind sie nicht 
immer zwingend nötig.

> Die Nutzung von
>dedizierten USB<->Seriell/Parallel-Adaptern wie FT245RL ist für mich
>immer eine Kapitulation vor der Software-Entwicklung - weil das
>Zusammensetzen von Hardware-Komponenten einfacher erscheint als das
>Zusammensetzen von Software-Komponenten (CAN-Treiber + USB-Treiber).

Andere Leute haben andere Stärken und Gewichtungen.

[Volker S. (vloki)]

Dr. Sommer schrieb:
> PS: Scheints doch zu geben:
> ...
> https://github.com/fabiobaltieri/open-usb-can

Dr. Sommer schrieb:
> Na, alles in einem Mikrocontroller zu machen ist noch günstiger und gut
> möglich, wie an den genannten Projekten sichtbar ist.

Zumindest das zwiete Projekt scheint so wie das von Thomas Fischl zu 
sein. Nur eben mit einem ATMega anstelle von einem PIC.

Beide (ATMega, PIC) erledigen nur den USB Teil und sind über SPI mit 
einem CAN Controller verbunden.

[Thomas F. (igel)]

Lutz H. schrieb:

> Gibt es für den CAN  günstige Karten für den PC? Karten die ich gefunden
> habe liegen bei 500 bis 700 Euro.

Bei PEAK ab 200€

https://www.peak-system.com/PCAN-PCI.207.0.html

[Decius (Gast)]

Mit den Adaptern habe ich gute Erfahrungen gemacht. Der CAN-Monitor ist 
inklusive. Allerdings kann ich nicht sagen, ob man die als Privatperson 
irgendwo zu kaufen bekommt.

https://www.peak-system.com/PCAN-USB.199.0.html

Preiswerter gehts hier. Allerdings ist der CAN-Monitor anscheinend nicht 
inclusive. Erfahrungen habe ich aber nicht mit dem Teil.

https://elmicro.com/de/canusb.html

Ansonsten würde ich mal nach CAN Adapter open source suchen.

[Decius (Gast)]

Ahh sorry, Du hattest nach CAN Karten gefragt. Sicher da Du den 
dauerhaften Betrieb und nicht die Entwicklung im Focus hattest. Mit Peak 
machst Du sicher nichts falsch.

[Marcel B. (the_s616)]

Vielen Dank für die große Anzahl und zum Teil sehr ausführlichen 
Antworten.
So schnell habe ich nicht mit so vielen Antworten gerechnet :)
Nun möchte ich euch aber auch nicht länger im Trüben fischen lassen.

Falk B. schrieb:
>>Ich möchte mir eine Art Hue selbst bauen,
>
> Ein was?

Hue ist eine Produktreihe von smarten Lampen von Philips, doch bieten 
diese nicht alles was ich mir wünsche, zudem sind diese recht teuer.

DMX512 ist leider nicht geeignet, zwar lassen sich die Slaves schnell 
gruppieren und einfach steuern, doch ist die Kanalzahl nicht 
ausreichend.
So währen maximal 51 Slaves in einem Universum möglich, sprich ich 
benötige mindestens zwei DMX512 Universen.

Falk B. schrieb:
>>Da ich mich mit der PWM Steuerung nicht so auskenne,
>
> Das kann man ändern. PWM ist kein Hexenwerk.
>
(...)
>
>>doch stelle ich mir hier die Frage, ob eine PWM Dimmung nicht
>>effizienter  einfacher  günstiger ist.
>
> Wahrscheinlich.

Dann werde ich mich hier mit auch etwas genauer befassen.
Doch kommt es bei PWM gerade bei kleinen Werten nicht zu einem 
merklichen Flackern?

Wolfgang schrieb:
> The S. schrieb:
>> Ich möchte mir eine Art Hue selbst bauen,
>> hierfür möchte ich mir LED Module selbst bauen,
>> die über einen BUS angesprochen werden und entsprechend LEDs dimmen.
>
> Was für LEDs hast du dir dafür vorgestellt.
>
> Die WS2812 mit integrierten Controller für ihren seriellen Bus wurden
> doch schon erfunden.

Die WS2812 sind in der Tat nicht uninteressant, jedoch bieten auch diese 
nicht, was ich mir wünsche. Derzeit habe ich mir R+G+B+NW 3-Chip LEDs 
und eine UV (Schwarzlicht) LED heraus gesucht. Um möglichst viel Licht 
und eine gute Kontrolle über dieses zu bekommen.

Daher habe ich die WS2812 wieder verworfen.

Decius schrieb:
> Nur noch als Tip zur weiteren Information. Controller,
> Transceiver,
> Protokolle was sich dahinter "verbirgt" ist das sogenannte
>
> OSI-Schichtenmodell. ;-)

Keine Sorge, ich habe drei Jahre eine Schulische Ausbildung zum ITA 
hinter mir, die Grundlagen sind mir daher durchaus bekannt. ;)
Jedoch fehlt mir viel praktische Erfahrung, die ich durch solche 
Projekte versuche zu bekommen.

CAN ist nach dem, was ich so gefunden habe recht teuer, würde aber in 
der Tat am nächsten heran kommen.

Wenn ich die Beiträge recht verstehe, geht die Tendenz
1. Richtung UART mit RS485 und einem ggf. selbst entwickeltem Protokoll.
2. Dimmung via PWM, jedoch eine zentrale Uhr, damit keine Interferenzen 
entstehen.

Falls ich irgendwie falsch liege, bitte ich um Korrektur meiner 
Aussagen.

Mit freundlichen Grüßen
Marcel

[Decius (Gast)]

Hmm, auch wenn es gegen den Trend ist, hier noch eine Liste mit 
möglichen CAN-Interfaces.

http://www.can-wiki.info/doku.php?id=can_interfaces:main

Wenn es ein privates Projekt ohne EMV Anforderungen unter starken 
Kostendruck ist, ist der UART+RS485 sicher eine Alternative. Privat hast 
Du ja alle Zeit der Welt, Dir ein eigenes Kommunikationsprotokoll zu 
schnitzen. :-)

Allerdings nicht vergessen, die serielle Schnittstelle am Pc ist eine 
RS232, die ist elektrisch gesehen nicht identisch zur RS485.

Zur Gruppierung würde ich auch hier schauen, ob Broadcast Messages 
möglich sind, und dann eine Gruppenkennung mitschicken.

[CC (Gast)]

Es gibt auch einige SBCs mit CAN. Ein BeagleBone(Black) braucht z.B. nur 
einen Transceiver, einen Raspberry könnte man über einen MCP2515 o.ä. 
damit bestücken... Im Dauerbetrieb brauchen die auch weniger Strom als 
ein PC, bieten aber dennoch eine angenehme Umgebung...

[Marcel B. (the_s616)]

Decius schrieb:
> (...)
> Wenn es ein privates Projekt ohne EMV Anforderungen unter starken
> Kostendruck ist, ist der UART+RS485 sicher eine Alternative. Privat hast
> Du ja alle Zeit der Welt, Dir ein eigenes Kommunikationsprotokoll zu
> schnitzen. :-)
>
> Allerdings nicht vergessen, die serielle Schnittstelle am Pc ist eine
> RS232, die ist elektrisch gesehen nicht identisch zur RS485.
>
> Zur Gruppierung würde ich auch hier schauen, ob Broadcast Messages
> möglich sind, und dann eine Gruppenkennung mitschicken.

Ja, es ist ein rein privates Projekt, da sind gerade bei vielen Modulen 
natürlich die Kosten nicht zu vernachlässigen.
Das mit den Broadcast Messages klingt tatsächlich gar nicht schlecht, 
danke dir.

CC schrieb:
> Es gibt auch einige SBCs mit CAN. Ein BeagleBone(Black) braucht
> z.B. nur
> einen Transceiver, einen Raspberry könnte man über einen MCP2515 o.ä.
> damit bestücken... Im Dauerbetrieb brauchen die auch weniger Strom als
> ein PC, bieten aber dennoch eine angenehme Umgebung...

Die Steuerung würde ich über einen Pine Rock64 realisieren, der sowieso 
bald (wenn er ankommt) in Dauerbetrieb geht.

Eine Frage zu möglichen LEDs ist mir da jedoch gerade gekommen.
Ich habe mir zu erst bei leds-and-more die benötigten LEDs heraus 
gesucht, nun habe ich jedoch bei Led1 deutlich günstigere und etwas 
stärkere LEDs gesehen, ist hier die Qualität viel schlechter, oder ist 
leds-and-more einfach total überteuert?

[Wolfgang (Gast)]

Decius schrieb:
> In form des UART gibt es natürlich auch bei RS485 ein einfaches
> Kommunikationsprotokoll. Aber die Bus-Arbitirierung fehlt.

Was willst du beim Steuern von Lampen mit Bus-Arbitrierung? Die 
LED-Module sollen gefälligst zuhören, was der Master ihnen befiehlt - 
ohne Widerworte.

[Volker S. (vloki)]

The S. schrieb:
> Eine Frage zu möglichen LEDs ist mir da jedoch gerade gekommen.
> Ich habe mir zu erst bei leds-and-more die benötigten LEDs heraus
> gesucht, nun habe ich jedoch bei Led1 deutlich günstigere und etwas
> stärkere LEDs gesehen, ist hier die Qualität viel schlechter, oder ist
> leds-and-more einfach total überteuert?

Was für LEDs denn genau?
(die Qualität hängt ja nicht vom Verkäufer ab)

[Mark W. (kram)]

Ich wuerde mit SPI anfangen, und dann, wenn Du die grossen Kabellaengen 
brauchst, einfach isoSPI machen. Der LTC6820 ist Dein Freund. :-)
Ich denke damit laesst sich das Vorhaben gut realisieren.

[Volker S. (vloki)]

Mark W. schrieb:
> Der LTC6820 ist Dein Freund. :-)

Für vermutlich deutlich weniger Geld bekommt man aber auch sicher
einen uC mit integriertem CAN Modul + einen externen Transceiver.

[Mark W. (kram)]

Volker S. schrieb:
> Mark W. schrieb:
>> Der LTC6820 ist Dein Freund. :-)
>
> Für vermutlich deutlich weniger Geld bekommt man aber auch sicher
> einen uC mit integriertem CAN Modul + einen externen Transceiver.

Ja, schon klar. Die billigste Loesung ist es nicht.
Marcel wird schon wissen, was sein Geldbeutel hergibt. :-)

[Peter D. (peda)]

Mark W. schrieb:
> Ich wuerde mit SPI anfangen

... wenn die Leitungslänge 10cm nicht überschreitet. Darüber kann SPI 
schon Probleme machen.
SPI ist mit Abstand der störempfindlichste Bus. Oder man nimmt 
differentielle Treiber+Empfänger für sämtliche Signale.

[Mark W. (kram)]

Peter D. schrieb:
> Mark W. schrieb:
>> Ich wuerde mit SPI anfangen
>
> ... wenn die Leitungslänge 10cm nicht überschreitet. Darüber kann SPI
> schon Probleme machen.
> SPI ist mit Abstand der störempfindlichste Bus. Oder man nimmt
> differentielle Treiber+Empfänger für sämtliche Signale.
Die Datenraten sind ja nicht soo hoch. Aufm Tisch kann man das ja mit 
wenigen Teinehmern anfangen, dann hat man schon mal die Software. Dann 
nimmt man die SPI Bruecke LTC6820 und testet mit den Kabellaengen.

[Dr. Sommer (Gast)]

Peter D. schrieb:
> SPI ist mit Abstand der störempfindlichste Bus.

Nicht I²C, wo positive Pegel und steigende Flanken durch Pullups erzeugt 
werden (statt mit Push-Pull-Stufen wie bei SPI) und somit beliebig 
kaputt gehen - besonders lustig bei Serienwiderständen?

[Marcel B. (the_s616)]

Volker S. schrieb:
> The S. schrieb:
>> Eine Frage zu möglichen LEDs ist mir da jedoch gerade gekommen.
>> Ich habe mir zu erst bei leds-and-more die benötigten LEDs heraus
>> gesucht, nun habe ich jedoch bei Led1 deutlich günstigere und etwas
>> stärkere LEDs gesehen, ist hier die Qualität viel schlechter, oder ist
>> leds-and-more einfach total überteuert?
>
> Was für LEDs denn genau?
> (die Qualität hängt ja nicht vom Verkäufer ab)

Oh stimmt ^^, dass hätte ich natürlich dazu schreiben müssen.
Im konkreten geht es um die PLCC6 LEDs, der jeweiligen Verkäufer.
https://www.led1.de/shop/smd-leds/smd-led-bauform-plcc6/?xoid=nhbfu7rp06uj7cjonr4ca17vm6
gegen diese LEDs
https://www.leds-and-more.de/catalog/5050-bauform-viel-licht-auf-wenig-raum-c-26_143.html?osCsid=bufpq135qghfc5sdgdnupc4sk0
nur bei der UV LED, muss ich bei leds and more auf eine andere Bauform 
zurück greifen, bei LED1 hätte ich alles in einer Bauform.
Oder gibt es noch andere Shops, die Seriös zu einem guten Preis LEDs 
anbieten?

Bei LED1 ist der Hersteller Winger angegeben, zu dem im Netz nicht so 
viel zu finden vermag, beim anderen Shop ist soweit ich gesehen habe 
kein Hersteller angegeben.

Mark W. schrieb:
> Ja, schon klar. Die billigste Loesung ist es nicht.
> Marcel wird schon wissen, was sein Geldbeutel hergibt. :-)

Als Student, ist der tatsächlich nicht so propper gefüllt. ^^
Ich denke über die MAX1483 ICs, werde ich etwas gutes hin bekommen, 
gerne bin ich für weitere Ideen offen.

Ich bedanke mich noch mal für die wirklich gute Hilfe.
Mit freundlichen Grüßen
Marcel

[Peter D. (peda)]

Mark W. schrieb:
> Die Datenraten sind ja nicht soo hoch.

Die ist für die Störsicherheit nicht entscheidend, sondern die 
Grenzfrequenz des Empfängers. Z.B. ein 74HC595 kann bis 30MHz, d.h. 17ns 
kurze Störungen bringen ihn schon aus dem Takt.

CAN hat den großen Vorteil, daß es Störungen selber erkennt und ohne 
jedes Zutun automatisch den Transfer wiederholt. Außerdem wird jedes Bit 
3-mal abgetastet. CAN wurde speziell auf Störsicherheit hin entwickelt.

[Einer K. (Gast)]

Dr. Sommer schrieb:
> Nicht I²C, wo positive Pegel und steigende Flanken durch Pullups erzeugt
> werden (statt mit Push-Pull-Stufen wie bei SPI) und somit beliebig
> kaputt gehen - besonders lustig bei Serienwiderständen?

Nööö...

I2C, in der Regel niedrigere Frequenzen. Meist 100kHz.

SPI oft an die 4MHz.
Da beginnt ganz schnell der Kampf gegen/mit Reflektionen.

Typisch:
Oszi dran, alles ok, Oszi ab, sporadische Fehler.

[Dirk (Gast)]

The S. schrieb:
> gerne bin ich für weitere Ideen offen.
muss alles 'roh' über den BUS gehen?
muss es ein BUS für 'beide' Richtungen sein?
kann ein Slave nicht Aufgaben übernehmen?
Wir haben mal vor ein paar Jahren Experimente mit unterschiedlichen LED 
'Situationen' (sehr dunkel punktförmige f. Sternenhimmel vs. flächige ) 
bzgl. Wahrnehmung von Flackern, Helligkeitsunterschieden probiert und 
sind nach sehr grober Erinnerung auf:
ab 2kHz: kein Flackern/Perlenschnureffekt (ansonsten besonders bei 
kleinen punktförmigen und unterem Helligkeitsbereich)
Dynamik: für indirekte, flächige Beleuchtung reichen wohl 10-12bit; f. 
Sternenhimmel 14-bit nicht ganz
Unterschiede: 8-bit sollten reichen; mit 7-bit haben probierte LUT tw. 
wahrnehmbare 'Sprünge' gehabt (Test: zufälliges +-1 alle 0,1..2 sek)
einige Effekte könnten auch tw. durch die Ansteuerung (wohl zu langsame 
uln2003)verursacht sein, aber 8-bit Werte mit 14-bit LUT im µC können 
den weiteren Umgang vereinfachen.
Ein µC kann u.U. auch Fading übernehmen (auf feste Update Frequenz bsp. 
5/10/20 Hz oder wie eine Glühlampe schnell aufleuchten und langsamer bei 
verringerung regieren)
Gruppenadressen und/oder kombinierte R/G/B Datenpakete sollten kein 
Problem sein, allerdings hängt (bei den probierten Ideen) viel im Status 
der µC was  auch unübersichtlich werden kann ;-)

Beim BUS noch der Gedanke an Leitungslänge und chaotische 
Plug&PrayStruktur: vom Gefühl schadet eine gelegentliche 
Potentialtrennung (Optokoppler/WLan) nicht unbedingt. Vom PC über WLan 
(bsp. Esp266) in die gröbsten Ecken und von da mit einfachst seriell in 
die µC oder weiteren 'Hubs' und die Rückmeldung 'nur' über die Ecke oder 
gar per Hand ...

kurz: der 1-wire BUS könnte etwas zu wenige Ideen gehabt haben, 
ansonsten kann vieles gut funktionieren

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

The S. schrieb:
> würde ich die LEDs via µCU + DAC + Mosfet dimmen,
Das würde ich als eklatanten Designfehler ansehen.

> Da ich mich mit der PWM Steuerung nicht so auskenne,
Ändere das. Du musst es, wenn du so ein Projekt in ernsthaften 
(Beleuchtungs-)Dimensionen durchziehen willst.

The S. schrieb:
> Um möglichst viel Licht und eine gute Kontrolle über dieses zu bekommen.
So eine lineare Ansteuerung mit "DAC + Mosfet" (am besten noch ohne 
Stromregelung, sondern nur über Spannungssteuerung), wie du sie dir 
vorstellst, ist nebenher für sinnvolle Helligkeiten auch noch eine 
brauchbare Heizung.

> Derzeit habe ich mir R+G+B+NW 3-Chip LEDs und eine UV (Schwarzlicht) LED
> heraus gesucht.
Welche denn?

Arduino F. schrieb:
> I2C, in der Regel niedrigere Frequenzen. Meist 100kHz.
> SPI oft an die 4MHz.
> Da beginnt ganz schnell der Kampf gegen/mit Reflektionen.
Die Frequenz der Datenübertragung ist dabei aber nicht das Problem, 
sondern, dass beim SPI die Flanken aktiv getrieben werden und je nach 
Treiber entsprechend steil sein können. Beim I2C ist zumindest die 
steigende Flanke wegen des Pullups nur eine e-Funktion...
Fürs Thema sicher interessant ist deshalb auch der 
Beitrag "Re: Serienwiderstand bei Hochfrequenz"

[grundschüler (Gast)]

Dirk schrieb:
> kurz: der 1-wire BUS könnte etwas zu wenige Ideen gehabt haben,
> ansonsten kann vieles gut funktionieren

Der ist universell und kann alles in nahezu jeder Geschwindigkeit. Funk 
ist z.B. eine quasi-1-Wire-Verbindung, da nur ein pin getoggelt wird.

1-Wire unterscheidet sich auch nicht so sehr von twi oder spi.  Es kommt 
immer darauf an, dass die Geschwindigkeit so gedrosselt wird, dass die 
Signale sicher unterscheidbar sind. ob die Signale einen Spi- oder 
twi-clock oder 1-wire-daten darstellen, ist im Prinzip egal. Die 
Leitungsverbindung muss so gut sein, dass die Datenübertragung sicher 
erfolgen kann. Ob das nun ein clock- oder 1-wire-Daten sind, ist der 
Leitung egal und weiß sie im Zweifel nicht.

Der to kann also von spi bis 1-wire alles nehmen. Wichtiger als die 
Busleitung ist das Protokoll. Das protokoll ist von der Art der 
Übertragung unabhängig. Man kann für 1-Wire, twi, spi, 4bit, 8bit etc. 
im Prinzip das gleiche Protokoll verwenden.

Fragestellung ist eigentlich immer nur, was erfüllt alle Anforderungen 
mit dem wenigsten Aufwand.

[Stefan F. (Gast)]

Bei verkabelten Geräten sollte man bedenken, dass die Kabel, Stecker und 
Verteiler am Ende oft die teuersten Komponenten sind - vor allem bei 
größeren Installationen.

Ethernet Komponenten sind derzeit unschlagbar billig. Da kann es sich 
unter Umständen lohnen, in die Geräte entsprechende Schnittstellen 
einzubauen, auch wenn das technisch unnötig Aufwändig erscheinen mag.

[Karl (Gast)]

Lothar M. schrieb:
> So eine lineare Ansteuerung mit "DAC + Mosfet" (am besten noch ohne
> Stromregelung, sondern nur über Spannungssteuerung), wie du sie dir
> vorstellst, ist nebenher für sinnvolle Helligkeiten auch noch eine
> brauchbare Heizung.

Genau so eine Spannungssteuerung baue ich gerade für mein Arbeitszimmer, 
weil ich keine PWM-gesteuerten LED haben will.

Die "Heizleistung" wird gnadenlos überschätzt. Durch die nichtlineare 
Kennlinie der LED spielt sich das alles im oberen Spannungsbereich ab.

Bei einem 12V-24W LED-Strip mit 2A beträgt die maximale Verlustleistung 
am Transistor 2W, wenn man die Schaltung mit 12.5V versorgt, bei voller 
Helligkeit beträgt sie noch 1W.

Damit kann ich leben. Die Alternative wäre ein Schaltregler, aber der 
müsste dann 95% Effizienz haben, damit sich das lohnt.

[Dergute W. (derguteweka)]

Moin,

Stefan U. schrieb:
> Ethernet Komponenten sind derzeit unschlagbar billig. Da kann es sich
> unter Umständen lohnen, in die Geräte entsprechende Schnittstellen
> einzubauen, auch wenn das technisch unnötig Aufwändig erscheinen mag.

Uii, duennes Eis. Ethernet scheint aus mir unbekannten Gruenden hier im 
Thread nicht ganz so wohlgelitten zu sein ;-)

Gruss
WK

[CC (Gast)]

...dann kann man ja auch einfach Ethernetkabel und -stecker verwenden 
und die Adern für eigene Dinge nutzen. Verdrillt ist es, z.T. geschirmt, 
passives PoE hat ja auch mehr oder weniger seine Standardleitungen...

[Stefan F. (Gast)]

Ich dachte dabei nicht nur an Kabel, sondern auch an Switche.

[Marcel B. (the_s616)]

Dirk schrieb:
> muss alles 'roh' über den BUS gehen?
> muss es ein BUS für 'beide' Richtungen sein?
> kann ein Slave nicht Aufgaben übernehmen?

Alles Roh über den BUS zu realisieren erscheint mir die einfachste 
Möglichkeit, was die Programmierung betrifft bin ich an sich recht fit, 
klar werde ich mich bei dem ein oder anderen speziellen Thema noch mal 
kurz einlesen müssen, doch das sollte keine Probleme bereiten.

Für beide Richtungen würde bei meiner aktueller Planung das einbinden 
der Slaves erleichtern.
Wenn ich den RS485 richtig verstanden habe, ist es hier möglich Full 
Duplex zu arbeiten. Somit kann ich die Slaves fast Hotplug fähig machen.
Man würde einen Slave während des Betriebs einfach anschließen und einen 
Taster an diesem betätigen. Hierdurch würde der Master über die 
Rückleitung eine Signal bekommen, dass jemand auf seine Adresse wartet.
Nun wird allen bereits im BUS befindlichen Slaves signalisiert, dass sie 
die nächste Nachricht ignorieren sollen. Nun bekommt der neue Slave 
seine Adresse im BUS, da er ja weiß, dass er die Adresse angefordert 
hat, ist dies der einzige, der sie verarbeitet.
Nach einer kurzen Rückmeldung zum Master, dass die Adresse richtig 
verstanden wurde, geht der Regelbetrieb im BUS weiter.
(Das wäre jetzt im Groben meine Vorstellung davon, wie ich den Slaves in 
richtiger Reihenfolge ihre jeweilige Adresse zuordnen würde)

Ich wüsste ehrlich gesagt nicht, welche Aufgaben ich einem Slave 
übertragen soll?
Im Prinzip stelle ich mir die Slaves als schlichte µCU gestützte 
multichannel PWM Dimmer vor, die über einen BUS die benötigten Daten 
bekommen.

Dirk schrieb:
> Beim BUS noch der Gedanke an Leitungslänge und chaotische
> Plug&PrayStruktur: vom Gefühl schadet eine gelegentliche
> Potentialtrennung (Optokoppler/WLan) nicht unbedingt. Vom PC über WLan
> (bsp. Esp266) in die gröbsten Ecken und von da mit einfachst seriell in
> die µC oder weiteren 'Hubs' und die Rückmeldung 'nur' über die Ecke oder
> gar per Hand ...

An Potentialtrennung habe ich tatsächlich noch keinen Gedanken 
verschwendet, schaden wird es auf jeden Fall nicht hier für etwas 
Sicherheit zu sorgen.

Für die weiteren Informationen möchte ich dir wirklich danken, nun habe 
ich sehr viel wichtiges, worüber ich mir Gedanken gemacht habe kompakt 
an einer Stelle und kann mich nun weiter orientieren.

Lothar M. schrieb:
>> Derzeit habe ich mir R+G+B+NW 3-Chip LEDs und eine UV (Schwarzlicht)
>> LED
>> heraus gesucht.
> Welche denn?

Konkret geht es hier um quasi das gesamte Sortiment an PLCC6 LEDs dieser 
beiden Händler.
Als konkretes Beispiel hier ein mal die möglichen grünen LEDs ich bin 
mir weiterhin unsicher, ob ich bei LED1 zu wenig für eine Brauchbare 
Qualität zahle, oder ob ich bei leds and more zu viel bezahle, daher 
einmal die konkreten LEDs um die es geht:
https://www.led1.de/shop/smd-leds/smd-led-bauform-plcc6/led-smd-bauform-plcc6-gruen-15lm-wergn15-cm.html
gegen
https://www.leds-and-more.de/catalog/smd-5050-plcc6-led-ultrahell-gruen-2500mcd-120-chip-p-1379.html?osCsid=bufpq135qghfc5sdgdnupc4sk0

Stefan U. schrieb:
> Bei verkabelten Geräten sollte man bedenken, dass die Kabel, Stecker und
> Verteiler am Ende oft die teuersten Komponenten sind - vor allem bei
> größeren Installationen.

Das habe ich auch schon fest gestellt, ich hatte zu erst an eine 9W4 
D-Sub Verbindung gedacht, doch dies ist in diesem Preisbereich fast 
unbezahlbar.
Da ziemlich schnell viele Ampere zusammen kommen fällt PoE so wie 
Ethernet an sich eigentlich raus.
Wobei die von "hause" aus geschirmten Kabel natürlich Vorteile mit sich 
bringen.
Für grob 10 Slaves sollte es tatsächlich reichen, doch wie viel kann ich 
damit wohl überspannen?
2-3 Meter würde ich mal schätzen, dass ist für den Alltag wohl etwas zu 
kurz.

Ich bedanke mich auch weiterhin für die vielen sehr hilfreichen 
Antworten.

Mit freundlichen Grüßen
Marcel

[Dirk (Gast)]

>Wenn ich den RS485 richtig verstanden habe, ist es hier möglich Full
Duplex zu arbeiten.
Ja, allerdings auf Kosten der Nutzdaten und du musst entweder selber ein 
Protokoll basteln wer wann senden darf oder die von Modbus/KNX/..o.ä. 
nutzen.
DMX (RS485 1:n) hat praktisch die durch Aufwand in Kabel etc. begrenzte 
Bandbreite zur Verfügung, während Modbus/KNX/? (RRS485 m:n) jeweils noch 
eigene Daten zur 'Freigabeverhandlung' brauchen.
DMX ist sehr effizient, da du praktisch nur
d_0,d_1,....d_511 überträgst (ähnlich Ws2812,Monitor,....)
mit Adresse:
a_0,d[a_0],a_1,d[a_1],... (bei 10 Byte Daten + 1 Byte Adresse noch nicht 
dramatisch)
aber dann noch:
a_0,d[a_0],a_1,d[a_1],...,f_jmd_anderes?....nein->...a_10,d[a_10]
ist für seltene Rückmeldungen bei begrenzter Bandbreite ungünstig.
Die Variante bsp.
 RS485/DMX für Steuerdaten
+ 1-wire für Rückleitung
dürfte für Plug'n Play (neue Geräte nur alle paar Sekunden) ein deutlich 
besseres Aufwand/Nutzenverhältnis haben.

>Alles Roh über den BUS zu realisieren erscheint mir die einfachste Möglichkeit
das ist es wohl auch (irgendwie/häufig), allerdings kann die Frage wie 
roh genau auch bei BUS Ideen unterschiedliche Wirkungen haben.
DMX ist konzeptionell sehr roh :
das Universum-Speicherabbild des PC wird jeweils komplett roh an alle 
Geräte (ob aktiv oder nicht) übertragen.
Selektive Updates an einzeln adressierte Geräte können die Bandbreite 
reduzieren oder durch den Overhead erhöhen, aber mit dem 'Feature' 
Gruppenadressen zur Busoptimierung ist es mit dem einfachen 
Speicherabbild vorbei.
Praktisch ist DMX erstmal wie eine Grafikkarte die das Bild roh an den 
Monitor sendet aber für "schlichte µCU gestützte
multichannel PWM Dimmer" (linear codiert/statuslos) grob 12-14 bit für 
die Dynamik beim Monitorbild benötigt(der Monitor rechnet mit 
gamma-funktion UND Status Helligkeit/Kontrast praktisch intern auf 
14-bit hoch)
kurz: Vereinfachung kann Bandbreite kosten und kompliziert werden sobald 
man beim vereinfachen nicht gaaaanz vorsichtig ist.

>An Potentialtrennung habe ich tatsächlich noch keinen Gedanken
verschwendet, schaden wird es auf jeden Fall nicht hier für etwas
Sicherheit zu sorgen.
Sicherheit im Sinne von Menschenschutz ist wohl bei den Netzteilen 
relevant. Ich hab mehr an Erfahrungen:
Monitor-Stecker in Grafikkarte v.PC -->Autsch--> käme mein Bastel-µC 
damit klar?
müssen kleine µC die eigentlich nur unter harmloser Kleinspannung stehen 
gleich bei Kontakt mit einer (geerdeter) Lötspitze verunglücken?
oder brummt der PC mit vielen Metern Empfangschleifen wie eine 
Stereoanlage?
gedacht
kurz: mehr als eine Fehlerquelle weniger gemeint, auch wenn "Sicherheit" 
natürlich auch wichtig ist (in Anführungszeichen da es sehr viele Arten 
von Sicherheit gibt und "Sicherheit" aufgrund der unsicheren Bedeutungen 
eigentlich für Ironieanwendungen brauchbar wäre)

>Ich wüsste ehrlich gesagt nicht, welche Aufgaben ich einem Slave
übertragen soll?
das Beispiel Fading hat sich bei den Experimenten zur Wahrnehmung 
ergeben(allerdings nicht 'blind' getestet).
Ein Farbsignal mit 30HZ Update 'fühlte' sich mit Fading/Interpolation 
anders an (ließt sich etwas merkwürdig) Für Ambilight o.ä.kann u.U. 
10fps Analyse reichen wenn der Slave interpoliert.
Mehr als Fading und Gammafunktion im µC ist nach einer privat 
Untersuchung (n=1) sicher nicht die einfachste Möglichkeit. Dynamisch 
Gruppenadressen zuweisen ist eine nette Möglichkeit die am einfachsten 
nicht genutzt wird und auch Sequenzer im µC  sind nett und machen 
kompliziert.
kurz: zu viele Möglichkeiten sind nicht auch nicht zwingend besser...

[Marcel B. (the_s616)]

Dirk schrieb:
> (...)
> Die Variante bsp.
>  RS485/DMX für Steuerdaten
> + 1-wire für Rückleitung
> dürfte für Plug'n Play (neue Geräte nur alle paar Sekunden) ein deutlich
> besseres Aufwand/Nutzenverhältnis haben.

Ich dachte eigentlich, auf Basis dieses Datenblatts:
https://datasheets.maximintegrated.com/en/ds/MAX1482-MAX1483.pdf
Seite 11, Figure 15.
Dass es möglich ist, den "Empfänger" aller Slaves auf ein und den 
"Sender" dieser auf ein weiteres Leitungspaar zu legen. Der Master würde 
entsprechend anders herum angeschlossen werden, somit kann der Master 
auf einem Paar den Slaves ungehindert Steuerdaten übermitteln und eben 
über das andere Paar Informationen wie "Neuer Slave" oder 
"Übertragungsfehler" zurück bekommen.
Aber nach deiner Aussage scheint dieses nicht zu funktionieren.

Mittlerweile habe ich mich noch etwas intensiver mit der Thematik 
befasst, daher möchte ich nun 6 Statt 5 LEDs einsetzen, alles andere 
(abgesehen von einer leicht gestiegenen Datennutzung) bleibt erst mal 
gleich.
Ich denke, dass ich mittlerweile auch ein nutzbares Protokoll erdenken 
konnte.

Hierbei werden insgesamt 14 Byte für einen Slave übertragen, die wie 
folgt aufgeteilt sind:
1.     Byte Adresse (1-250)
2.-13. Byte für jede Farbe einzeln: 10 Bit Farbwert und 6 Bit für ggf.
       Fading. (0-63 ms) Ab 16Hz ist so ein durchgehendes Faden über den
       gesamten Wertebereich möglich.
14.    Byte Kontrollbyte um Übertragungsfehler zu detektieren.

Es würden noch 6 Broadcastadressen für allgemeine Steuerungen zur 
Verfügung stehen.
Hierzu zähle ich etwa die BUS Steuerung zu deaktivieren und aktivieren. 
(ignorieren der Nachrichten).

Die Hardwaregruppierung war eine Idee um mehrere Slaves exakt 
gleichzeitig zu steuern, doch bei einer möglichst hohen angestrebten 
Aktualisierungsfrequenz wird der zeitliche Unterschied bei seriellen 
ansprechen der Slaves wohl nicht auffallen.

Ich bin gestern auch auf einen vielversprechenden Controller für die PWM 
Steuerung gestoßen:
https://www.microchip.com/wwwproducts/en/PIC24F08KL301
Jedoch bin ich mir hier nicht sicher, ob tatsächlich 6 unabhängige PWM 
Channel zur Verfügung stehen, in der Übersichtstabelle von den 16 Bit 
µCUs steht zwar, dass maximal 6 PWM Channel genutzt werden können, doch 
ist auf der direkten Produktseite folgendes zu lesen:
>Capture/Compare/PWM Peripherals 3/3
das verwirrt mich jedoch ein bisschen.

Gibt es ggf. alternativen zu diesem Controller?
Ist dieser Controller überhaupt geeignet?
Soll ich hier überhaupt nach dem entsprechenden Controller fragen, oder 
ist es besser ein neues Thema hierfür zu erstellen?

Mit freundlichen Grüßen
Marcel

[Volker S. (vloki)]

Also der PIC24... kann meiner Meinung nach, laut Data Sheet, 3 
unabhängige Hardware PWM und ist demnach nicht für deine 6 Kanäle 
geeignet.

Wenn du einen uC von Microchip oder Atmel suchst, dann würde ich dir 
MAPS empfehlen http://www.microchip.com/maps/Microcontroller.aspx

[avr (Gast)]

Stefan U. schrieb:
> Ich dachte dabei nicht nur an Kabel, sondern auch an Switche.

Die braucht man bei CAN nicht.

[Peter D. (peda)]

The S. schrieb:
> Wenn ich den RS485 richtig verstanden habe, ist es hier möglich Full
> Duplex zu arbeiten. Somit kann ich die Slaves fast Hotplug fähig machen.
> Man würde einen Slave während des Betriebs einfach anschließen und einen
> Taster an diesem betätigen. Hierdurch würde der Master über die
> Rückleitung eine Signal bekommen, dass jemand auf seine Adresse wartet.

Nö, RS-485 ist Halb-Duplex. Der Master muß immer nur einen Slaven zum 
Senden auffordern und diese dürfen nicht einfach so dazwischen 
quatschen, sonst kommt es zu Datenkämpfen. Viele Transceiver haben 
deshalb eine Übertemperaturabschaltung, aber diese sollte man nicht für 
den regulären Betrieb mißbrauchen.

Das ganze Protokollgeraffel mit der Slaveadressierung, 
Richtungsumschaltung, Fehlererkennung, Timeouts usw., was Du bei RS-485 
mühsam in SW machen mußt, kriegst Du bei CAN für umsonst.
Und dann ist auch Hotplugging kein Problem. Der gerade laufende Transfer 
erkennt Fehler und wiederholt sich automatisch und ein neuer Slave darf 
einfach drauflos quatschen.

[Tobi (Gast)]

Morgen,

Wie wäre es mit LIN? Wenn eine typische Übertragungsrate von 19k2 
ausreicht.
Man muss auch nicht zwingend das LIN-Protokoll anwenden, LIN-UART geht 
auch und man hat maximal drei Leitungen.
Ein LIN-Transceiver wäre der ATA6625.

Gruß Tobi

[Bernd (Gast)]

Ich habe auch zuerst an CAN gedacht.
Da gehen zwar nur max. 127 Teilnehmer pro Bus, aber mir stellt sich eine 
ganz andere Frage: was will der TO denn eigentlich verbinden?
Geht es um eine lange Kette an LEDs oder um im Raum verteilte Module mit 
jeweils mehreren LEDs? Vermutlich werden es mehrere Module mit eigenem 
uController die einzeln oder gemeinsam gesteuert werden können sollen. 
So ala Smart Home.
Die WS2812 oder ähnliche LEDs (RGBW) mit integriertem Controller 
vereinfachen sicherlich den Aufbau der einzelnen Module. Für verteilte 
Module die fest installiert sind kann auch eine CAN verkabelung machbar 
sein.
Das wird dann zwar nicht mehr anfängerfreundlich, aber eine 
interessantere Variante wären autarke Module die zB per ESP8266 im WLAN 
hängen. Ein Modul kann zB die komplette TV-Hintergundbeleuchtung, die 
gesamte Sofaunterleuchtung etc sein. Per WLAN ist dann auch eine 
Steuerung per Smartphone oder Smart Home Zentrale denkbar. Sei es nun 
über eine App oder über URLs.
Dann wird der TO vermutlich auch keine 250 Module mehr benötigen.
Denkbar sind auch vernetzte Controllereinheiten, die dann mehrere LED 
Aufgaben in einer Raumecke erledigen. Also z.B. mehrere LED Ketten 
unabhängig ansteuern können. Das reduziert die Anzahl der Module 
nochmals.
Und einen PC als CAN Master möchte man auch nicht unbedingt haben. Das 
würde dann auch eher ein dediziertes Modul übernehmen, oder aber jedes 
Modul ist eigenständig. Ein CAN Interface für die Entwicklung bräuchte 
man aber wohl trotzdem. Die PEAK Teile sind preiswert und gut.

[Volker S. (vloki)]

Bernd schrieb:
> Ich habe auch zuerst an CAN gedacht.
> Da gehen zwar nur max. 127 Teilnehmer pro Bus,

Kann man im Prinzip nicht so viele Teilnehmer wie mögliche Message IDs 
haben, wenn man sich an kein vorgegebenes Protokoll hält?

[Bernd (Gast)]

Volker S. schrieb:
> Bernd schrieb:
>> Ich habe auch zuerst an CAN gedacht.
>> Da gehen zwar nur max. 127 Teilnehmer pro Bus,
>
> Kann man im Prinzip nicht so viele Teilnehmer wie mögliche Message IDs
> haben, wenn man sich an kein vorgegebenes Protokoll hält?

Stimmt. Ich hatte CANopen im Kopf...
Aber die grundsätzliche Frage bleibt, ob er wirklich 250 Slaves über den 
Bus ansprechen können muss. Jeder Slave braucht dann einen uController, 
einen CAN Transceiver etc. Ich würde versuchen, das so weit wie möglich 
zusammen zu fassen und so etwas wie die schon genannten Module mit 
mehreren Ausgängen für intelligente LED Ketten machen.

[Frank K. (fchk)]

Mal was ganz anderes: Es gibt günstige Bluetooth LE oder IEEE 802.15.4 
(Zigbee, 6LoWPan und andere) Module für ein paar Euro. Auf dem Funkchip 
kann man auch seinen eigenen Code mit laufen lassen, so dass ein extra 
Controller entfällt. In jeder Philips Hue und Osram Lightify Birne ist 
so ein Teil drin.

Die Funktchips enthalten in der Regel einen 8051 oder einen ARM Cortex M 
Prozessorkern.

fchk

[Dirk (Gast)]

>über das andere Paar Informationen wie "Neuer Slave" oder"Übertragungsfehler" 
zurück bekommen.
>Aber nach deiner Aussage scheint dieses nicht zu funktionieren.
Sorry, die Variante hatte ich überhaupt nicht weiter bedacht und 
praktisch als zweiten Bus abgestempelt (knapp daneben,ups)
Solange die Slaves sich absprechen und nicht gleichzeitig 
"Übertragungsfehler"/"Neuer Slave" senden funktioniert das sicher 
problemlos; die Regelung: Slave darf nur antworten wenn er zuvor vom 
Master gnädig auf Paar 1 adressiert wurde ist für "!Übertragungsfehler!" 
ganz praktisch, bei Neueinsteigern ist etwas Vorsicht geboten für den 
Fall, dass sich viele gleichzeitig anmelden bsp. wenn plötzlich gute 
Stromverhältnisse herrschen.
kurz: im wesentlichen hatte ich einen Übertragungsfehler (vielleicht 
eine Abneigung gegen aufwändig verdrillte 4 polige Leitungen oder 
inkl.Stromversorgung 6 Leitungen f. 6 Kanäle oder ...) aber etwas 
"Protokollgeraffel" benötigst du und da ist die Frage welche Information 
ein neuer Slave eigentlich hat oder ob nur 'Ansprechbar' die Information 
ist u.U. sehr interessant.

>einzeln: 10 Bit Farbwert
für 'vernünftige' (im Sinne sichtbarer Bereich) physische Auflösung zu 
wenig (8MHz µC @2KHz schafft 12-bit)und für auf wahrgenommene Werte 
transformierten Bereich zu viel.
wenn du im µC eine (programmiertechnisch) einfache LUT implementierst 
(gamma 2,2; 12-bit)
W[0..255] mit W[x]=(2^12-1)*(x/255)^2,2
dann benötigst du extern lediglich 8-bit (u.U. 7) und  - das ist der 
eigentliche Punkt - der Bereich ist praktisch linear zur Wahrnehmung 
d.h. ein Fading 255-->0 wird als 'gerade' wahrgenommen und du hast bei 
rgb grob PC Farbwerte (der genaue gammawert müsste gemessen werden aber 
2,2 sollte grob passen)

>einzeln: 6 Bit für ggf. Fading. (0-63 ms)
unpraktisch: wenn der PC sendet wann das nächste Datum zu erwarten ist, 
dann betrifft das alle Kanäle; für Effekte mit etwas anderer Definition 
z=1ms*2^(w/c) u.U. nett, aber kompliziert für einfaches Softwaremodell.

>Kontrollbyte
nice to have
kurz: für wahrnehmungsnützliche Daten sollten 9 Byte reichen

>Soll ich hier überhaupt nach dem entsprechenden Controller fragen, oder ist es 
besser ein neues Thema hierfür zu erstellen?
bei der Frage nach dem Bus wäre für der Punkt ob der µC genau für den 
Bus besondere Merkmale benötigt. Mit Software-PWM kann jeder µC, der 6 
Ausgänge an einem Port/ 8MHz /einen Timer und etwas Speicher hat, die 
Aufgabe bewältigen. Vom Prinzip könnten die Antworten ähnlich wie die 
Frage nach dem Bus enden, schließlich hat jeder einen Hammer zu Hause 
der genau zur Frage passt.

[Marcel B. (the_s616)]

Peter D. schrieb:
> Nö, RS-485 ist Halb-Duplex. Der Master muß immer nur einen Slaven zum
> Senden auffordern und diese dürfen nicht einfach so dazwischen
> quatschen, sonst kommt es zu Datenkämpfen. Viele Transceiver haben
> deshalb eine Übertemperaturabschaltung, aber diese sollte man nicht für
> den regulären Betrieb mißbrauchen.

Dann verstehe ich aber die eine Darstellung im Dokument zu den 
MAX1483/MAX1482 nicht, da hier eindeutig von Full-Duplex mit einem 
Single Master BUS geschrieben wird.

Alles was ich bei CAN an Bauteilen gefunden haben liegt Kosten technisch 
über denen von RS485, zugegebener Maßen blicke ich hier nicht ganz 
durch.
Abgesehen von ein paar einzelnen ICs / Controllern für ein paar Euro das 
stück, finde ich nur große Bausteine für mindestens 30 Euro.


Bernd schrieb:
> Die WS2812 oder ähnliche LEDs (RGBW) mit integriertem Controller
> vereinfachen sicherlich den Aufbau der einzelnen Module. Für verteilte
> Module die fest installiert sind kann auch eine CAN verkabelung machbar
> sein.

Die WS2812 sind nur RGB, weitere ähnliche LEDs sind mir bisher nicht 
bekannt.
Da es eine einzelne 3 Chip LED ist, wird hier die Lichtausbeute wohl 
deutlich unter der von 6 autarken 3 Chip LEDs liegen.
Mir geht es in erster Linie darum, möglichst viel Licht mit einer guten 
Farbkontrolle zu erlangen.
Ich möchte mir einzelne Module basteln. (Die erwähnten Slaves)
Ein Modul soll jeweils aus 6 LEDs bestehen. Rot, Grün, Blau, Gelb 
(Amber), Neutral Weiß und UV.
Die Module sollen später via Computer bzw. einer Smartphone App 
gesteuert und einzeln angesprochen werden können.
So lassen sich die gleichen Module für eine passive Raumbeleuchtung und 
gleichzeitig für eine Arbeitsplatzbeleuchtung oder ähnliches einsetzen.
Es würde sich somit die gesamte Raumbeleuchtung mit einem Master und den 
dazu gehörigen Slaves verhältnismäßig einfach einrichten.
(Nach dem die ganze Arbeit getan ist)

Als Beispielrechnung wieso ich gerne so viele Slaves unterstützen 
möchte.
Mein aktuelles Zimmer ist 16qm groß, und hat einen gesamt Umfang von 16 
Metern, wenn ich alle 10cm ein Modul einsetze um im Raum eine 
Flächendeckende, ausreichend starke Beleuchtung zu gewährleisten, dann 
sind 160 Module im Einsatz.
Durch direkte Beleuchtung an verschiedenen Stellen, oder weitere 
Einsatzmöglichkeiten an unterschiedlichen Positionen können es noch 
deutlich mehr Module werden.
Dadurch, dass es eine Adressierung jedes einzelnen Moduls gibt, lässt 
sich dennoch alles jedes Modul unabhängig Steuern.
So ist die passive Raumbeleuchtung unabhängig vom Arbeitslicht, da jeder 
Slave nur auf die für ihn bestimmte Anweisung hört.

Frank K. schrieb:
> Mal was ganz anderes: Es gibt günstige Bluetooth LE oder IEEE 802.15.4
> (Zigbee, 6LoWPan und andere) Module für ein paar Euro. Auf dem Funkchip
> kann man auch seinen eigenen Code mit laufen lassen, so dass ein extra
> Controller entfällt. In jeder Philips Hue und Osram Lightify Birne ist
> so ein Teil drin.

Das hört sich interessant an, halten mich jetzt ruhig für paranoid, doch 
sehe ich in jeder Schnittstelle die Außerhalb meiner 4 Wände zur 
Verfügung steht ein potentielles Einfallstor für Leute die da eigentlich 
nichts zu suchen haben.
Mache ich bsp. einen gravierenden Fehler in der LEDs Steuerung via Funk, 
könnte es über Umwege möglich sein in das Netzwerk ein zu dringen und 
ggf. weitere Geräte zu befallen.
Zudem hängen hier mindestens die WLAN Netze recht nah aufeinander, 
weshalb ich auf Funkverbindungen nach Möglichkeit verzichte um nicht für 
noch mehr Störungen zu sorgen.

Dirk schrieb:
> Solange die Slaves sich absprechen und nicht gleichzeitig
> "Übertragungsfehler"/"Neuer Slave" senden funktioniert das sicher
> problemlos; die Regelung: Slave darf nur antworten wenn er zuvor vom
> Master gnädig auf Paar 1 adressiert wurde ist für "!Übertragungsfehler!"
> ganz praktisch, bei Neueinsteigern ist etwas Vorsicht geboten für den
> Fall, dass sich viele gleichzeitig anmelden bsp. wenn plötzlich gute
> Stromverhältnisse herrschen.

An ein solches Problem hatte ich zunächst nicht gedacht, danke für den 
Denkanstoß.
Da die Slaves nach einander durch ihre jeweilige Adresse angesprochen 
werden, sollte es bei einer ausreichend kurzen Rückmeldung möglich sein, 
den Rückweg auch bei massiven Übertragungsfehlern frei von Störungen 
durch überlagerte Nachrichten zu halten.
Um neue Slaves ein zubinden, könnte nach dem alle bekannten Slaves 
angesprochen wurden, eine kurze Pause seitens des Masters statt finden.
Diese Pause wird dann zum Zeitfenster, welches ein neuer Slave hat um 
eine Adresse an zu fordern, da der Rückkanal auch bei vielen 
Störmeldungen nach einer kurzen Verzögerung frei ist. Damit nun nicht 
alle Adresslosenslaves gleichzeitig während der Pause eine Adresse 
anfordern, wird eine Anforderung mittels Knopfdruck auf dem Slave 
veranlasst und in der Pause ausgelöst.
So kommt sich kein Slave in die Quere und dennoch erreichen den Master 
alle benötigten Informationen.

Dirk schrieb:
> wenn du im µC eine (programmiertechnisch) einfache LUT implementierst
> (gamma 2,2; 12-bit)
> W[0..255] mit W[x]=(2^12-1)*(x/255)^2,2
> dann benötigst du extern lediglich 8-bit (u.U. 7) und  - das ist der
> eigentliche Punkt - der Bereich ist praktisch linear zur Wahrnehmung
> d.h. ein Fading 255-->0 wird als 'gerade' wahrgenommen und du hast bei
> rgb grob PC Farbwerte (der genaue gammawert müsste gemessen werden aber
> 2,2 sollte grob passen)

Diese Information ist sehr hilfreich, vielen Dank.
Hier werde ich mich auch noch etwas genauer einlesen, bisher habe ich 
nur etwas von einer logarithmischen Helligkeitswahrnehmung gelesen.

Dirk schrieb:
>>einzeln: 6 Bit für ggf. Fading. (0-63 ms)
> unpraktisch: wenn der PC sendet wann das nächste Datum zu erwarten ist,
> dann betrifft das alle Kanäle; für Effekte mit etwas anderer Definition
> z=1ms*2^(w/c) u.U. nett, aber kompliziert für einfaches Softwaremodell.

Da habe ich mich wohl etwas missverständlich ausgedrückt, mit dem 
Fadingwert, sollte angegeben werden, bis wann der im vorderen Teil 
angegebene Farbwert erreicht werden soll.
Bei 0 sofort und bei 63 ms ein herunter dimmen auf den angegebenen Wert.
So können bei Farbwechseln weichere Übergänge geschaffen werden, ohne 
viele Daten über den BUS senden zu müssen.
Wenn ich nur 8 Bit für den Farbwert benötige und weiterhin bei 2 Byte 
für jede Farbe bleibe, so würden theoretisch sogar Fadingzeiten von bis 
zu 255ms möglich sein.
Die den BUS bei konstanten Farbverläufen zusätzlich entlasten würden.
So würden beim sanftem Ausschalten mit einer Sekunde fading auf Null nur 
vier Nachrichten benötigt werden.


Erneut muss ich mich bei euch für die Vielzahl an wirklich hilfreichen 
Antworten bedanken, diese helfen mir wirklich sehr.
Vielen Dank an alle, die sich bemühen mir weiter zu helfen.

Mit freundlichen Grüßen
Marcel

[Stefan F. (Gast)]

RS485 kann man in zwei Varianten betreiben:

  * 1 Leiterpaar = Half Duplex
  * 2 Leiterpaare = Full Duplex

Die erste Variante scheint häufiger vor zu kommen.

[Peter D. (peda)]

The S. schrieb:
> Dann verstehe ich aber die eine Darstellung im Dokument zu den
> MAX1483/MAX1482 nicht, da hier eindeutig von Full-Duplex mit einem
> Single Master BUS geschrieben wird.

Prinzipiell ginge das (MAX1482), man muß allerdings 4 Datenleitungen 
verlegen.
Auch gewinnt man dabei nichts, da trotzdem der Master immer erstmal 
einem Slave sagen muß, wann er auf Senden umschalten darf.
Man treibt also einen doppelt hohen Aufwand an Verkabelung und hat davon 
keinerlei Nutzen.

The S. schrieb:
> Alles was ich bei CAN an Bauteilen gefunden haben liegt Kosten technisch
> über denen von RS485, zugegebener Maßen blicke ich hier nicht ganz
> durch.

Z.B. der CAN-Transceiver TJA1050T (0,821€) kostet bei Farnell nur die 
Hälfte vom MAX1482 (1,63€). Und ein AVR mit CAN kostet 3,60€ 
(ATMEGA16M1-AU).

[Volker S. (vloki)]

The S. schrieb:
> Abgesehen von ein paar einzelnen ICs / Controllern für ein paar Euro das
> stück, finde ich nur große Bausteine für mindestens 30 Euro.

Verstehe ich auch nicht. Wie hast du denn da gesucht?
Ein PIC18F25K83 kostet ~2€ (Einzelstück), bei 100 dann nur noch 1,50
Transceiver bei Hundert, wohl so ~50ct.

OK, der 18F hat nur 4 Hardware PWM. Wenn man bei MAPS sucht, CAN und 
6*PWM auswählt, dann kommen da 202 Treffer. Schränkt man das auf 
möglichst wenig Pins (z.B 32) ein, dann bleiben noch 24. Die kann man 
auch nach Preis sortieren...

[Einer K. (Gast)]

The S. schrieb:
> wenn ich alle 10cm ein Modul einsetze

Dann brauchst du kein fettes Bussystem, wie CAN RS485 usw.
WLAN ist sowieso bei der Anzahl aus dem Rennen.
Die meisten Haushalts Router können maximal 32 Geräte.

Ein Tokenpassing System auf TTL Level ist voll ausreichend.
Nahezu jeder (alle?) ATMega hat eine UART on Board.
Jeweils Tx zum rechten Partner, an Rx, und fertig ist der Ring.

Adressierung, kann man machen, ergibt sich aber auch schon aus der 
Position.

[avr (Gast)]

Arduino F. schrieb:
> Ein Tokenpassing System auf TTL Level ist voll ausreichend.
> Nahezu jeder (alle?) ATMega hat eine UART on Board.
> Jeweils Tx zum rechten Partner, an Rx, und fertig ist der Ring.

Kann man machen wenn die Datenrate ausreicht. Mit Tokenpassing hat das 
allerdings gar nichts zu tun.

[Einer K. (Gast)]

avr schrieb:
> Kann man machen wenn die Datenrate ausreicht. Mit Tokenpassing hat das
> allerdings gar nichts zu tun.

Nunja...

Will man wirklich Adressen vergeben, Geräte einzeln ansprechen, 
Rückmeldungen auswerten, usw. dann ist man schon fast bei einem 
Tokenpassing System angekommen.

[Volker S. (vloki)]

Arduino F. schrieb:
> Dann brauchst du kein fettes Bussystem, wie CAN...

Also ich finde CAN recht schlank ;-)
Nimmt mir einen Haufen lästiger Arbeit ab!

[Einer K. (Gast)]

Volker S. schrieb:
> Nimmt mir einen Haufen lästiger Arbeit ab!

Glaube ich dir....
Habe ja auch nichts grundsätzlich gegen CAN.
Halte es nur nicht für das Optimum, für dieses Problem.

The S. schrieb:
> dann sind 160 Module im Einsatz.
Habe noch keinen CAN Bus mit 160 Teilnehmern laufen sehen.
Sehe da Probleme leuchten, kann mich aber irren.

Außerdem dürfte das erheblich teurer werden als 160 * 10cm Schaltdraht.

[Bernd K. (prof7bit)]

Falk B. schrieb:
> and we have developed our own DLL
> which in turn interfaces with the D2XX DLL from FTDI. This threaded DLL
> includes Open, Close, Read, Write & Status functions and will make it
> quick and easy for customers

So ein crap. Ein CAN Controller Treiber hat sich gefälligst als 
Netzwerkschnittstelle anzumelden so daß man es in 
/etc/network/interfaces konfigurieren und die normale Socket CAN API 
benutzen kann wie jeder andere CAN controller unter diesem Himmel es 
auch tut.

[Volker S. (vloki)]

Arduino F. schrieb:
> Habe ja auch nichts grundsätzlich gegen CAN.
> Halte es nur nicht für das Optimum, für dieses Problem.

Ich denke es wäre sehr einfach umsetzbar, aber da ich mich nicht mit 
allen  Alternativen auskenne, kann ich auch nicht sagen, ob es das 
Optimum ist.


Arduino F. schrieb:
> The S. schrieb:
>> dann sind 160 Module im Einsatz.
> Habe noch keinen CAN Bus mit 160 Teilnehmern laufen sehen.
> Sehe da Probleme leuchten, kann mich aber irren.

Die Teilnehmer wären ja mehr oder weniger passiv,
wenn eigentlich immer nur der ein und selbe sendet.

[Dietrich L. (dietrichl)]

Arduino F. schrieb:
> Nunja...
>
> Will man wirklich Adressen vergeben, Geräte einzeln ansprechen,
> Rückmeldungen auswerten, usw. dann ist man schon fast bei einem
> Tokenpassing System angekommen.

auch nunja, aber beim Tokenpassing geht es um die Verwaltung von 
Multimaster-Systemen. Und das "schon fast" lasse ich hier nicht gelten, 
denn eine sichere Multimaster-Steuerung ist nicht trivial.

Beim Ring geht es erst einmal um die Topologie des Busses und man kann 
den Datenverkehr ohne weiteres als Master-Slave-System mit nur einem 
Master organisieren.

[Einer K. (Gast)]

Dietrich L. schrieb:
> auch nunja,
Genau!

Bisher wurde in diesem Thread noch kein solches "Ring" System in den 
Raum geworfen. Weiter verteidigen will ich es nicht.

Was der TE daraus macht, soll nicht mein Problem sein.

Und wenn dich das Wort Tokenpassing so sehr stört, dann ignoriere es 
doch bitte.
Aber wenn jemand anders das Wort Tokenpassing noch nicht kennt, dann 
sollte er mal bei Google rein klappern.
Vielleicht hilfts ja dabei, das Denken zu ändern.




Dietrich L. schrieb:
> Beim Ring geht es erst einmal um die Topologie des Busses
Und wenn du schon so pingelig bist, dann sage bitte nicht Bus zu einem 
Ring.
Denn das ist kein Bus.

[Peter D. (peda)]

Volker S. schrieb:
> Also ich finde CAN recht schlank ;-)
> Nimmt mir einen Haufen lästiger Arbeit ab!

Insbesondere sehr viel Programmierarbeit, wenn man noch nicht so 
vertraut mit Busprotokollen ist.
Man kann auf CAN auch höhere Protokolle aufsetzen, aber der Clou ist, 
man muß es nicht.
CAN läuft auch bare metal schon stabil und zuverlässig, was auf jegliche 
UART-Spielereien erstmal nicht zutrifft. Ohne ein Protokoll ist man bei 
der UART erschossen.

[Dietrich L. (dietrichl)]

Arduino F. schrieb:
> Bisher wurde in diesem Thread noch kein solches "Ring" System in den
> Raum geworfen. Weiter verteidigen will ich es nicht.

Das ist auch gut so und durchaus eine sinnvolle Idee.

> Dietrich L. schrieb:
>> Beim Ring geht es erst einmal um die Topologie des Busses
> Und wenn du schon so pingelig bist, dann sage bitte nicht Bus zu einem
> Ring.
> Denn das ist kein Bus.

Physikalisch nicht, aber logisch schon: jeder kann mit jedem reden. Ob 
das dann allerdings "logischer Bus" genannt werden kann weiß ich nicht 
:-(
Insofern gebe ich dir recht ;-)

[Tom (Gast)]

Hallo,
Bei 160 Knoten fällt der Preis pro Knoten schon deutlich ins Gewicht.
Deshalb sollten diese einfach/billig sein. CAN hat zwar seine Vorzüge, 
die aber hier m.E.n. gar nicht genutzt werden. Es gibt doch nur einen 
Master, der die Kommunikation steuert. Und ein Slave antwortet nur auf 
Befehl des Masters
--> keine Multimaster-Fähigkeit nötig. Bei dem Anwendungsfall ist eine 
Rückantwort auch nur selten nötig.
Das eigentliche Problem ist doch eher ein physikalisches: 160 Knoten die 
als Last am Bus hängen.
Eine UART-Daisy-Chain von jeweils Tx->Rx ist wahrscheinlich zu langsam, 
selbst bei 460800 baud braucht ein Byte (10bit) 22µs + Verarbeitungszeit 
für den Kontroller. Bei 30µs würde der letzte Knoten die Daten erst nach 
ca. 5ms bekommen. Aber warum sollte dass Signal erst durch den µC?
Einfach ein Gatter zum nächsten Knoten und Abgriff zum µC. Wäre dann wie 
MIDI.
Protokoll ganz einfach: Adresse, Daten, CRC
Die Antwort des Slave könnte genauso zurück laufen. Oder noch primitiver 
über ein Gatter auf ein wired-And Bus, der mit deutlich niedriger 
Baudrate fährt.

BG, Tom

[Jobst Q. (joquis)]

The S. schrieb:
> Die WS2812 sind nur RGB, weitere ähnliche LEDs sind mir bisher nicht
> bekannt.

> Da es eine einzelne 3 Chip LED ist, wird hier die Lichtausbeute wohl
> deutlich unter der von 6 autarken 3 Chip LEDs liegen.


Es gibt den Controller darin auch einzeln als WS2811. Die 3 Ausgänge 
kann man für die Ansteuerung beliebiger LEDs in beliebiger Helligkeit 
verwenden. Für 6 verschiedene LEDs bräuchtest du eben 2 Stück WS2811.

> Mein aktuelles Zimmer ist 16qm groß, und hat einen gesamt Umfang von 16
> Metern, wenn ich alle 10cm ein Modul einsetze um im Raum eine
> Flächendeckende, ausreichend starke Beleuchtung zu gewährleisten, dann
> sind 160 Module im Einsatz.

Mit den WS2811 bräuchtest du dann nur jeweils 10cm Datenverbindung von 
einem Modul zum nächsten. Da jeder nur bis zum nächsten sendet, ist sie 
weniger störanfällig als ein langer Bus für alle.

[avr (Gast)]

Tom schrieb:
> Aber warum sollte dass Signal erst durch den µC?

Das hat den Vorteil, dass es prinzipbedingt keine Buskollision gibt, mit 
dem Nachteil der Latenz, die natürlich mindestens ein Frame beträgt. 
Außerdem wird die Hardware einfacher und günstiger. 1 MBaud kann 
übrigens so ziemlich jeder µC. Ein STM32F0 kann bis zu 6 MBaud, da sieht 
die Sache gleich schon ganz anders aus.

Arduino F. schrieb:
> Und wenn dich das Wort Tokenpassing so sehr stört, dann ignoriere es
> doch bitte.

Wenn man über die Topologie spricht (wie schon angemerkt), dann ist das 
Wort fehl am Platz. Nimm das nicht persönlich - es geht mir nicht um 
dich, sondern um andere Personen, die dabei etwas Lernen könnten was so 
nicht stimmt.

[Thomas H. (flaretom)]

@AVR:
Warum sollte es Buskollisionen geben in dem System?
Master->Slave:geht HW technisch gar nicht.
Slave ->Master: Der Slave hat zu schweigen, bis er gefragt wird.
Bei dem Anwendungsfall sollte das reichen.

Natürlich kann man die Kette schneller fahren, aber:
- für den Rückkanal bräuchte man aber eine 2.UART (d.h. ein zweites 
Rx/Tx Paar). Es sei den man hat wirklich einen Ring - Ok, haut im Zimmer 
hin, aber was ist wenn man mal Abstiche haben will. Reine Ringtopologie 
wäre mir persönlich zu restriktiv.
- jeder Knoten muss alle Pakete weiterleiten. Hängt der µC nicht 
dazwischen, dann kann er sich nach der Adresse ausklinken und auf die 
nächste Nachricht warten bzw. etwas sinnvolles machen (PWM ohne HW-Timer 
z.B.). Eine neue Nachricht kann z.B. durch Break oder Parity Fehler von 
der HW allein erkannt werden.

Naja, wie gesagt bei 160 Knoten würde ich alles so günstig machen wollen 
wie möglich, also auch PWM mit GPIO und keinen µC mit 6PWM Kanälen.
-> STM32F030F4P6

BG, Tom

[Thomas H. (flaretom)]

Ok, eine Sache die eine UART-Daisy-Chain erlauben würde ist die 
Adressierung der Knoten durch ihre Position in der Kette. Wenn man das 
braucht...
Erzwingt natürlich wieder ein Ketten- bzw. Ringtopologie.
Auf jeden Fall Viel Spaß beim Basteln :)

[Klaus (Gast)]

Jobst Q. schrieb:
> Es gibt den Controller darin auch einzeln als WS2811.

Das ist noch nicht alles. Da man in Asien bunte Lichter liebt, gibt es 
gefühlt tausend fertige Sachen. Mal bei Aliexpress nach RGB oder RGBW 
suchen. Da kommen dann neben den WS281x auch APA102 oder SK68xx, zum 
Teil mit SPI. Da bekommt man richtig Geschwindigkeit in die Ansteuerung. 
Auch Module mit mehreren LEDs pro Farbe für 12 oder 24V Betrieb findet 
man. Mit einer Neuentwicklung lässt sich nichts mehr gewinnen.

> In contrast to the SK6812 used in some of our other similar LED strips,
> which use a specialized one-wire control interface and require strict
> timing, the SK9822 uses a standard SPI interface for control (with
> separate data and clock signals) and has no specific timing requirements,
> making it much easier to control

Das stammt von hier

https://www.pololu.com/product/3090

die Doku ist bei den Amis besser, die Preise eher in China

MfG Klaus

[avr (Gast)]

Thomas H. schrieb:
> Warum sollte es Buskollisionen geben in dem System?
> Master->Slave:geht HW technisch gar nicht.
> Slave ->Master: Der Slave hat zu schweigen, bis er gefragt wird.
> Bei dem Anwendungsfall sollte das reichen.

Ich sagte prinzipbedingt. OneWire funktioniert auch ohne Kollision, aber 
nur bei fehlerhafter Software kann es auch Kollisionen geben. Bei dem 
Ring muss man sich darüber keine Gedanken machen, da logisch jeder µC 
eine direkte Verbindung zum nächsten hat.

> Natürlich kann man die Kette schneller fahren, aber:
> - für den Rückkanal bräuchte man aber eine 2.UART (d.h. ein zweites
> Rx/Tx Paar). Es sei den man hat wirklich einen Ring - Ok, haut im Zimmer
> hin, aber was ist wenn man mal Abstiche haben will. Reine Ringtopologie
> wäre mir persönlich zu restriktiv.

Man kann den Ring auch zurückführen, mit ein paar Buffer dazwischen. Du 
vergisst hier, dass die Lösung als Ring erstmal eine Leitung weniger 
benötigt.

> - jeder Knoten muss alle Pakete weiterleiten. Hängt der µC nicht
> dazwischen, dann kann er sich nach der Adresse ausklinken

Mit DMA kein Problem.

Ich sehe den großen Vorteils des Rings erstmal in dem Reduzierten 
HW-Aufwands. Man braucht keine extra Buffer, die Adressierung ist 
einfach und die Software ebenso, da es Punkt-zu-Punkt-Verbindungen sind.

[Marcel B. (the_s616)]

Vielen Dank für die weiteren sehr ausführlichen und hilfreichen 
Antworten.

Peter D. schrieb:
> Auch gewinnt man dabei nichts, da trotzdem der Master immer erstmal
> einem Slave sagen muß, wann er auf Senden umschalten darf.
> Man treibt also einen doppelt hohen Aufwand an Verkabelung und hat davon
> keinerlei Nutzen.

Ok, dann werde ich den Plant mit den MAX1482 und voll duplex verwerfen 
und stattdessen mit den MAX1483 arbeiten, 100 Stück gibt es hier für 11 
Dollar bei Aliexpress.

Arduino F. schrieb:
> Ein Tokenpassing System auf TTL Level ist voll ausreichend.
> Nahezu jeder (alle?) ATMega hat eine UART on Board.
> Jeweils Tx zum rechten Partner, an Rx, und fertig ist der Ring.

Ein sauberer Ring ist die fertige Installation (so wie ich sie mir 
vorstelle) leider auch nicht.
Oder stört es bei dieser Variante nicht, wenn dann auch mal zwei Meter 
zwischen zwei Modulen liegt? (Arbeitslicht von Deckennähe herunter 
geführt)

Tom schrieb:
> Eine UART-Daisy-Chain von jeweils Tx->Rx ist wahrscheinlich zu langsam,
> selbst bei 460800 baud braucht ein Byte (10bit) 22µs + Verarbeitungszeit
> für den Kontroller. Bei 30µs würde der letzte Knoten die Daten erst nach
> ca. 5ms bekommen. Aber warum sollte dass Signal erst durch den µC?
> Einfach ein Gatter zum nächsten Knoten und Abgriff zum µC. Wäre dann wie
> MIDI.
> Protokoll ganz einfach: Adresse, Daten, CRC
> Die Antwort des Slave könnte genauso zurück laufen. Oder noch primitiver
> über ein Gatter auf ein wired-And Bus, der mit deutlich niedriger
> Baudrate fährt.

Ein interessanter Ansatz, 5ms Verzögerung könnte sogar tatsächlich 
ausreichend sein, weniger ist natürlich dennoch schön :D

Jobst Q. schrieb:
> Mit den WS2811 bräuchtest du dann nur jeweils 10cm Datenverbindung von
> einem Modul zum nächsten. Da jeder nur bis zum nächsten sendet, ist sie
> weniger störanfällig als ein langer Bus für alle.

Ich sehe hier eine Einschränkung in der Versorgung.
Da es ja 3 Chip LEDs in 6 "Farben" sind.
Also insgesamt 18 LEDs die versorgt werden wollen, jedoch effektiv 6 
Kanäle die gesteuert werden müssen.

Lässt sich hier etwas mit MOSFETS machen?
Dann könnte schon ein kleiner ATMEGA48PA-AU ausreichen, oder ist der 
dann bei 6 PWM Kanälen zu langsam / ungenau?

Wenn ich es richtig verstanden habe, lässt sich theoretisch jeder I/O 
Pin via Software zum PWM Signalgeber "umbauen", der dann CPU Takt 
gebunden eine entsprechende Frequenz erreicht?

Eine Sache ist mir erst in der Nacht klar geworden, über die 
Stromversorgung habe ich mir bisher keine Gedanken gemacht.
Zunächst hatte ich geplant alles mit 5V zu betreiben (Hier wären dann 
die 3 Chip LEDs intern Parallel geschaltet worden) doch mit der Lösung 
über einen Vorwiderstand würde hier pro Modul alleine für die LED 
Versorgung maximal 1,8 Watt anfallen.
Nach längerer Überlegung bin ich dann zum Schluss gekommen, die 3 Chip 
LEDs jeweils so zu verleiten, dass sie in Reihe geschaltet sind. Somit 
kommen die LEDs auf eine Durchlassspannung von 6,0V respektive 9,6V.
Mit einem PC Netzteil lässt sich nun mittels 12V, 7V und 5V alles mit 
hoher Effizienz versorgen. (12V und 7V für die LEDs, 5V für MCUs)
So erhalte ich bei selber Lichtleistung einen Energiebedarf von 1,24W 
für die LED Versorgung pro Modul.
Nun stellt sich mir jedoch die Frage, ob ein solches NT mit einem 
Negativen Stromfluss auf der 5V Schiene gut zurecht kommt, oder ob es 
hier zu Problemen kommen kann.

Mit freundlichen Grüßen
Marcel

[Bernd K. (prof7bit)]

Jemand hat vor ein paar Jahren mal was gepostet über einen Ring bei dem 
über jeweils ein Relais pro Slave der Ausgang entweder direkt an den 
Eingang geschaltet war oder wenn das Relais anzog war der Ausgang an den 
UART TX des Slave geschaltet, der hat da irgendeine Mimik die in einer 
Reihe nebeneinander stehender Schränke eingebaut war angesteuert wenn 
ich mich recht erinnere.

das müsste sich auch statt Relais mit einen einzigen und-Gatter pro 
Slave machen lassen, ungefähr so:

RX  TX Master
|   |
O   O
|   |
|   |_____________RX
|   |
|   |  ___________TX
|   | |
|  -----
|  | & |
|  -----
|   |
|   |
|   |
|   |
O   O
|   |
|   |_____________RX
|   |
|   |  ___________TX
|   | |
|  -----
|  | & |
|  -----
|   |
|   |
|   |
|   |
O   O
|   |
|   |_____________RX
|   |
|   |  ___________TX
|   | |
|  -----
|  | & |
|  -----
|   |
|   |
|   |
|   |
O   O
|   |
|   |_____________RX
|   |
|   |  ___________TX
|   | |
|  -----
|  | & |
|  -----
|   |
|   |
|   |
|   |
O   O
|___|

Aber mit Relais hätte es den Vorteil daß ein Slave komplett abrauchen 
könnte und der TX dennoch weiterhin durchgeschleift wäre.

Protokollmässig kann man das dann so behandeln als wäre es RS485, jeder 
Slave hat eine Adresse und antwortet nur wenn er gefragt wird.

[Marcel B. (the_s616)]

Bernd K. schrieb:
> das müsste sich auch statt Relais mit einen einzigen und-Gatter pro

Interessante Idee, jedoch vermutlich tatsächlich teurer, als mit MAX1483 
von Aliexpress.

Mein aktueller Schaltplan wurde von mir mal an gehangen.
Gibt es hier irgendwelche groben Schnitzer?
Hat jemand eventuell noch einen Tipp?
Der ATmega ist nicht als absolut fest eingeplant,
sondern soll nur ein funktionierender Platzhalter sein.
PWM werde ich wohl nun via Software lösen, da hier dann kleinere MCUs 
eingesetzt werden können.

Insgesamt fallen über den LEDs "RED" und "AMBER" 6V und über den 
restlichen jeweils 9,6V ab.
Die Transistoren habe ich mit einer Usat von 0,7V eingerechnet, da ich 
hier noch keine konkretes Bauteil gefunden habe.

Mir wird mittlerweile klar, dass ich den Titel anders hätte wählen 
sollen, dann wäre ich vermutlich schneller zu einem brauchbaren Ergebnis 
gekommen.
Ich hoffe, dass mir kurz vor der Zielgeraden noch geholfen werden kann, 
auch wenn es schon längst nichts mehr mit der eigentlichen Frage zu tun 
hat.
Doch extra einen neuen Beitrag zu eröffnen, erscheint mir etwas zu viel 
des Guten,
da hier ja nun alle Informationen vorliegen.
Hierfür möchte ich mich entschuldigen.

Mit freundlichen Grüßen
Marcel

[Andi B. (andi_b2)]

Du vermischt in diesem Thread ziemlich viele Einzelprobleme, weshalb 
dieser nun schon ziemlich unübersichtlich ist. Wenn ich das richtig 
sehe, dann hast du dich für RS485 entschieden. Ist auch meine Wahl. Ich 
nehme den MAX3072 auch deswegen, weil ich meinen uC (EFM32GGxxx) mit 
3,3V versorge. Ebenfalls slew rate limited und 1/8 load.

Den Aufwand für das Protokoll solltest du aber nicht unterschätzen. Ich 
hab das für mich mit Gruppenbildung und hot plugging spezifiziert und zu 
einem größeren Teil auch schon implementiert. Sowohl am uC als auch für 
einen rudimentären PC Tracer. Deshalb kann ich dir auch sagen, dass ist 
ein ziemlicher Aufwand.

Wenn du das ernsthaft weiterverfolgen willst, würde ich dir raten die 
Teile getrennt zu diskutieren. Und beschäftige dich nacheinander mit den 
einzelnen Teilen. Also nicht PWM Steuerung von LEDs mit Bustyp und 
Protokoll in einem Thread. Denk auch über mögliche Abstriche bei den 
Anforderungen nach. Z.B. brauchst du wirklich hot plugging mit 
automatischer Adressvergabe? Die Abritrierung erfolgt bei mir indirekt 
über eine vorher einprogrammierte einzigartige MAC Adresse und bewusst 
in Kauf genommener eventueller (Verzögerungs- und Verarbeitungszeit 
abhängig) Buskollisionen. Ich mach das. Aber überlege ob du dir den 
Aufwand nicht doch sparen willst. Könnte sonst leicht zu einem 
Monsterprojekt ausarten, welches nie fertig wird. Ich weiß wovon ich 
rede :-)

[Peter D. (peda)]

Andi B. schrieb:
> Deshalb kann ich dir auch sagen, dass ist
> ein ziemlicher Aufwand.

Das ist auch meine Erfahrung, Protokolle werden oft unterschätzt.
Daher meine Empfehlung zu CAN, auch wenn die MCs mit CAN einige Cent 
teurer sein mögen.
Es gibt neben AVRs auch günstige PIC18 mit CAN.

[Dietrich L. (dietrichl)]

Peter D. schrieb:
> Protokolle werden oft unterschätzt

... weil viele erstmal nur den "Gut"-Fall betrachten.

Im Fehlerfall
- Störungen auf der Leitung
- Unterbrechung der Leitung
- Ausfall eines Teilnehmers
- Kollision auf dem Bus
- Dauersenden eines Teilnehmers
- ???
kann es kompliziert werden, besonders dann, wenn ein Fehler u.U. nicht 
erkannt wird und zu ungewollten und kritischen Aktionen führt.

[chris (Gast)]

Ich würde hier auf ein Tranceiver Baustein verzichten, und es z.B. mit 
einem
Tiny20 machen. 6x pwm + i2c slave sowie 2x i2c master in SW.

[Dr. Sommer (Gast)]

chris schrieb:
> Ich würde hier auf ein Tranceiver Baustein verzichten, und es z.B. mit
> einem
Wenn schon integrierter Transceiver, dann gleich das störsichere CAN 
statt dem störempfindlichen I²C:
Peter D. schrieb:
> Gibbet aber auch onchip:
> LPC11C12FBD48/301

[chris (Gast)]

Integrierten Can Tranceiver, nur LPC11C22, also 2,68 € gegen 0,394 € , 
bei
250 Schaltungen ist die Differenz genau 571,5 € .

Und i2c bei diesen kurzen Strecken, nur point to point, master push 
pull,
die Fehleranfalligkeit ist sehr gering, aber jedem das Seine.

[Andi B. (andi_b2)]

chris schrieb:
> Und i2c bei diesen kurzen Strecken, nur point to point, master push
> pull,
> die Fehleranfalligkeit ist sehr gering, aber jedem das Seine.

I²C auf 25m mit 50kByte/s (--> >> 500kBit)? Das meinst du aber nicht 
ernst.

[chris (Gast)]

Ich meinte auf keinem Falle ein shared I2C bus für alle Nodes, sondern
ein point to point i2c bus, ein master, ein slave !

Wenn im Anfangspost bei noch ungewisser Architektur 25mt bus für eine 
Deckenbeleuchtung steht, bei 250 clients sind warscheinlich 10cm Abstand 
von
einem Node zum nächsten gemeint. Kann mich irren, ich lese es so aber 
raus.

Mfg
Chris

[Marcel B. (the_s616)]

Peter D. schrieb:
> Das ist auch meine Erfahrung, Protokolle werden oft unterschätzt.
> Daher meine Empfehlung zu CAN, auch wenn die MCs mit CAN einige Cent
> teurer sein mögen.
> Es gibt neben AVRs auch günstige PIC18 mit CAN.

Als Student sitzt der Geldbeutel nicht ganz so locker, bei ein paar 
wenigen macht es kaum was aus, doch bei geplanten >160 summiert sich da 
schon was hübsches auf.
Bei der Lösung über einen externen MAX1483 habe ich kosten von ca. 10 
Ct. pro Knoten.
Bei dieser Lösung kann zudem der MCU stark beschnitten ausfallen.
Hardware PWM wäre zwar schön, doch über Software lässt sich das ganze 
auch noch steuern.
Wenn nun ein entsprechender MCU mit CAN bei einem relativen Aufpreis von 
unter 10 Ct. liegt, wäre ich geneigt mir diese noch mal etwas genauer an 
zu schauen.

Das soll jetzt keines Wegs abwertend klingen, auch wenn es den Eindruck 
erwecken könnte.
Ich möchte halt mit diesem Projekt so viel wie Möglich lernen, was mir 
später einmal von nutzen sein kann.
Da sehe ich ein zusammen basteln nach "Baukasten" nicht als 
erstrebenswert an. CAN mag mir einiges an Arbeit abnehmen, doch denke 
ich, dass ich bei einem RS485 BUS zwar ordentlich aufs Maul bekommen, 
doch auch am meisten lernen kann.

So muss ich mich um alles selbst kümmern, somit wird sich jeder Fehler 
Sofort bemerkbar machen, hieraus kann ich dann versuchen möglichst viel 
Wissen zu generieren.
(Natürlich in der Hoffnung, dass ich nicht vor Frust alles an die Wand 
schmeiße) ;)


chris schrieb:
> Wenn im Anfangspost bei noch ungewisser Architektur 25mt bus für eine
> Deckenbeleuchtung steht, bei 250 clients sind warscheinlich 10cm Abstand
> von
> einem Node zum nächsten gemeint. Kann mich irren, ich lese es so aber
> raus.

Nein, du irrst nicht.
Im Mittel wird es wohl auf ca. 10cm pro Node heraus laufen.
Doch möchte ich die Möglichkeit haben, auch mal zwischen zwei Nodes um 
die zwei Meter zu haben.
Um so z.B. Arbeitslicht ebenfalls über einen Master steuern zu können.
Spart im Endeffekt dann wieder ein bisschen was, wenn der gesamte Raum 
nur einen Master benötigt.
Die geschätzt zwei Meter entstehen halt dadurch, dass ich den BUS und 
die Versorgung von Deckennähe zu mir herab hole, dann ein Array aus ein 
paar sehr kurz verbundenen Nodes Bilde und die Kabel dann wieder 
Richtung Decke die allgemeine Raumbeleuchtung weiter Versorgen lasse.

So kommt tatsächlich annähernd eine Ringtopologie zu Stande.
Jedoch habe ich keine Erfahrungen wie es sich mit den Latenzen verhält.
(bei maximal Ausbau wären dann 250 Hops für einen Umlauf von Nöten)

Andi B. schrieb:
> Wenn du das ernsthaft weiterverfolgen willst, würde ich dir raten die
> Teile getrennt zu diskutieren. Und beschäftige dich nacheinander mit den
> einzelnen Teilen. Also nicht PWM Steuerung von LEDs mit Bustyp und
> Protokoll in einem Thread.

Also stellt es hier kein Problem dar, wenn man verschiedene Teile eines 
Projekts in spezialisierten Beiträgen einzeln ausdiskutiert?
Leider habe ich bisher in Foren die Erfahrung gemacht, dass alles was 
Ansatzwiese mit dem Thema zu tun hat gefälligst in einem Thread zu 
stehen hat.

Derzeit habe ich noch zu ein paar Punkten offene Fragen, die ich dann 
ggf. in einzelnen Themen behandeln werde, damit es hier noch möglichst 
übersichtlich bleibt.
Sollte ich in den Themen, die ich in Zusammenhang mit diesem Projekt 
erstelle die jeweils anderen Themen Verlinken, oder einfach nur bei 
Bedarf entsprechende Informationen zwischen diesen austauschen?

An sich benötige ich eine Kommunikation die folgende Eigenschaften 
erfüllt:
1. Relativ störsicher.
2. Hohe Datenrate.
3. Niedrige Latenz.
4. Günstig.
5. Nachrichtenzuweisung.

Hier hatte ich halt in erster Linie an einen klassischen BUS mit 
Adressierung gedacht.

Ich bedanke mich auch weiterhin für diese wirklich freundliche und 
sachkundige Hilfe bei meinen Fragen.

Mit freundlichen Grüßen
Marcel

[Peter D. (peda)]

The S. schrieb:
> So muss ich mich um alles selbst kümmern, somit wird sich jeder Fehler
> Sofort bemerkbar machen

In der Praxis ist es aber nicht so einfach. Gerade 
Kommunikationsprobleme treten selten sofort auf. Und wenn dann der Bus 
alle Stunde abkackt, muß man erstmal den Teilnehmer finden, der es 
verursacht hat.

UART-Protokolle werden gerne als Text aufgebaut. Das kostet zwar 
Datenrate, aber man kann es mit einem PC mitloggen, in eine Datei 
schreiben und dann später analysieren.
Binärprotokolle sind nicht direkt lesbar, insbesondere bei Fehlern.

[chris (Gast)]

Wenn dir 245 Adressen genügen würden, wäre Modbus eine plug and play 
Möglichkeit.
Tiny414 (0.394 € Mouser) mit HW rs232, driver 1/8 load unit (z.B. 
ISL81487IBZ-T 0.494 €) .

[Thomas H. (flaretom)]

Hi,

Also ich würde mich mittlerweile dem Vorschlag von AVR anschließen:
- die TXD-RXD-Verkettung kostet keine zusätzliche HW
--> Die Knoten können sehr günstig sein (µC + LED) aliexpress 10 Stück 
STM32F030F4P6 < 5€
- Adressierung nach ID und Position ist möglich
- Entnahme, Zufügen von Knoten dadurch problemlos möglich
- Buskollisionen kann es prinzipbedingt nicht geben --> sehr einfaches 
Master/Slave Protokoll möglich
- Man könnte sogar etwas Vergleichbares wie beim WS8212 basteln: Jeder 
Knoten knabbert etwas von einem Bytestring ab und gibt nur den Rest 
weiter --> eine lange Nachricht, die alle Knoten ansteuert
- die Durchlaufzeit ist für den Anwendungsfall bei hoher 
Übertragungsrate zu vernachlässigen
- Die kurzen Abstände zwischen den Knoten erlauben eine hohe Baudrate 
ohne Mehraufwand an Treiber etc.
- Wenn ein Knoten spinnt, sieht man an der LED Reaktion sofort bis wohin 
die Kette funktioniert

Wenn der Tag 48h hätte, könnte man sich so etwas glatt auch mal basteln 
;).

BG, Tom

[Marcel B. (the_s616)]

Thomas H. schrieb:
> --> Die Knoten können sehr günstig sein (µC + LED) aliexpress 10 Stück
> STM32F030F4P6 < 5€

> Wenn der Tag 48h hätte, könnte man sich so etwas glatt auch mal basteln
> ;).
>
> BG, Tom

Das hört sich tatsächlich nicht ganz so verkehrt an, auch wenn ich mir 
dann mit der Spannungsversorgung Gedanken machen muss, hatte eigentlich 
geplant ein PC Netzteil zu nutzen.
Doch der STM verträgt ja keine 5V ^^
Laut Datenblatt, 
http://www.st.com/content/ccc/resource/technical/document/datasheet/a4/5d/0b/0e/87/c4/4d/71/DM00088500.pdf/files/DM00088500.pdf/jcr:content/translations/en.DM00088500.pdf
verfügt der Controller zwar über 6 PWM, doch wenn ich es richtig 
verstehe, kann er nur 4 unabhängige Channel erzeugen, oder gilt das nur 
für den TIM1 und über den Link mit den weiteren speziellen Timern, 
kommen so 6 unabhängige PWM Channel zu Stande?

Der Preis ist natürlich ansehnlich, Steuerung und Kommunikation wäre 
hier dann 50 Ct. + eventuelle Spannungsanpassung.
Auf der andern Seite hätte ich bei RS485 ich 10 Ct. Kommunikation + 
Steuerung.

48h Tage, kann ich aber auch nur aktuell abreißen ^^.

Peter D. schrieb:
> In der Praxis ist es aber nicht so einfach. Gerade
> Kommunikationsprobleme treten selten sofort auf. Und wenn dann der Bus
> alle Stunde abkackt, muß man erstmal den Teilnehmer finden, der es
> verursacht hat.

Liegt darin nicht erst der Spaß?
Wenn scheinbar alles läuft und plötzlich alles "brennt", dann den Fehler 
zu suchen, finden und zu beseitigen sehe ich als zufriedenstellende 
Aufgabe an. (Natürlich nicht als Ziel)

Mit freundlichen Grüßen
Marcel

[Tom (Gast)]

Hi Marcel,

Ja, du hast Recht. Ich bekomme auch nur 4 Kanäle zusammen. Aber ich 
dachte, dass es für solche Lichtsteuerungssachen reicht, einfach die 
GPIOs direkt anzusteuern.
Leider geht bei den einfachen Teilen die Ansteuerung der GPIO-Ports über 
DMA nicht. Also hätte ich nach einem neuen Lichtbefehl die PWM Signale 
als zb. 100 32bit Werte vor berechnet und dann timergesteuert an das 
GPIO-BSRR ausgegeben. SW-DMA sozusagen. PWM-Frequenzen von 10kHz sollte 
ausreichen und sich damit problemlos herstellen lassen. (Vorsicht nur 
gefühlt, nicht gerechnet oder probiert ;) ).
Ja, die 5V sind natürlich ein Problem. Also entweder Regler oder 
schauen, ob man doch lieber einen z.B. ATTiny nimmt (gibts auch günstig 
bei aliexprees). Ob es dort mit PWM-Kanälen oder GPIO geht - keine 
Ahnung.

BG, Tom

[Marcel B. (the_s616)]

Ich bedanke mich für alle Antworten und werde nun ein kurzes Resume aus 
den Beiträgen ziehen:

Zur Auswahl stehen im Prinzip drei Möglichkeiten.

1. Möglichkeit CAN
Vorteile:
 Sehr einfach
 Sehr störungssicher
 Hohe Datenraten möglich
Nachteile:
 Relativ Teuer
 Die 250 Teilnehmer lassen sich nur über die Message ID Addressieren.
 (Beim 2. Punkt bin ich mir nicht ganz sicher)

2. Möglichkeit direkte UART Verbindungen.
Vorteile:
 Sehr günstig
 Sehr einfach
 Einfaches DMX ähnliches Protokoll möglich
 Relativ störungssicher
 Adressierung erfolgt automatisch durch Position in der Kette.
Nachteile:
 Zunehmende Latenz, je weiter der Client weg ist.
 Nur realtiv Kurze Verbindungen zwischen den jeweiligen Modulen möglich.
 Rückkanal nur bei geschlossenem Ring möglich.

3. Möglichkeit RS485 via MAX1483
Vorteile:
 Keine Latenzvariation
 Relativ hohe Datenraten
 Sehr große Strecken möglich
Nachteile:
 Kompliziertes Protokoll
 Relativ störanfällig

Sollte ich hier etwas vergessen haben, gerne einfach Antworten und ich 
werde es dann entsprechend aufnehmen.

Damit möchte ich dieses Thema hier auch beenden, da wohl nicht mehr all 
zu viel dazu kommt.
In einem weiteren getrennten Thema werde ich mich dann mit der Hilfe des 
Forums genau mit der LED Steuerung und deren Versorgung befassen um 
anschließend den dazu passenden Controller mit seinen Fähigkeiten zu 
nutzen um den für diesen Controller besten BUS zu wählen.


Zum Schluss möchte ich mich noch mal für alle Hilfreichen Antworten und 
eure Geduld bedanken.

Mit freundlichen Grüßen
Marcel

[Dirk (Gast)]

>Zur Auswahl stehen im Prinzip drei Möglichkeiten.
eigentlich nicht, da die "drei" Möglichkeiten eher eine zufällige 
'Zählung' sind.
Ein kompliziertes Protokoll lässt sich beispielsweise praktisch immer 
implementieren sofern man nicht aufpasst und versehentlich ein fertiges 
'unkompliziertes' nimmt und RS485 via MAX1483 funktioniert auch mit 
unkomplizierten Protokollen.
Vom Prinzip haben wir eine sehr sehr bunte Mischung aus im wesentlichen 
elektrischen bestimmten Eigenschaften und welchen die sich aus der 
Adressierung ergeben zusammen mit unkontrollierten zeitlichen 
Anforderungen beim CAN.
Ich versuche mal ein paar strukturelle Eigenschaften anhand eines leicht 
modifizierten Schichtenmodells der OSI-Religion aus dem letzten 
Jahrtausend sehr sehr grob in Stichpunkten zu schildern (die einzelnen 
Schichten lassen sich nicht wirklich klar abgrenzen, deswegen mit +-5 
Toleranz)
OSI 1 (Spannungen): differenzielle Signale (zwei verdrillte Adern, 
RS485/CAN/DMX) erlauben lange Leitungen praktisch ohne Störungen; die 
letzten Millimeter vom Transceiver werden immer 'konventionell' 
bewältigt. Bei kurzen Entfernungen (direkte UART Verbindungen) reicht 
eine Leitung mit Massebezug.
OSI 2 (Medien/Leitungszugriff): weiter unten ein Beispiel aus einer 
Praxis...
OSI 3 (Adressierung/Link layer):DMX-artig ist die Adresse in der 
Position des Datenpakets kodiert, während die anderen Varianten jeweils 
die Adresse als Datum zusätzlich übertragen.
Daisy-Chain (V2) kann bzw. könnte die Position in der Kette als 
Adresse verwenden, aber auch von 'Start' abzählen und eine 'freie'(nicht 
positionsgebundene) Adresse benutzen.
An ganz vielen Stellen schleicht sich zu dem bekannten Wertebereich 
eines Bytes (0..255) noch ein weiterer Wert (start/brk o.ä.) um einen 
Anfang zu definieren. Wenn man daisy-chain mit 'freier' Adressierung auf 
8-bit realisieren möchte müsste man bspw. einen Wert aus 0..255 für brk 
opfern.
((unkonventionell(nicht weiter geprüft): intern daisy-chain mit 9bit für 
"out-of-band" (Begriff für Informationen die nicht im eigentlichen 
jeweiligen{!}Datenstrom übertragen werden)))
== kurze Zwischenbilanz ==
bei freier Leitung ohne Diskussionen:
Gemeinsamkeiten M1..M3:
- asynchron d.h. der Takt/Zeit wird nicht über die Leitung übertragen. 
Alle Beteiligten müssen auf einem anderen Weg für gleiche Zeiten sorgen 
(Hauptfehlerursache neben komplettem Ausfall wie Stecker vergessen o.ä.) 
Da die Länge bekannt ist wird doch etwas Zeitinformation mit übertragen 
und es gibt damit Möglichkeiten zum nachjustieren aber gedanklich und 
'Normalbetrieb' ist asynchron (ohne Zeit) passender.
- digitale Signale/keine Rauschstrecke d.h. sofern keine kritischen 
Daten übertragen werden (Steuerung Herzschrittmacher o.ä.) oder 
spezielle Ängste aus dem Internet mitübertragen werden müssen, lassen 
sich mit den Daten weltweit Lampen auf Bühnen (DMX) oder ähnliches 
steuern.
- Datenrate hängt von Leitungen bzw. Transceivern, Zeit und den 
beteiligten µC ab
RS485 MAX1483/DMX (elektrisch identisch)  ("250kbps") ==> 25fps 
(ZimmerOS mit 160*6 LED ca. 1000; netto ohne Adressen)
ISL81487: ("up to 5Mbps") ==> 500fps  (8-bit µC könnten in dem Bereich 
disqualifiziert sein)
Bei einem wirklich einfachen Programmmodell und Slaves die nicht 
regelmäßig die Bühne wechseln sondern zumindest im Betrieb an einer 
festen Position bleiben, ließe sich ohne Angst vor falschem leuchten 
selbst mit den MAX1483 eine Latenz 1/25 sek realisieren
Zum Besuch in einer Praxis (OSI 2)
Szene: du (Marcel:M) besuchst Peter (P) in der Praxis aus der er seinen 
Beitrag geschrieben hat und ein Master (MA; je nach Praxis 
Betreuer/Arzt/ o.ä.) 'leitet' die Kommunikation:
== 1. Möglichkeit CAN ==
M:Nachricht_1; P:NACHRICHT_1 MA:NACHRICHT_1!!! -->MA sendet
NACHRICHT_1!!!(MA)
M:Nachricht_1; P:NACHRICHT_1 MA:NACHRICHT_2!!! -->MA sendet
NACHRICHT_2!!!(MA)
M:Nachricht_1; P:NACHRICHT_1 -->P sendet
NACHRICHT_1(P)
...
in der Praxis: "Geraffel" wer am lautesten schreit
== 2. Möglichkeit direkte UART Verbindungen.==
N_1(MA)==>M; N_1(M)==> P; N_1(P)==>MA (N1 vom P,M anfangs 'leer')
N_2(MA)==>M; N_2(M)==> P; N_2(P)==>MA
...
in der Praxis: multiprozess (zuhören/reden gleichzeitig) stille Post, 
ohne Implementierung der für das original Spiel wichtigen Fehler)
== 3. Möglichkeit RS485 via MAX1483 ==
(kein festes Protokoll. Szene aus DMX-RDM mit Stammpatienten)
MA:N_1 (Antworterlaubnis:1) ==>M
M:N_1
MA:N_2 (A:0) ==>M
MA:N_3 (A:0) ==>M
MA:N_4 (A:1) ==>P
P:N_1
.....
in der Praxis: sehr protokollarisch geprägte mündliche Prüfung mit 
mehreren Prüflingen oder Podiumsdiskussion
==> Kompliziert werden Protokolle für Möglichkeit 3 durch fehlende 
Signale die Anfang UND Richtung definieren (bsp. 
256=brk;257=brk-Antwort) UND wenn flexible Datenmengen angefragt werden.
Beim MAX1482 (getrennter Antwortbus)kein Problem solange die Antworten < 
Anfrage bleiben. Bei einem gemeinsamen Bus muss
a) der Master genug Zeit für die Antwort lassen und
b) die Antwort als solche erkennbar sein bsp. durch Adresse:Master
Eine sehr unkompliziertes Protokoll ließe sich basteln wenn von der 
Anwendungsebene OSI 7-8 nicht alle 0..255 benötigt werden und ein Paket 
==> slave mit brk=255 und umgekehrt mit brk=254 definiert werden kann.

Grundsätzlich wird es schwierig falls Gerüchte aus einer Praxis über 
Vorlieben von UART-Protokollen ("werden gerne als Text aufgebaut") mit 
Protokollen außerhalb der betroffenen Praxis verwechselt werden. Am 
OSI-Modell lässt sich das grob nachvollziehen:
Du (OSI 8/ Anwender) möchtest von deinem Sklaven (S)(bei Auskünften tw. 
Diener engl. 'server' genannt) den Zustand der aktuellen Helligkeit 
erfahren, dann könnt ihr auf OSI 7 ein einfaches Textprotokoll bsp. http 
installieren für das es sogar fertige Programme gibt. Dann könnt ihr 
euch auf OSI 7 mit
M->S: GET /LED1 HTTP/1.1
S->M: HTTP/1.1 200 OK
S->M: Content-Type: text/plain
S->M:
S->M:
S->M: 42
unterhalten und du weißt => die LED leuchtet 42
- Anwender: glücklich
- UART-Protokoll (falls beteiligt): Hä? (muss für http aber 7-bit 
Zeichen, für bestimmte Content-typen sogar 8-bit, übertragen können)
- uC Slave: unglücklich, weil Texte interpretieren für µC relativ viel 
Arbeit macht.

kurzes Zwischenergebnis:
a) die Ausgaben die vermutlich durch Kollision mit einem CAN-Bus 
entstanden sind (neben den Vorlieben von UART-Protokollen waren auch 
besondere Leseschwierigkeiten bei Fehlern und - vorsichtig formuliert - 
'spezielle' Problemklassifikationen in der Kollisionsausgabe) fallen 
eher in den Unterhaltungsbereich. Möglichkeit 1 ist für Menschen die mit 
dem CAN-Bus aufgewachsen sind oder einfach gerade einen da haben 
sicherlich praktisch, aber solche Faulheit erzeugt manchmal skurrile 
Fehler und kann Menschen aus einer Praxis berichten lassen die einfach 
keine konkreten Daten kennt.
b) Anforderungen aus OSI 7 (http:7/8bit) müssen von allen(!) 'unteren' 
Schichten erfüllt werden, aber vom Prinzip ließe sich unser 
Textprotokoll http auch über das Internet benutzen sofern OSI 6.. das 
organisieren.
c) wie schon weiter oben von 'unten' (OSI 1) vermutet kommen schnell 
Schichten durcheinander

Für den Anwendungsfall LED ließe sich OSI 7 Binärprotokoll (Anwender 
Marcel kann Software zur Dekodierung entwickeln ==> keine 
Leseschwierigkeit insbesondere bei Fehlern) mit Bus-Protokoll OSI 1-3 
als Gesamtpaket unter Umgehung von OSI 4-6 definieren.
Dann stehen im Prinzip zwei Möglichkeiten für OSI 7 zur Auswahl:
1. Möglichkeit 8-bit Daten/ 256 mögliche Werte je Datum 
Helligkeit/Fehler/Adresse
Vorteile:
- Sehr einfach zu denken
- kompatibel mit 8-bit Denkmustern
Nachteile:
- benötigt 8-bit Busprotokoll
2. Möglichkeit fast 8-bit Daten/ 255 mögliche Werte je Datum (u.a. 
Helligkeit/Fehler/Adresse)
Vorteile:
- erlaubt  Busprotokolle die einen Wert für interne Zwecke benötigen
Nachteile:
- erzeugt Probleme beim 8-bit denken
- u.a. nicht mit http (Content-Type:binary u.ä.)kompatibel

für Möglichkeit 2 aus OSI 7 ergäben sich für OSI 2 +-1 (die geraffel 
Variante mit unkontrollierten Tn aus der CAN-Paxis gemuted)
2.1 Daisy-chain
Vorteile:
- 'volle' Bandbreite da kein Zeitfenster für Rückantwort benötigt wird
- Fehler lokalisierbar (Rest fällt aus)
Nachteile:
- schwerer denkbar
- Mehrbelastung µC
- Rest fällt aus wenn ein Slave ausfällt
- zus. Latenz von (je nach Geschwindigkeit) 0,01sek
2.2 physikalisch gemeinsamer Bus
 Gegenteil von 2.1

für alle Möglichkeiten die Adressierungsmöglichkeiten
x.x.1 Möglichkeit DMX-artig Adressen durch Position im Datenpaket
Vorteile:
- hohe Datenbandbreite
Nachteile:
- könnte ein (real) einfaches Sofwaremodell erzwingen
x.x.2 Adressierung je Datenpaket
Vorteile:
- erlaubt weniger Banbreitenstrafe bei komplizierten Softwaremodellen
- vermutlich etwas einfacher für µC

also grob 8 Möglichkeiten von denen nicht alle unkompliziert sind (bsp. 
1.2.1 gäbe bei freien Adressen Chaos, aber 2.2.x oder 1.2.1. mit festen 
Adressen nicht)

Ein kurzes Resumee: vom Prinzip wird die Nettodatenrate bei den 
aktuellen Möglichkeiten durch die µC und deren Programmierung limitiert 
(460 kbs  sollte mit allen diskutierten µC möglich sein, allerdings mit 
teils sportlichen Kombinationen wg. Soft-PWM und einige bräuchten einen 
Quarz für einen langfristig praktisch störungsfreien Betrieb)
Hauptprobleme dürften psychologischer Natur sein (der Verzicht auf einen 
Wert erzeugt bei einigen Programmierern merkwürdige Nebenwirkungen/ 
unsicheres Leuchten trotz aller Gefahren aus dem Internet/ LED mit 
Anzeigen haben die ohne PC/Smartphone zu erkennen ist/...)
Vermutlich wäre Daisy-Chain die Leistungsfähige Variante auch wenn ich 
mich dabei erwische das abzulehnen (Gehirne funktionieren nicht wirklich 
digital); Gedanklich wäre evtl. DMX+RDM mit 500kbs (statt 250kbs) /960 
Adressen (statt 512) und einer gedanklichen Trennung von Wartungsbetrieb 
(Slave können Fehlerspeicher melden/ Plug'n play spielen aber evtl. 0,1 
sek Latenz haben) und Normalbetrieb (50fps) praktisch wie auf 'normalen' 
Bühnen mit DMX-RDM auch, ein sinnvoller Kompromiss.

Noch ein paar kleine Anmerkungen (LED 'Wahrnehmungen' wären noch mal so 
lang wie dieser Text)
- falls du r+g+b=bunt planst dann könnten 3*rgb(w) Chips statt r*3 
+3*g+3*b deutlich besser sein, da einzelne LED sich optisch nur schwer 
homogenisieren/mischen lassen.
- 3,6 Volt gibt es für <1€ Step-down
- µC-Wahl hat tw. ähnliche psychische Probleme wie Buswahl wenn 32bit 
praktisch das gleiche wie 8bit kosten. Manchmal können 8bit aber durch 
die erzwungenen Beschränkungen vieles vereinfachen,manchmal allerdings 
extrem kompliziert machen.

[Marcel B. (the_s616)]

Vielen Dank Dirk, dass du dir solch eine Mühe gemacht hast, auch wenn 
mir das ISO/OSI Schichtmodell bekannt ist, fand ich deine Erklärung gut 
und leicht verständlich.

Beim Protokoll konnte ich mir zwei Möglichkeiten erdenken.
Eine Adressierung jedes Paketes, zum genauen bestimmen des Zieles.
Hier würde es dann wie Folgt aufgebaut werden:
Für einen einen Zyklus:
8 Bit Startzeichen -> (...) -> 8 Bit Adresse + 96* Bit Daten. (...) -> 8 
Bit Stopzeichen -> Pause*1 -> 8 Bit Startzeichen (...)
Wenn mehrere Clients die selben Daten bekommen, findet eine Gruppierung 
wie folgt statt:
8 Bit Startzeichen -> (...) -> 8 Bit Gruppierung -> 8 Bit Anzahl 
Adressen -> Adressen jeweils 8 Bit -> 96* -> (...) -> 8 Bit Stopzeichen 
-> Pause*1 -> 8 Bit Startzeichen (...)

* Die genaue Bitzahl setzt sich aus 8 Bit Farbe + Benötigte Bits für 
eventuellen Verlauf zusammen. Bei entsprechend hoher Wiederholrate lässt 
sich hier natürlich etwas sparen.

*1 während der Pause können die Clients mit dem Server kommunizieren, 
oder eben nicht. Bei Kommunikation wer das Startzeichen entsprechend 
verzögert.

Bei diesem Protokollaufbau gäbe es eine Variable Zykluszeit, da wenn nur 
ein Client angesprochen wird, auch nur Daten für diesen einen Versendet 
werden müssen und der Zyklus damit abgeschlossen ist.

Das andere Protokoll wäre einfach ein erweitertes DMX Protokoll, nichts 
besonderes.

Der Grund wieso ich 6 einzelne LEDs einsetzen möchte, liegt in der 
erreichbaren Helligkeit.
Auf einer Platine werde ich diese wohl auf etwas mehr als 1,5 * 1,5 cm 
unter bringen können.
Da wird sich der Effekt der Abtrennung hoffentlich noch nicht so stark 
bemerkbar machen, gerade bei Passiver Beleuchtung.
Auf der anderen Seite habe ich so auch eine Standard Bauform und 
Ansteuerung, bei der ich solange die Technischen Daten gleich bleiben 
die LEDs beliebig austauschen kann.
So könnte ich z.B. beim Anwendungsfall "Arbeitslicht" statt R+G+B+W+A+UV 
4 mal W und zwei mal 2 wählen. Je nach Anwendungsfall dann auch nur UV 
oder der gleichen.

Dennoch ein großer Dank an euch alle.

Mit freundlichen Grüßen
Marcel

[Dirk (Gast)]

>auch wenn mir das ISO/OSI Schichtmodell bekannt ist, fand ich deine Erklärung gut 
und leicht verständlich.
ups, das hätte nicht passieren sollen.
Das war eigentlich keine Erklärung des OSI-Modells sondern eine 
_|Verwendung|_ zur Herleitung und Übertragung einer Antwort die genügend 
Fixpunkte hat um entscheidbar zu sein. Und leicht verständlich kann die 
auch nicht gewesen sein, sonst hättest du auf die Daten darauf antworten 
können und nicht mit deiner Bekanntschaft.
Zur Erklärung (hier folgt ein Versuch einer Erklärung): OSI ist 
kommunikationstechnisch praktisch (auch) ein 'vereinbartes' 
Modell/Symbolgruppe ähnlich wie Deutsch/Englisch/Chinesisch zur 
Kodierung. Wenn Menschen über die Gestaltung von technischer 
Kommunikation kommunizieren möchten, dann kann OSI praktisch mit jeder 
Sprache 'darunter' benutzt werden (nach M-OSI evtl. OSI over deutsch 
over latin-char-set over Internet over Ethernet) Formal sehr kompliziert 
aber für OSI-Schreiber bzw. Verabredende einfacher als auf 
ungenaue/undefinierte Bekanntschaften bezugnehmen zu müssen.
Wenn du bsp. OSI 6..1 entwickelst und u.a. innerhalb deiner 
Implementierung
>8 Bit Startzeichen -> (...) -> 8 Bit Adresse + 96* Bit Daten. (...) -> 8 Bit 
Stopzeichen -> Pause*1 -> 8 Bit Startzeichen (...)
verwendest, dann kannst du mir entweder :
OSI 6: Adr:[0..255 -startzeichen(SZ),-endezeichen(EZ)] Daten [0..255 
-SZ,-EZ]
übermitteln und ich schreibe die einfache Anwendung ohne SZ,EZ 
Helligkeitswerte.
oder du gibst
OSI 6: Adressen:8-bit Daten:8-bit
an und ich schreibe die einfache Anwendung mit 8-bit Daten. Deine OSI 
6..1 Implementierung sorgt dann für überraschendes Blinken falls eine 
LED zufällig in der Helligkeit des Startzeichens leuchten soll was  den 
Start einer Übertragung markiert und das nachfolgende Datum zúr Adresse 
und die danach folgenden zu Daten der ungeplanten Adresse werden lässt.
Wenn wir uns dann vor Gericht treffen und der Falsche verurteilt wird 
dann ist der Falsche im Idealfall derjenige der die vereinabrte 
Spezifikation (OSI ist praktisch auch Vertragssprache) nicht eingehalten 
hat (lt. Gerücht manchmal auch der Andere)
OSI kann aber auch als eine Möglichkeit genutzt werden um Fragen zu 
(anderen) Kommunikationsprotokollen herstellen zu können, dadurch das es 
Fixpunkte im Modell  vorschlägt.
Praktisch kann ein handelsüblicher Mensch unter optimalen Bedingungen 
gerade einmal (gemessene) 7 Items verarbeiten, wobei für praktische 
Anwendungen i.A. 2-3 (+ 3 im Hinterkopf )nutzbar sind. Der Rest ist 
entweder vorherige erfolgreiche Itemisierung d.h. bspw. aus 1+2+3+4+5+6 
wurde vorher(!) erfolgreich  6[wg."1+2+3"] +15["4+5+6"] oder gefühlt 
erfolgreich 5["1+2+3"] +15["4+5+6"]  verarbeitet  und dann kann ein 
Mensch bequem 1+2+3+4+5+6= 21 bzw.=20 berechnen und sowohl 6+15=21 als 
auch 5+15=20 sind richtige Ergebnisse.
Problematischerweise fühlen sich gefühlt richtige und andere richtige 
Items genau gleich an und ohne einen externen Schiedsrichter (Richter) 
wären unsere beiden Implentierungen für uns beide jeweils 
Richtig.(NB.:gäbe eine interessante Relativitättheorie in der die 
relative Richtigkeit vom jeweilgen Standpunkt ter abhängt. Beim 
Verarbeiten von 2 'richtigen' Informationen zusammen mit 1 Information, 
nach der zumindest eine der beiden doch unrichtig sein muss, kommt es 
bei Menschen schnell zu einer kognitiven Dissonankatastrophe ähnlich wie 
in der Praxisausgabe nach der CAN-Bus Kollision ("Bus kackt 
ab"/UART-Vorlieben/etc.) praktisch wie bei einer Seekrankheit ( 2 
'richtige' Informationen von Auge/Ohr und eine weitere dass die beiden 
eigentlich gleich sein sollten)
Ich fürchte das dürfte hier passiert sein und deswegen kannst du die 
Antwort (keine Erklärung von OSI)
>>>Gibt es einen passenden BUS zur steuerung vieler Clients über mehrere Meter?
>>2.1 Daisy-chain [vs.RS485]
>>Vorteile:
>>- 'volle' Bandbreite da kein Zeitfenster für Rückantwort benötigt wird
>>- Fehler lokalisierbar (Rest fällt aus)
>>Nachteile:
>>- schwerer denkbar
>>- Mehrbelastung µC
>>- Rest fällt aus wenn ein Slave ausfällt
>>- zus. Latenz von (je nach Geschwindigkeit) 0,01sek
nicht empfangen und glaubst an eine Erklärung zu deiner Bekanntschaft 
mit ISO/OSI.

Ich könnte versuchen anstatt mit OSI das Ergebnis mit anderen Modellen 
oder irgendwie ohne weiteres Protokoll zu übertragen, aber vermutlich 
ist das Ergebnis an sich blockiert (praktisch eine Firewall durch 
Dissonanzkatastrophe)
Rein technisch/finanziell dürfte Daisy-chain die beste Lösung für die 
behaupteten Anforderungen sein.
Klassische Schutzmaßnahmen (ich verwende sehr gerne unstrukturierte 
Baumstrukturen damit daisy-chain gar nicht als Möglichkeit in Betracht 
kommt)fallen weg, aber der entscheidende Nachteil:"schwerer denkbar" ist 
schwer akzeptierbar (auch eine Art Denkbarkeit, hmm)

Also lieber eine Variante 2 (Menschen haben neben OSI noch weiche 
Protokolle):
>>>Gibt es einen passenden BUS zur steuerung vieler Clients über mehrere Meter?
- ES485 ist hinreichend lange ausgedeutet (Standardprotokoll außerhalb 
harter Entscheidungen)und damit der passende Bus
- der Vorschlag evtl.  7,97-bit  für OSI 7 zu definieren erlaubt bei 
ES485 sehr einfach denkbare Protokolle, da ein start/escape zeichen für 
Buszwecke zur Verfügung steht.

Zu den 'Neben'bedingungen des Projekts:
>gerade bei Passiver Beleuchtung (indirekt)
- dann ist der Helligskeitsbereich deutlich(!) weniger wichtig (Sterne 
in der Nacht könnten für indirekte Beleuchtung praktisch gleich hell 
geschaltet werden, haben aber im direkten Sichtfeld eine Dynamik von ca. 
6 Größenordnung)
- auch PWM -Frequenz ist indirekt nicht soo sichtbar (die flackernden 
punktförmigen LED an billigen Blechkisten auf den Straßen sind für 
einige ärgerlich, aber nicht die flächigen)
- UV passiv? kann u.U. witzlos sein
warum 3*r +3*g 3*b (9 led) heller als 3* 3*rgb (9 led) sein soll versteh 
ich nicht, aber wenn Mischung kein Problem ist dann wäre evtl. für rot 
eine 4.te sinnvoll, da rot häufig dunkler erscheint

Projektorganisation :
Prognose:
- es wird Überraschungen beim Treffen mit der  Softwareabteilung geben 
wenn  die versucht die Informationen über den Bus zu erhalten und 
Anzeigen für den Benutzer designt die dieser auch von den LED direkt 
sehen könnte.
- die Softwareabteilung wird die Verärgerung über die Mehrarbeit durch 
die vielen Möglichkeiten aus der Busabteilung nicht offen zu Sprache 
bringen dürfen.
- die versunkenen Kosten in die Denkarbeit für den aufwendigen Bus 
erlauben keine kostengünstige Softwareproduktion. Was implementiert ist 
muss auch genutzt werden, egal um welchen Preis.
- Plug'n Play wird aufgrund der Vielzahl unterschiedlicher Geräte sehr 
einfach, evtl. reicht ein bit um alle Möglichkeiten zu erfassen
- die Qualität des Endprodukts hängt zu 60% an der PC/Smartphonesoftware 
und zu 40% am Lampendesign (wenn der Bus nicht abkackt und einen 
Kurzschluss hat)

Projektleiter:
- handelsüblichen Studenten wird eine Restlaufzeit von teils über 60 
Jahren prognostiziert, während LED o.ä. evtl. mit 15J zu rechnen sind. 
Investitionen in erstere sind praktisch das 4-fache wert.
- je nach Studiengang gibt es evtl. mal ein Modul OR, vielleicht fallen 
ein paar Gemeinsamkeiten auf (vielfach mathematisch vertuscht, aber ...)

Welt:
- die Ähnlichkeiten technischer Kommunikation mit menschlicher lässt 
sich plausibel erklären, wenn die Hintergründe dass Technik von Menschen 
entwickelt wird/wurde bekannt sind. Manchmal werden menschliche 
Protokolle aber auch durch Technikvergleich bewusst, da viele Protokolle 
auf unbewussten Schichten implementiert sind.
- die Helligkeitswahrnehmung (Hauptthema für direktstrahlende LED) ist 
wohl doppeltlogarithmisch (vom Prinzip logarithmisch aber im Kernbereich 
noch einmal anders, also komisch) mit einer Gamma-Funktion kommt das 
manchmal hin, ist aber sehr uneinheitlich.


LG