Moin moin alle miteinander!
Da ich kein großer Freund von Quecksilber bin, sehe ich nun den Punkt
gekommen, an dem es Zeit wird, meine Zimmerbeleuchtung von Wolfram auf
Halbleiter umzustellen, so sieht der Plan aus:
1500 RGB-LEDs, 1500 kaltweiße LEDs, 2000 warmweiße LEDs, alle auf
flexiblen Leisten, jeweils in kleinere Gruppen unterteilt und mittels
PWM (12 Bit) dimmbar.
Als "Dimmer" möchte ich ca. 50 PIC12F1840 nehmen (hab hier noch ne
Kiste voll von denen) und sie über I2C (400 kHz) ansprechen. Ich weiß,
I2C war niemals als Feldbus konzipiert, aber da er ja auch schon
offiziell als Verbindung zwischen TV und Videorekorder genutzt wurde....
Ich habe vor, SCL und SDA über 2 Koaxkabel laufen lassen, deren
Kapazität bei 55 pF/m liegt und da als maximale Leitungslänge meine
Zimmerhöhe (2,4 m) angenommen werden darf, bleibe ich garantiert
innerhalb der spezifizierten 400 pF.
Den Master (noch nicht konzipiert) dann ab in die Mitte und die Pullups
jeweils an die beiden Enden.
Die große gestrichelte Linie im Schaltplan steht für den Platz, an dem
die restlichen Slaves sitzen/hinzugefügt werden können.
Meine erste Frage betrifft den Schirm von SDA & SCL, wie beschalte ich
ihn?
Einseitig oder beidseitig, auf GND oder auf VDD oder mit Spannungsteiler
auf VDD/2?
Hab hier im Forum gegensätzliche Infos gefunden, deswegen...
Außerdem bin ich noch etwas ratlos, ob und wenn ja, wie ich GND Slave
und GND LEDs trenne ohne dabei große Masseschleifen zu basteln, hab die
Sorge, dass der hohe pulsartige Strom der LEDs mir sonst das I2C
versaut. Andererseits müssen die FETs natürlich noch irgendwie
durchsteuern können ^^
Und wie siehts mit den Serienwiderständen vor jedem Slave aus, 330, 100
oder 0 Ohm?
MfG, Quenz
@ Quenz (Gast)
>Da ich kein großer Freund von Quecksilber bin, sehe ich nun den Punkt>gekommen, an dem es Zeit wird, meine Zimmerbeleuchtung von Wolfram auf>Halbleiter umzustellen, so sieht der Plan aus:
Den Teufel mit dem belzebub austreiben?
>1500 RGB-LEDs, 1500 kaltweiße LEDs, 2000 warmweiße LEDs, alle auf>flexiblen Leisten, jeweils in kleinere Gruppen unterteilt und mittels>PWM (12 Bit) dimmbar.
Wohnst du in las Vegas? Oder auf dem Rummel?
>Ich habe vor, SCL und SDA über 2 Koaxkabel laufen lassen, deren>Kapazität bei 55 pF/m liegt und da als maximale Leitungslänge meine>Zimmerhöhe (2,4 m) angenommen werden darf, bleibe ich garantiert>innerhalb der spezifizierten 400 pF.
Es geht auch mehr, dann eben halt langsamer.
>Den Master (noch nicht konzipiert) dann ab in die Mitte und die Pullups>jeweils an die beiden Enden.
Einmal irgendwo reicht. Das Thema Wellenwiderstand greift bei I2C
nicht wirklich.
>Meine erste Frage betrifft den Schirm von SDA & SCL, wie beschalte ich>ihn?
Das ist deine Masse.
>Außerdem bin ich noch etwas ratlos, ob und wenn ja, wie ich GND Slave>und GND LEDs trenne ohne dabei große Masseschleifen zu basteln, hab die>Sorge, dass der hohe pulsartige Strom der LEDs mir sonst das I2C>versaut.
Muss man halt lokal mit Elkos puffern.
>Und wie siehts mit den Serienwiderständen vor jedem Slave aus, 330, 100>oder 0 Ohm?
Gar nicht.
thx @ falk
Du meinst, ich soll die Schirme als einzige Masseverbindung zwischen
Netzteil, LEDs und Slaves nehmen?
@ next
Eigentlich keine schlechte Idee, das Ding ist nur, dass jeder Slave so
klein (und so billig;) wie möglich bleiben muss, da ich sie (wie die
LEDS) in eine Fräsnut in meinen Regalen einsetzen möchte. Mit jedem
zusätzlichen Bauteil verbrauch ich mehr Basismaterial, hab mehr
Lötarbeit und mehr "Hohlraum" in den Regalbrettern...
@ Quenz (Gast)
>Du meinst, ich soll die Schirme als einzige Masseverbindung zwischen>Netzteil, LEDs und Slaves nehmen?
Nein,denn du willst dort ja nicht Zig Ampere drüberschicken. Außerdem
ist das mit den Koaxkabeln nicht sonderlich sinnvoll und praktikabel,
selbst RG174 ist mal ganz fix ziemlich dick, von Steckverbindern ganz zu
schweigen. Das Problem der Masseverschiebung löst man mit gescheiten
Bustreibern, I2C ist dafür denkbar ungeeignet, geht nur in bestimmten
Situationen. Nimm CAN oder RS485, die Kosten für den Tranceiver bringen
dich nicht um.
Hast du schon gedacht wie man die i2c adressierung per platine
unterschiedlicht einstellen kann ?
Ueberlege mal om ein andere protocol zb DMX-512 zu benutzen.
@ Patrick
Jeder Slave (ist ja ein µC) bekommt seine eigene Adresse bei der
Programmierung.
Ich hab mir stundenlang Gedanken übers Protokoll gemacht und hin und her
überlegt, I2C kommt mir deshalb sehr entgegen, weils keine
Außenbeschaltung braucht (insgesamt 2 Widerstände, nicht nennenswert)
und nur 2 IO-Pins verbraucht (der 12F1840 hat nur 6 und 3 davon brauch
ich schon für die RGB-Ansteuerung.
Natürlich ist I2C nicht ganz ohne, aber da ich wiegesagt Koaxkabel mit
55 pF/m benutze und das auch nur 2,5 mm Durchmesser hat, scheint es mir
bisher als die Lösung, die meinen Vorgaben (klein, simpel, billig) am
nächsten kommt.
Achja, Steckverbinder (einfache Stiftleisten) benutz ich nur für die
Energieversorgung, die Koaxkabel werden alle 20 cm "leicht angeknabbert"
und dann mit einem kleinen Stück Litze direkt an die Slaveplatine
gelötet. HF-Steckverbinder wären nicht nur zu groß, sondern auch viel zu
teuer.
Sobald ich halt nen Transciver/Pegelwandler/sonstwas einsetze, wird die
Slaveplatine (n>50) ebenfalls zu groß und zu teuer...
Ich finde es zumindest "ungeschickt", überschüssige Energie an
Widerständen zu vernichten. Wenn das pro 3 LEDs 1 Widerstand ist, dann
sind das immerhin 1667 Widerstände, und wenn jeder mit 1/4 Watt heizt,
ist das die Abwärme eines Baustrahlers...
Quenz schrieb:> 1500 RGB-LEDs, 1500 kaltweiße LEDs, 2000 warmweiße LEDs
Weißt du, wie oft da eine kaputt ist?
Wenn eine einzelne LED eine MTBF von 100000 Stunden hat, dann verreckt
bei dir rechnerisch alle 100000/(3*1500+1500+2000) = 12,5 Stunden eine
LED. Also sorg dafür, dass du die Dinger leicht tauschen kannst... :-o
@ Quenz
Lese Dir mal den Absatz "Verwendung" unter
http://de.wikipedia.org/wiki/I2c durch und lass ihn Dir auf der Zuge
zergehen.
Bist Du wirklich sicher, dass Deine Applikation diesen Anforderungen
entspricht?
Lothar Miller schrieb:> dann verreckt> bei dir rechnerisch alle 100000/(3*1500+1500+2000) = 12,5 Stunden eine> LED.
Was soll das bitte für eine Rechnung sein? Nach deiner Überlegung
erreicht dann genau eine LED die MTBF.
I2C ist zwar nicht die beste Wahl, kann hier aber bedenkenlos benutzt
werden. Ich nehme an, du willst keine super schnelle
Blitzdings-Discobeleuchtung bauen, daher kannst du die Busfrequenz doch
stark verringern und somit Probleme umschiffen. Bei 10kHz benötigst du
grob geschätzt 1/3s für die Übertragung an alle Slaves. Wenn überall die
gleiche Einstellung gemacht werden soll, so kannst du dies über eine
globale Adresse machen, auf die alle Slaves reagieren. Das ACK musst du
dann aber weglassen.
Die Adresse würde ich dynamisch per SW jedes mal neu erzeugen. Ich hätte
jedenfalls keine Lust die SW 50Mal neu zu kompilieren nur weil eine Zahl
ändert...
Ausserdem würde ich für die ganze Sache einen anderen Ansatz wählen.
Warum nicht eine etwas grössere Leiterplatte erstellen, auf der LED
Treiber sitzen, die von einem uC gesteuert werden. Ist doch dem Treiber
wurscht wenn da noch 2m Kabel dazwischen sind. Ausserdem würde ich
schauen, dass möglichst wenig unnötige Verlustleistung entsteht
(Vorwiderstände usw.).
@ Lothar
Der Widerstand und die LEDs sind nur das Ersatzschaltbild für die
flexiblen LED-Leisten, deren Design war nicht meine Idee ;)
Die MTBF-Rechnung halte ich bei nicht überbelasteten LEDs für
vernachlässigbar, zumal mir der Rechenweg ein wenig spanisch vorkommt.
Wieso 3 mal die Gesamtanzahl aller LEDs? Die MTBF parallel
zusammengesetzter Systeme wird doch ganz anders berechnet!? Außerdem
darf man nicht vergessen, dass es eigentlich nie dazu kommen wird, dass
alle LEDs (gleichzeitig) an sind, zum einen wegen der PWM, zum anderen
weil die RGB-Beleuchtung sowieso nicht für den Alltag gedacht ist,
sondern nur nach Bedarf verwendet wird.
@ Jungster
Ich weiß, dass die Idee hart an der Grenze ist, aber ich habe imho
genügend Schutzmaßnahmen getroffen, als dass der Bus laufen sollte. Wie
ganz zu Anfang erwähnt, es gab schon Videorecorder, die über ein
I2C-Kabel mit dem Fernseher verbunden wurden.
Quenz schrieb:> Wie ganz zu Anfang erwähnt, es gab schon Videorecorder, die über ein> I2C-Kabel mit dem Fernseher verbunden wurden.
50 Videorecorder???
@ bestucki
> I2C ist zwar nicht die beste Wahl, kann hier aber bedenkenlos benutzt> werden. Ich nehme an, du willst keine super schnelle> Blitzdings-Discobeleuchtung bauen, daher kannst du die Busfrequenz doch> stark verringern und somit Probleme umschiffen. Bei 10kHz benötigst du> grob geschätzt 1/3s für die Übertragung an alle Slaves. Wenn überall die> gleiche Einstellung gemacht werden soll, so kannst du dies über eine> globale Adresse machen, auf die alle Slaves reagieren. Das ACK musst du> dann aber weglassen.
Sehr richtig, so hab ich auch gedacht :)
Vll mach ich die I2C-Frequenz auch variabel, falls es doch mal einen
Abend Blitzdingsdisko sein soll, muss dann halt schauen, bis zu welcher
Geschwindigkeit der Bus mitmacht ^^
> Die Adresse würde ich dynamisch per SW jedes mal neu erzeugen. Ich hätte> jedenfalls keine Lust die SW 50Mal neu zu kompilieren nur weil eine Zahl> ändert...
Das wäre eine große Arbeitserleichterung, gefällt mir sehr die Idee. Nur
wie mach ich das bzw. woher weiß ich am Ende, welche Slave jetzt welche
Addy hat?
> Ausserdem würde ich für die ganze Sache einen anderen Ansatz wählen.> Warum nicht eine etwas grössere Leiterplatte erstellen, auf der LED> Treiber sitzen, die von einem uC gesteuert werden. Ist doch dem Treiber> wurscht wenn da noch 2m Kabel dazwischen sind. Ausserdem würde ich> schauen, dass möglichst wenig unnötige Verlustleistung entsteht> (Vorwiderstände usw.)
150 mal 12 Bit PWM mit unterschiedlichem DutyCycle?
151 mal ca. 2 Meter ungeschirmtes Kabel auf dem mit 5 - 10 kHz bis zu
1,5 A laufen?
Ich glaube, da hab ich mit I2C weniger Stress ;)
@ Jungster
> Quenz schrieb:>> Wie ganz zu Anfang erwähnt, es gab schon Videorecorder, die über ein>> I2C-Kabel mit dem Fernseher verbunden wurden.>> 50 Videorecorder???
Lustige Vorstellung. Ich denke mal, dass bei 50 Videorecordern die 400
pF-Marke überschritten worden wäre, weils das passende Kabel damals
sicher nur in 0,5 Meter-Stückelungen gab.
@Falk
Huhu, nur so als Idee, wenn's günstig sein soll:
Schau Dir mal den L9637 bei ST an. Es gibt sowas steinstabiles wie
LIN-Bus, da reicht dann für den ganzen Klump ein Dreidrahtsystem.
Damit haben wir schonmal halbe Gebäude vernetzt, bei 24V, 19200 Bd und
Konstantstromquellen für die LEDs. Nur ein Vorwiderstand dürfte doch
etwas schlicht für gleichmäßige Beleuchtung werden.
Wir haben das seinerzeit mit 90S4433, dem antiken Vorgänger des Mega8
aufgebaut, den LIN-Bus hatte ich ausgewählt, weil der kurzschlussfest
und nahezu unzerstörbar ist.
Beste Grüße
Krempel
Hi Quenz,
dass das Kabel keine 400pF hat mag ja noch hinkommen, aber jeder Slave
und dessen Port + Leiterplatte + Stecker + Streukapazität hat schon
mindestens 15pF. Macht bei 50 also schon 750pF + Kabelkapazität. Die
spezifizierten 400pF kannst Du also knicken.
Nachschlag zum Thema Stringdefekt, Ausfall einzelner LEDs in der Kette.
Littlefuse hat eine Bauteilserie PLED 5HT, die schaltet man parallel zu
den LEDs und schon ist der Ausfall einer LED nicht mehr letal für die
Kette.
@ Hans
> Hi Quenz,>> dass das Kabel keine 400pF hat mag ja noch hinkommen, aber jeder Slave> und dessen Port + Leiterplatte + Stecker + Streukapazität hat schon> mindestens 15pF. Macht bei 50 also schon 750pF + Kabelkapazität. Die> spezifizierten 400pF kannst Du also knicken.
Verdammt, nicht bedacht.
Also die Slavekapazität plus Sicherheitsreserve ausrechnen und die 50
Slave mittels "Zwischenmaster" (Bus-Topo --> Baum-Topo) soweit
aufteilen, dass jeder Strecke + Slaves wieder unter 400 pF liegen :/
Quenz schrieb:> Das wäre eine große Arbeitserleichterung, gefällt mir sehr die Idee. Nur> wie mach ich das bzw. woher weiß ich am Ende, welche Slave jetzt welche> Addy hat?
Da du ausschliesslich uCs verwendest, die du selbst programmierst, hast
du den Vorteil, dass du das "Protokoll" selbst definieren kannst. Du
kannst die Adressen auch nur einmal dynamisch erzeugen lassen und dann
im internen EEPROM speichern. Das erste Mal musst du dann einen
"Konfigurationsmodus" aufrufen. Musst du ja so der so, entweder einmal
dynamisch oder einmal statisch im Programmcode.
Alternativ kannst du die Adresse auch einzeln "einbrennen". Dabei ist
immer nur ein Slave mit einer Standardadresse (im Programmcode
definiert) am Bus und der Master sendet diesem die neue Adresse, die
dann im internen EEPROM abgelegt wird. z.B. über einen Taster kannst du
dann den Master forcieren nach einem neuen Slave zu suchen.
Adresse eim eeprom is ne gute Idee.
Beim flashen wird auch das eepromfile mit übertragen in dem immer mitm
editor ne neue Zahl eintippen bevor man den nächsten PIC nimmt.
Falls du das von Hand löten willst:
Ich habe mal ne Schaltung mit über 500 LEDs und entsprechend vielen
Vorwiderständen gelötet. Das ist eine Heidenarbeit!
Martin Wende schrieb:> Adresse eim eeprom is ne gute Idee.> Beim flashen wird auch das eepromfile mit übertragen in dem immer mitm> editor ne neue Zahl eintippen bevor man den nächsten PIC nimmt.
Danke für diesen großartigen Tip :)
Wie willst du eine drei-kanalige 12-bit PWM mit EINEM hardware 10-bit
PWM Modul realisieren? In Software?
Aber ich denke eine 8-bit Auflösung sollte für eine Beleuchtung auch
ausreichen. Die ist dann einfach in Software zu machen und verringert
auch den Datenverkehr auf dem Bus.
Hab mir mal das Datenblatt vom PIC12F1840 genauer angeguckt, 50 pF
allein für den Slave-Pin, Mist...
Aber mir ist eine Methode eingefallen, wie man das ganze retten kann ^^
Da die Slaves vom Bus sowieso nur Farb-, Dimm- und andere Steuerbefehle
übernehmen sollen, spricht nichts dagegen, diesen unidirektional
auszulegen; ich verzichte einfach aufs Acknowledge und puffer den Bus
masterseitig! Außerdem vergrößere ich den Störabstand, indem ich die
Bus-Spannung auf 24V erhöhe und diese mittels Spannungsteiler vor jedem
Slave wieder auf TTL-Level bringe. 4 x 0603 Widerstände entspricht
meinem Verständnis von klein, billig und simpel ^^
Irgendwer irgendwelche Einwände?
> Wie willst du eine drei-kanalige 12-bit PWM mit EINEM hardware 10-bit> PWM Modul realisieren? In Software?
Vergiss das PWM-Modul, die linearen 12 Bit vom I2C soll die SW per
lookup table in einen 16-bit Wert umsetzen, welcher der bereits
erwähnten Helligkeitskurve entspricht. Dieser 16-bit Wert wird dann als
Compare für Timer1 benutzt. Nach jedem Interrupt wird des Compare mit
gestoptem Timer auf die nächste Farbe geupdatet.
Dann nimm aber nicht mehr den I2C sondern einen (Software)UART.
Dann brauchste sogar nur einen Datenpin.
Außerdem kannste nen nrmalen Mosfettreiber nehemn, der hat auch schon
genug Power um die Leitung zu treiben.
Martin Wende schrieb:> Dann nimm aber nicht mehr den I2C sondern einen (Software)UART.> Dann brauchste sogar nur einen Datenpin.
Dann muss aber per Software die Taktfrequenz vom Master und der Slaves
abgeglichen werden (ich nehme an, du benutzt den internen
RC-Oszillator).
Ausserdem würde ich auch einen Treiberbaustein verwenden. Bei deiner
Lösung werden, wenn auch nur kurz, deine 24V kurzgeschlossen.
Quenz schrieb:> Außerdem vergrößere ich den Störabstand, indem ich die> Bus-Spannung auf 24V erhöhe und diese mittels Spannungsteiler vor jedem> Slave wieder auf TTL-Level bringe. 4 x 0603 Widerstände entspricht> meinem Verständnis von klein, billig und simpel ^^
Hört sich für mich eher nach "Murks" und "Gebastel" an... :-/
> Irgendwer irgendwelche Einwände?
I2C unidirektional? Wofür dann das ACKnowledge?
Nimm RS485 oder besser RS422. Das ist z.B. in der kommerziellen
Lichttechnik als DMX512 bekannt und kampferprobt, braucht auch nur 2
verdrillte Leitungen und hat wegen der symmetrischen Übertragung eine
ausgezeichnete Störfestigkeit. Mit DMX512 könntest du z.B. auch Tests
mit einem käuflichen Controller machen, oder dein System um eine
kommerzielle Lampe erweitern...
Und richtig: die Ausfallswahrscheinlichkeit ist niedriger, allerdings
weiß ich einige LED-Strahler aus der Lichttechnik (Lichterketten, PAR56
und PAR64), wo ein LED-Defekt die Hauptausfallsursache ist. Ich würde
also eine einfache Tauschmöglichkeit der LEDs einplanen...
Ralf schrieb:> Wenn du unbedingt bei I2C bleiben willst könnte dir noch ein P82B715 I2C> Bus extender helfen...>> Ralf
Davon kann ich nur abraten.
Wenn schon I2C dann wenigstens P82B96.
Allerdings rate ich in diesem Zusammenhang immer noch von I2C insgesamt
ab.
Das ist für diese Applikation einfach zu empfindlich.
Gruß
Moin moin,
die Aufgabe ist sicher interessant, aber sonnvoll?
Bei gut 400W Verlustleistung macht der Wolframdraht doch die bessere
Figur. 6 60W-Lämpchen sind vermutlich gemütlicher und auch nicht
verschwenderischer, und sie machen auch noch Licht dabei. ;-)
Zumal unter ökologischem Gesichtspunkt 5000 LEDs + anderer
Halbleiterkram gegen die 6 Glühlampen nicht sonderlich glorreich
dastehen.
VG
Steffen
>>Gesichtspunkt 5000 LEDs + anderer Halbleiterkram gegen die 6 Glühlampen
ich verstehe nicht wie man das ins Verhältnis setzen kann, 5000 RGB
Leuchtdiodens und 6 Glühlampen, was haben die gemein außer das sie Licht
erzeugen?
MM
Hallo MM,
meiner bescheidenen Meinung nach verursacht die Herstellung von 5000
LEDs mehr Sondermüll und Giftstoffe (Abprodukte der
Halbleiterindustrie) als 6 Glühlampen.
Aber wie so oft im Leben kann ich mich auch irren. Beweisen kann ich es
eh nicht. ;-)
VG
Steffen
Achtung: Es geht hier nicht um 6 Glühlampen vs. 5000 LEDs
Die Leistung von 400W war nur die Verlustleistung, die ich anhand der
zuerst geposteten Schaltung bei 5000 LEDs maximal prophezeit habe. Bitte
nicht jede dahingerotzte Zahl als Stand der Technik annehmen...
Ich weiss. Mir ging es darum auch darauf hinzuweisen, dass nicht alles
sinnvoll ist, was machbar ist.
Vor allem in Zeiten des ungebremsten "Wachstums" und der Verschwendung.
Aber, ich will damit keinen Flamewar entfachen. ;-)
Und es geht natürlich nicht um 5000 LEDs - 6 Glühlampen, sondern um 5000
LEDs mit Vordiderstand - 6 Glühlampen.
Wobei die 5000 LEDs auch eine Leistung benötigen. aber das kann ich
natürlich hier so nicht abschätzen.
VG
> Und es geht natürlich nicht um 5000 LEDs - 6 Glühlampen, sondern um 5000> LEDs mit Vordiderstand - 6 Glühlampen.
Flexible (RGB-)LED-Streifen (alle 5 cm teilbar) ohne Vorwiderstand? Wird
sowas überhaupt hergestellt? Ich zerschredder doch nicht haufenweise
Europlatinen, um mir daraus eigene (starre) Leisten mit KSQ statt
Vorwiderstand zu basteln, wir reden hier von etlichen Metern...
Achja, ich war zu Anfang bei der Mengenangabe der LEDs etwas unpräzise,
es sollen nicht 1500 RGB-LEDs werden, es sollen 500 werden, ich hatte
noch die Zahl der Dies im Kopf, deswegen...
Die 2000 warmweißen LEDs werden die Hauptarbeit leisten, während RGB und
kaltweiß für Sonderzwecke vorgesehen sind und somit für den tagtäglichen
Energieverbrauch keine Rolle spielen.
@Quenz,
das ist ein sehr schöner Beitrag von dir, klasse wie du auf Vorschläge
eingehst. Offensichtlich hast du dich ja schon entschieden - ich bin weg
- viel Erfolg.
RGB LED und Glühlampen lassen sich nicht vergleichen da sie völlig
unterschiedliche Möglichkeiten bieten. Man kann nicht schreiben "ob es
sinnvoll wäre" da die Leuchtmittel völlig unterschiedliche Möglichkeiten
bieten - mehr wollte ich nicht sagen.
Das wäre so als würde ich schreiben, hmm ob es sinvoll wäre einen
Ferrari gegen einen Polo zu tauschen wenn der kaputt gegangen ist. Es
fehlen zu viele Angaben um das zu bewerten, auch von der Umweltbelastung
her. Wenn der Ferrari von einer Wohngemeinschaft mit 20 Personen
angeschafft wird um gemeinsam jeden Tag mit einem Anhänger voller
Menschen zur Abreit zu fahren, und der Polo das von der Leistung her nie
geschafft hätte.... Es hängt von den Randparametern und Gründen ab, die
NICHT weiter genannt werden und um die es hier wirklich überhaupt nicht
geht.
MM
Maddin schrieb:> das ist ein sehr schöner Beitrag von dir, klasse wie du auf Vorschläge> eingehst. Offensichtlich hast du dich ja schon entschieden - ich bin weg> - viel Erfolg.
Eher andersrum. Die Vorgabe ist, dass slaveseitig kein Pegelwandler
eingesetzt wird, aber in den meisten Vorschläge wird das ignoriert.
Stattdessen diskutieren wir über LED-Vorwiderstände...
Der PIC12F1840 kann ja schon mehr als die Standard 3mA an seinen IO
Ports (und somit I²C) ziehen. Daher könntest du auch die I²C Pull-Ups
kleiner machen (was den Kapazitätsproblemen entgegenwirkt).
Quenz schrieb:> Die Vorgabe ist, dass slaveseitig kein Pegelwandler> eingesetzt wird, aber in den meisten Vorschläge wird das ignoriert.
Die Eigenschaften des Busses (siehe meinen Link im Beitrag oben)
scheinen Dich nicht zu interessieren. Dieser Bus ist für die
Signalübertragung zwischen Komponenten auf einer Platine konzipiert und
nicht als Hausbus. Entweder wird Du bei Deiner Applikation einen sehr
hohen Aufwand (= unnötig teuer) bei der Spannungsversorgung treiben
müssen oder Du kannst sehr interessante Effekte erleben, die durch
Potentialverschleppungen entstehen.
Quenz schrieb:> Die Vorgabe ist, dass slaveseitig kein Pegelwandler> eingesetzt wird, aber in den meisten Vorschläge wird das ignoriert.
Ja, weil es einfach keinen Sinn macht, auf die 30 Cent für einen
RS422-Wandler zu verzichten. Und auf einem Bus rumzuhocken, der für
"Inter-Integrated-Circiut" Verbindungen (also auf Leiterplattenebene mit
50cm Länge) entwickelt wurde.
> Stattdessen diskutieren wir über LED-Vorwiderstände...
Es ist dein Thread (alternativ: deine Sitzung, deine Besprechung).
Da bist du selber in der Moderatorenrolle und solltest sachlich dafür
sorgen, dass das nicht ausufert! Oder sehe ich das falsch?
Wie immer, kaum wird ein I2C Bus über mehr als 5cm vorgeschlagen, schon
machen sich alle in die Hose :)
Halten wir mal fest: I2C über 2,5m ist absolut kein Problem. Zumindest
wenn man ihn nicht mit 1MHz fahren will.
Eine eigene Masse für den LED Strom hat er ja auch schon vorgesehen.
Probleme dadurch sollten sich also auch in Grenzen halten.
Jörg S. schrieb:> Eine eigene Masse für den LED Strom
Die Massen sind aber offensichtlich nicht potentialgetrennt. Damit kann
sich der Strom (mit allen Störsignalen) aussuchen, über welche Masse er
fließt. Wieso meinst Du, dass das gut funktionieren soll?
>Die Massen sind aber offensichtlich nicht potentialgetrennt.
Soweit ich die Schaltung richtig interpretiere sind sie aber auf den LED
Platinen getrennt.
Jörg S. schrieb:> Wie immer, kaum wird ein I2C Bus über mehr als 5cm vorgeschlagen, schon> machen sich alle in die Hose :)
Das ist so nicht richtig.
Ich verwende bei meiner Haussteuerung sehr viele Komponenten, die über
I2C angeschlossen sind. Und auch ich bewege mich dabei weit außerhalb
der Spezifikation. Mit den entsprechenden Folgen. Ich musste daher
einigen Aufwand treiben, um noch eine zuverlässige Kommunikation zu
gewährleisten. Obendrein wird hier durch die PWM-Steuerung der Module
noch ein erhebliches Störpotenital vorhanden sein. Ich prophezeihe daher
aus eigener Erfahrung, dass dies so einfach nicht dauerhaft
funktionieren wird.
Die Komponenten die ich über RS485 angeschlossen und übers ganze Haus
verteilt habe, funktionieren dagegen absolut unauffällig.
Gruß
Jörg S. schrieb:> Halten wir mal fest: I2C über 2,5m ist absolut kein Problem.> Zumindest wenn man ihn nicht mit 1MHz fahren will.
Und wenn keine Störer unterwegs sind, und wenn die Masseverbindung
passt, wenn keine Potentialverschiebungen durch die zwei "Massen"
auftreten, und, und, und...
Das wären mir einfach schon aus Prinzip zu viele Unwägbarkeiten. Und
zumindest ich will ja nicht jedem Tag dem Zeug hinterherrennen, weil
irgendwas wieder nicht tut wie es soll.
Lothar Miller schrieb:>> 1500 RGB-LEDs, 1500 kaltweiße LEDs, 2000 warmweiße LEDs> Weißt du, wie oft da eine kaputt ist?> Wenn eine einzelne LED eine MTBF von 100000 Stunden hat, dann verreckt> bei dir rechnerisch alle 100000/(3*1500+1500+2000) = 12,5 Stunden eine> LED. Also sorg dafür, dass du die Dinger leicht tauschen kannst... :-o
Das ist schlechtweg falsch. Aber leicht tauschen sollte man sie schon
könnnen...
Lothar Miller schrieb:> weil irgendwas wieder nicht tut wie es soll.
Da geht dann der WAF dramatisch nach unten.
Und das bei der Wohnzimmerbeleuchtung!!!
Aber wer nicht hören will ...
Gruß
I2c2.png
(12 KB)
