Hallo,


um meine Wohnung etwas aufzuhübschen plane ich den Einsatz
leistungsarmer (keine Luxeon) LEDs für eine Art Background-Beleuchtung.

Die Anzahl der LEDs soll < 64 sein und Standardtypen (20mA, 2 - 3,5V
Flussspannung) werden wohl reichen.

Eigentlich möchte ich vermeiden, zu jeder LED einen separaten Draht zu
ziehen um diese einzeln ansteuern zu können.

Meine Idee:

Ich spendiere jeder LED einen ATTiny und komme so mit 3 Leitungen aus
(wie eine Art Lichterkette mit einzeln ansteuerbaren Lämpchen).
-> Vcc
-> GND
-> BUS

Über die Bus-Leitung würde ich die Tinys mittels eines Masterprozessors
ansprechen (LED an, LED aus, LED Lichtstärke, ...).

Hat jemand bereits einmal etwas ähnliches realisiert?
Wie kann man das Vorhaben mit minimalem Bauteileaufwand realisieren?
Wie könnte man den Bus am einfachsten umsetzen (physical layer)?

Ich bin in der Lage Leiterplatten zu ätzen, zu bestücken sowie die
Controller in C/C++ zu programmieren - daran wird es nicht hängen ;-)


Gruß,
Alex

mit einem mc an jeder led könntest du jeweils dateneingänge an
datenausgänge hängen und so das signal immer schön neu aufbereiten.
das würde "unendlich weit" funktionieren wenn zwischen den einzelnen
stationen die länge nicht zuuuuu groß wird.

dei daten solltest du schön langsam mit nur geringer baud/schrittrate
senden.

dann denke dir ein einfaches protokoll aus, etwa
jede led/mc bekommt eine eigene feste adresse
Mit dem master adressierst du dann die einzelnen leds und gibst ihnen
noch zusätzlich helligkeitsinformationen mit, welcher der mc dann per
pwm umsetzt.

Startbyte| Adresse | Helligkeitswert | Stopbyte

das ganze sendest du permanent.

So etwas ist sehr leicht zu programmieren und umzusetzen, soweit du
alles erst einmal auf einem schönen leeren blatt papier entwickelst und
dann erst ans löten und tippen gehst ;-).

Hi Alex,
hab was ähnliches schon mal gemacht.
Hab aber nur max. 6 Abnehmer und max. 5m Leitung.
In der ersten Version hatten ich mal einen 74HCT14 als Ausgangstreiber
verwendet. Hatte dann Anstiegszeiten von >1µs pro Flanke bis ich auf
einem vernünftigem Pegel war. Bei einem sehr langsamem Timing bekommt
man es dann schon irgendwie hin. War aber nicht befriedigend.
Ich geh mal davon aus Du mit 64 Abnehmern noch langsamere Flanken
bekommst.

Hab die ganze Geschichte mittlerweiler mit RS485 gelöst. Funktioniert
soweit ganz gut. Setzte allerdings ATMegas ein, so dass ich eine UART
habe. Sollte Dein ATTiny keine UART haben, kannst Du ja auch eine
Software-UART implementieren. Bei RS485 Treibern kannst Du die
Std.Bauteile nur mit max.32 Nodes am Bus betreiben. Aber es gibt
Bausteine, die bis zu 256 Nodes erlauben.

Jeder ATMega hat bei mir eine eigene Adresse ( 1..255 ). Die schick ich
bei jedem Kommando mit raus. Darüber kann ich dann die ATMega einzeln
ansprechen.

Ich hatte übrigens auch einige Probleme mit dem Spannungsabfall über die
Leitung ( Flachbandleitung mit 0.014mm² ). Teilweise hat mir die BOD
beim Einschalten meiner Verbraucher den Prozessor resetet.

Markus

Für sowas würde sich auch diese Protokoll gut eignen:
http://www.hth.com/snap/

Mit einem Tiny pro LED geht das schon. Aufbereiten des Signals würde ich
schon machen, also jeweils einen Dateneingang und einen Datenausgang am
Tiny vorsehen, an den wiederum der nächste Dateneingang anzuschließen
ist. An jedem Dateneingang sollte der Datenbus mit 10k nach Masse
terminiert werden. Unbedingt nötig ist ein Elko von mindestens 100µF und
eine Keramikpille direkt am Tiny, die Spannungseinbrüche vermindern. Der
Spannungsabfall über der Gesamtleitung könnte abgefangen werden, wenn
man die Betriebsspannung etwas höher wählt und jedem Tiny-LED-Gespann
noch einen Low-Drop-Festspannungsregler mit gibt.

Hallo,


erstmal danke für euer Feedback.

Aktuell plane ich mit 12V Betriebsspannung, so dass ein Regler pro Tiny
fällig ist. Da so ein Controller < 1 mA bei 1 MHz (interner RC-Oszi)
braucht sollte die verheizte Leistung egal sein.

Aus dem stegreif hätte ich alle Controller mit einer Art Stichleitung
auf den Bus gehangen - euren Kommentaren zufolge wohl eher nicht so gut
:-)

Ich werde mir einmal überlegen, was ein daisy-chaining bedeutet. Für das
verteilen der Adressen ist es auf jeden Fall praktisch, weil der Master
die Adressen dann erst nach dem Einschalten verteilt und alle Slaves
identischen Binärcode haben können. Konzept: Master sendet "set address
xyz" und erster Slave der noch nicht konfiguriert ist nimmt die Adresse
und sendet ACK. Das macht der Master solange, bis kein ACK mehr kommt,
dann haben alle Slaves eine Adresse.

Als Baudrate genügt denke ich < 1 kBaud, ich möchte ja keine Lichtorgel
bauen :)

Der Bus sollte allerdings schon bidirektional funktionieren,
Kollisionserkennung ist aber nicht nötig. So können die Slaves melden
wenn ein Cmd erfolgreich empfangen wurde, macht das Debuggen denke ich
einfacher und man könnte die Software variabler gestalten.

Eine RS485 Transceiver je Node möchte ich aus Kostengründen eher
vermeiden. Eigentlich sollte es doch ein simpler Pull-Up gegen Vcc 5V
(hat doch ein Tiny intern) machen.


Gruß,
Alex

Wenn Du einen bidirektionalen Bus brauchst, dann ist das DaisyChaining
ehrer ungeeignet, weil recht aufwändig. In dem Fall sollte der DatenBus
in der Tat eine druchgehende Leitung sein und recht niederohmig
ausgeführt werden. Spendiere jedem Tiny einen Pullup, nimm einen
externen von maximal 10k, die internen sind zu hochohmig. Als Bustreiber
verwende npn Transistoren, die den Bus nach Masse ziehen können. Auf die
Weise kann jedes Modul senden und empfangen. Im Idle-Zustand ist Deine
Busleitung dann high. 12V als Betriebsspannung sind aber etwas hoch für
Controller, die mit 5V laufen. Im eingeschalteten Zustand der LED mußt
Du dann bereits 140mW an Wärme abführen, für einen kleinen Linearregler
schon unnötig viel. 7-9V sollten auch reichen.

Zur Spannungsversorgung hab ich letztendlich ein Schaltznetzteil
verwendet, was ich einfach auf 5,6V im Leerlauf gedreht hab und ein
Kabel mit entsprechendem Querschnitt. Hab dann immer noch um die
4.5-4.8V an den Controllern und spar mir somit die U-Regler.

Was spricht denn gegen 24V auf der Leitung und jeweils einen MC34063A
fuer 22cts, plus etwas Huehnerfutter ?

Hi,


die 12V hatte ich angesetzt, damit jeder Tiny je 3 gleichartige LEDs
(Serienschaltung) ansteuern kann (geschalten über einen npn Transistor
gegen Masse), um etwas mehr Lichtstrom je Node zu erhalten.

Wie ist das mit dem npn-Transistor als Bustreiber zu verstehen?

Ich klemme eine Serienschaltung von Pull-Up und Transistor zwischen Vcc
(5V) und GND. Zwischen Pull-Up und Transistor liegt das Potential der
Busleitung. Dort klemme ich einen als Eingang geschaltenen IO-Pin der
Tiny an. An die Transistorbasis kommt ein als Ausgang geschaltener Pin.

Korrekt?


Gruß,
Alex

>An die Transistorbasis kommt ein als Ausgang geschaltener Pin.

>Korrekt?

Mit Vorwiderstand, sonst korrekt.


Ich würde allerdings die Busleitung nicht direkt an den µC legen,  ich
würde ein Angstgatter dazwischen legen. Einfach um eine (kleine)
Trennung zwischen Kabel und µC zu erreichen.

"Angstgatter"

Zu welchem Zweck und von welchem Type, sorry, habe da nicht so die
Erfahrung ....


Alex

Ein einfacher Widerstand von der Busleitung zum Controllereingangspin
reicht, Wert von 2.2kOhm-4.7kOhm. Den Transistorkollektor kann man mit
270 Ohm an die Busleitung anschließen, dann hat man auch für den
Transistor einen Kurzschlußschutz.

Hallo,


ich habe mal ein bischen in Eagle rumexperimentiert, vielleicht hat ja
jemand von euch eine Meinung zur entstandenen Schaltung.

Am liebsten würde ich die 2K auf BUS_IN jedoch wieder entfernen. Ich
versuche den Hühnerfutteranteil gering zu halten, da ich den ganzen Kram
ja dann x-mal löten darf ... :-)

Gleichzeitig soll die Platinengröße der Slaves natürlich minimiert
werden, damit diese besser verbastelt werden können.


Alex

Sieht gut aus die Schaltung.
R3 kann 4k7 sein. Eine Programmierschnittstelle in Form eines kleinen
5-pol. Steckers / Buchsenleiste würde ich noch vorsehen. An IC2 muß von
5V nach Masse 10µF, C2 sollte nicht kleiner 100µ sein, der
100n-Kondensator muß direkt an den Controller.


>Am liebsten würde ich die 2K auf BUS_IN jedoch wieder entfernen. Ich
>versuche den Hühnerfutteranteil gering zu halten, da ich den ganzen Kram
>ja dann x-mal löten darf ... :-)

Najaa - nach einem gnügend starken Spannungspuls auf Deiner Busleitung
darfst Du sehr viele Controller neulöten, wenn Du auf diesen einen
Widerstand verzichten willst. Du darfst auch nicht vergessen, daß sehr
lange Leitungen für Fremdinduktion empfänglich sind.

Travel Rec. wrote:

> Eine Programmierschnittstelle in Form eines kleinen
> 5-pol. Steckers / Buchsenleiste würde ich noch vorsehen.

Beim Prototyp evtl. sinnvoll. Ansonsten sollte es der Dannegger'sche
Bootloader auch tun, und der erspart den separaten Stecker.

Wenn du den R4 weglässt, und den R6 in zw Emitter T2 und Masse legst,
hast du gleich eine feine Konstantstromquelle für die LEDs.

Iled = 4,4V/R6

PS: BC847 ist der SMD Typ den 547

Der Bootloader setzt soweit ich weiß einen UART voraus, somit wird das
wohl hier nichts. Aktuell plane ich Fassungen für die Tinys (DIL
Gehäuse) zu nehmen, so dass ich sie auf einem Dummy-Board programmiere
und dann auf die Platine setze.

Die Rolle der 10µ auf der Sekundärseite des Spannungswandlers ist mir
nicht ganz klar. Laut Datenblatt des 78L05 (TO92 Gehäuse) wird keine
weitere externe Beschaltung benötigt. Energie puffert bereits der Elko
auf der Primärseite, wozu also das zusätzliche C?


Gruß,
Alex

@MatthiasL

Wie kommst du auf die 4,4 V?

Was außer dem Emitterwiderstand begrenzt dann noch den Strom, den der
Controller in die Basis hineinschickt? Wenn ich deine Formel für 20 mA
If nehme komme ich auf ein R von 220 Ohm. Der Basisstrom sollte etwa
(5V-0.7V)/220 = ca. 20 mA sein. Soviel braucht es doch eigentlich nicht,
um den Transistor durchzuschalten.


Alex

>Was außer dem Emitterwiderstand begrenzt dann noch den Strom, den der
>Controller in die Basis hineinschickt?

Der Transistor begrenzt sich selbst. Es fließt nur soviel Basisstrom,
wie nötig ist, um den (von dir) eingestellten Kollektorstrom fließen zu
lassen.
Das nennt sich Stromgegenkopplung.


>Wie kommst du auf die 4,4 V?

Erfahrungswert für diesen Transistor: Ube=0,6V, bei 5V =>
Betriebsspannung ergibt das 4,4V über R6


>Der Basisstrom sollte etwa
>(5V-0.7V)/220 = ca. 20 mA sein. Soviel braucht es doch eigentlich nicht,
>um den Transistor durchzuschalten.

Nein. Das ist der Emitterstrom, den du einstellst. Da der BC547 ein B
von sagen wir mal 100 hat, bedeutet das, dass 20mA/100=200µA in die
Basis fließen (müssen). Somit ist der Kollektorstrom (gleich LEDstrom)
20mA-200µA=19,8mA.

Würde mehr Basisstrom fließen, dann fließt mehr Kollektorstrom. Dadurch
steigt die Spannung über besagtem WIderstand. Die Spannung zwischen
Basis(5V) und Emitter sinkt => Basisstrom sinkt...

(Ist eine Art Regelkreis)


Der größte Vorteil dieser Schaltung ist:
Der Transistor kann nicht in die Sättigung geraten, was beim schnellen
Schalten (PWM) durchaus zu beachten ist..

Durch den Emitterwiderstand fließt ja auch der Kollektorstrom, womit der
Basisstrom geringer wird. Ist eine Standardschaltung für eine
Stromquelle. Macht hier Sinn, weil Spannungsschwankungen dann sich wenig
auswirken.

10 uF brauchst du ausgangsseitig am 7805 nicht unbedingt, 100nF in der
Nähe des 7805 reichen auch. Wenn der Controller nahe beim 7805 liegt,
reicht auch nur ein 100nF direkt am Controller (nahe=2-3cm
Leitungslänge).

Alexander wrote:

> Der Bootloader setzt soweit ich weiß einen UART voraus

Nein.

Hallo,


dann mal ein leicht modifizierter Vorschlag mit den angeregten
Änderungen.

Eventuell werde ich wohl noch T1, R3 und R5 rausnehmen. Der Tiny kann
laut Datenblatt 40 mA an einem IO-Pin ab. Der Pull-Up gegen Vcc für die
Busleitung bringt für jeden Slave 0.5 mA (5V/10K), bei max. 64 Slaves
sind das 32 mA, das sollte also passen.

Was das für die Störsicherheit bedeutet muss ich mal sehen, nachstellen
kann man es wohl erst wenn alles zusammengebaut ist. Bei Verwendung des
Daisy-Chain Konzepts würde sich ja die wirksame Buslänge reduzieren
(bspw. < 1m je Leitungsabschnitt).


Vielen Dank nochmal für eure hilfreichen Beiträge,
Alex

... und der Anhang

R3 weg und T1 durch einen BS170 ersetzen.
Kann man bei diesen Tinys nicht den Reset-Eingang wegschalten und einen
I/O-Pin draus machen ? Würde Teile und Probleme sparen.
T2 kann man durch einen BS170 ersetzen, das würde aber nicht wirklich
was bringen.
Wozu R5 ? Überspannungsimpulse ?
R2 und R5 weg und einen internen Pull-Up nutzen. Wenn den alle uCs
aktiviert haben, sollte das ja dicke reichen.
Ich würde sogar den T1 weglassen und notfalls ein paar Portpins parallel
schalten und zwischen Eingang und Ausgang umschalten. Da kann man ja
nichts falsch machen, weil nur Pull-Ups und Push-Pull-Ausgänge nur gegen
Masse.

Bernd: ich denke, Deine Vorschläge sind kontraproduktiv.

Hallo,

das klingt ja nach einem interessanten Projekt.
Noch ein Vorschlag:

Ich würde zum einen alle Bauteile, vor allem Transistoren (=BC847) und
Attinys in SMD ausführen. Für den Attiny bräuchtest du dann natürlich
entweder einen Bootloader oder eine kleine Sockelleiste.
So ersparst du dir bei jeder einzelnen Platine die Bohrungen, was ja
schon alleine für den Attiny + Transistoren bei 64 Bus-Teilnehmern 896
Bohrungen sind...

Ansonsten sieht deine Schaltung gut aus!

Schöne Grüße,
Alex

Travel Rec. wrote:
> Bernd: ich denke, Deine Vorschläge sind kontraproduktiv.

Wahrscheinlich denken das aber nicht alle hier - vor allem der
Threadöffner spricht immer wieder davon, die Platine zu minimieren, das
Hühnerfutter zu vermeiden etc.
Mit welchem meiner Vorschläge hast Du denn das Problem ?

>Mit welchem meiner Vorschläge hast Du denn das Problem ?

Den Eingangsschutzwiderstand wegzulassen und die Transistoren ohne
Basisvorwiderstände zu betreiben. Auch MOSFETs sollten einen kleinen
Gatewiderstand haben, schon gerade dann, wenn man mit PWM arbeiten will.
Es nützt nichts, an der falschen Stelle zu sparen und dabei die
Schaltungssicherheit zu gefährden. Das Hühnerfutter gibt es auch sehr
klein, in SMD 0603 zum Beispiel, dann ist der Controller das größte
Bauteil, under das alles andere (außer dem Regler, den LEDs und den
Elkos) darunter paßt. Auch Transistoren gibt es in SMD.

Was das mit der Adressierung angeht: Hier noch ein mögliches Verfahren,
das keinen bidirektionalen Bus braucht:

Du verbindest alle Knoten (einschließlich Master) folgendermaßen:

[Knoten]     [Knoten]     [Knoten]
[-ein  ]  +--[-ein  ]  +--[-ein  ]
[  aus-]--+  [  aus-]--+  [  aus-]------....

Immer schön Ausgang von Knoten n auf den Eingang von Knoten n+1.
Zur Adressierung: Der Master sendet ein "Initialisieren!"-Kommando mit
einer Startadresse (z.B. 0) raus, folglich wird sie vom ersten Knoten in
der Kette empfangen. Dieser Knoten merkt sich die Adresse (0), errechnet
wiederum ein "Initialisieren!"-Kommando mitsamt einer neuen Adresse
(z.B. durch Erhöhen der eigenen, neue Adresse wäre dann also 1) und
schickt das Kommando ab.

Es wird vom nächsten Knoten empfangen, der dasselbe tut, und so werden
alle Knoten der Kette fix durchadressiert. Lediglich der Master muss
lange genug warten, die Wartezeit lässt sich wohl leicht ausrechnen.

Im Betrieb werden dann Kommandos (Helligkeit etc.) immer mit einer
Adresse beginnen. Der Master schickt das Kommando los, und der erste
Knoten vergleicht die Adresse mit seiner eigenen. Identisch? -->
Auswerten und fertig. Unterschiedlich? --> Kommando unverändert
weiterschicken.

Travel Rec. wrote:
>>Mit welchem meiner Vorschläge hast Du denn das Problem ?
>
> Den Eingangsschutzwiderstand wegzulassen und die Transistoren ohne
> Basisvorwiderstände zu betreiben. Auch MOSFETs sollten einen kleinen
> Gatewiderstand haben, schon gerade dann, wenn man mit PWM arbeiten will.
> Es nützt nichts, an der falschen Stelle zu sparen und dabei die
> Schaltungssicherheit zu gefährden. Das Hühnerfutter gibt es auch sehr
> klein, in SMD 0603 zum Beispiel, dann ist der Controller das größte
> Bauteil, under das alles andere (außer dem Regler, den LEDs und den
> Elkos) darunter paßt. Auch Transistoren gibt es in SMD.

Alles richtig - für SMD.

Aus den bisherigen Posts entnahm ich aber Bohren und selbst löten mit
bedrahteten Teilen, darum die Empfehlungen.

Aber ich bin jetzt still ! Basta

äh was sprich gegen i^2c?

>äh was sprich gegen i^2c?

2 Leitungen, kompliziertes Protokoll. Siehe Eröffnungspost.

@Compy

Das Daisy-Chaining hat nur einen gewichtigen Nachteil: Latenz

Bei 1 kBaud und 64 Nodes wird die Nachricht (angenommen 10 Bit) quasi
n-mal durchgereicht. Bis ein ACK vom Slave zurückkommt dauert es dann
noch einmal. Ein langsames Lauflicht o.Ä. ist damit dann schon nicht
mehr realisierbar.

Eventuell werde ich mich doch einmal mit SMD-Bauteilen auseinandersetzen
müssen, das verkompliziert jedoch aufgrund der dann verringerten
Strukturgrößen (Leiterbahnbreite, usw.) sowohl das Routing als auch das
Selber-Ätzen (beim Bestücken seh ich kein Problem).


Alex

@ Compy (Gast)

Ja, und der Ausgang des letzten Teilnehmers geht wieder auf den Eingang
des Masters. Somit weiß der, wieviel Teilnehmer vorhanden sind und kann
nach selbigem Prinzip (falls nötig) auch Pakete von dem Slaves
empfangen.

>Das Daisy-Chaining hat nur einen gewichtigen Nachteil: Latenz

Nicht unbedingt. Warum das ganze nicht ohne Adressen benutzen:
Die von Compy beschriebene Initialisierung könnte nur zur Ermittlung der
Anzahl der Teilnehmer dienen ( am Besten ein 0x4D vom Master
durchschicken bis es wieder zurückkommt)

Beim Datenverkehr für die Leds wird das ganze dann als Schieberegister
verwendet:
bsp: es gibt 4Teilnehmer:
Der Master sendet immer 5Bytes raus:
S1,S2,S3,S4

Dadurch dass jeder Teilnehemr weiß, der wievielte er in der Kette ist,
kann er nur auf das eine Byte (Word,DWord..) hören, und beim
Weitersenden diese Information durch eine eigene Ino Rx zurücksenden:
Master:     Tln1        TLn2        Tln3         Tln4         Master
 => S4S3S2S1 => S4S3S2R1 => S4S3R2R1 => S4SR3R2R1 => R4R3R2R1 =>

Somit entsteht eine sehr geringe Latenz, bidirektionale Komm....

Dazu brauchst Du aber ein 2. Datenkabel, nämlich das vom letzten Slave
zum Master zurück. Das Ganze geht auch mit einer Leitung und den
beschriebenen open-Collector-Stufen. Dann kann jeder dirket bekommen,
was ihm zusteht und gegebenenfalls antworten. Natürlich mit
festverteilten Adressen. Die Datenrate wird sicher schneller als 1kBaud
zuverlässig funktionieren. Wenn man spezielle Bitformate benutzt (3
Pulse: Startbit, 2 Pulse logisch High, 1 Puls logisch Low), muß man nur
kurze Zeit ein bestimmtes Timing einhalten (Pulsdauer) und kann das
Protokoll sogar unterbrechen, um später weiterzusenden. Es gibt 1000
Möglichkeiten.

War ja nur ne Idee ;-)

Ist ja auch ein Forum ;-)

Da ich auf den Slaves in C programmieren möchte und der Takt möglichst
niedrig sein soll (1 MHz bspw.) sehe ich nicht soviel Luft, um mit der
Baudrate noch sehr hoch zu kommen.

Beim physischen Protokoll schwanke ich aktuell zwischen:
a.) Manchester Codierung
b.) Pulsbreitencodierung

Auf jeden Fall werde ich eine bitweise Synchronisierung brauchen, da die
Controller mit ihren internen Oszillatoren bei schwankenden Temperaturen
(evtl. auch als open-air Lichtkette) funktionieren sollen. Nur der
Master bekommt einen Quarz.

Tendieren tue ich zu b.), weils noch etwas einfacher zu implementieren
ist, wobei beide Sachen keine Klimmzüge erfordern :)

Bei 1Mhz Taktrate bekommst Du aber kaum noch flimmerfreie Software-PWMs
bei genügend Auflösung hin. Der Tiny 13 vefügt über internen
9,6Mhz-Taktgenerator, damit wird´s schon eher ´was.

Da der Tiny45 eine HW-PWM Unit hat sollte das kein Problem sein.

1MHz/256 macht ca. 3.9 kHz

Damit sollte ich die 8 Bit PWM ohne Flimmern ausreizen können, wenn es
sein muss.

Der 13er hat auch Hardware-PWM, man muß nur gucken, daß man mit den Pins
klar kommt, da etliche Mehrfachbelegungen präsent sind.

hi,

Da sich hier so viele kompetente Leute versammelt haben und ich keinen
neuen Thread aufmachen will schreib ich mal hier rein.
Habe etwas ähnliches vor, nur dass ich das mit nur einem Controller
lösen will, der mehrere TLC5922 (Konstantstrom LED Treiber)
daisy-chained ansteuert.
Mit einem Treiber funktioniert das Programm schon, allerdings bin ich
mir nicht sicher ob das so bleibt wenn ich viele weitere Treiber
anschließe und das über ca 15 Meter. Laut Datenblatt hat der Treiber ein
delay von bis zu 300ns für Data IN --> Data OUT (vorrausgesetzt ich hab
mich da nicht vertan)
Außerdem habe ich Bedenken, dass meine SCLK Leitung nach x Metern kein
eindeutiges Signal mehr raus gibt.
Kann mich da irgendwer aufklären wie weit das alles unkritisch ist?

Vielen Dank

Kai

Mehrere Datenleitungen in einem Kabel über weite Strecken ist kritisch
wegen Übersprechen. Eine Datenleitung zwischen Masse und Vcc ist
unkritischer. 30 Meter bei 19kBaud und gut terminiertem Bus ist kein
Problem.

Zur Übertragung der Daten hatte ich an RJ12 Stecker gedacht, die haben 6
Pins, 5 brauche ich...
gibt es da irgendeine andere geschickte Lösung wie ich bis zu 30 Treiber
(15 Meter) relativ schnell (max 10ms für alle Treiber) mit möglichst
nicht 35 Datenleitungen ansteuern kann?
Wie sieht das mit der Verzögerung beim daisy chainen aus? Ist das ein
Problem?

>gibt es da irgendeine andere geschickte Lösung wie ich bis zu 30 Treiber
>(15 Meter) relativ schnell (max 10ms für alle Treiber) mit möglichst
>nicht 35 Datenleitungen ansteuern kann?

Ja, jedem LED-Treiber einen kleinen Tiny vorsetzen und mit einer
einzigen Datenleitung, wie oben beschrieben, arbeiten. Dein Problem wird
aber eher der hohe Stromverbrauch der vielen LEDs sein und der
demzufolge hohe Spannungsabfall über die Länge des Kabels.

Stromversorgung geschieht über ein PC Netzteil, das die LEDs mit 12V und
die Treiber mit 5V versorgt. Da ist genug Luft nach unten...
Den Tiny wollte ich mir sparen, aber wenn das so dann funktioniert, werd
ich mich wohl dafür entscheiden
Vielen Dank schonmal für die Kommentare

Sind gerade mal 1.20 EUR Aufpreis pro Modul bei einem Tiny13. Und man
kann viele verrückte Dinge machen.

bei tme.pl bekomm ich den auch für unter 80 Cent, aber mir ging es auch
eher um eine Aufwandminimierung, weil das daisy-chaning schon existiert
und ich mir kein neues Protokoll ausdenken muss.
Der Treiber will halt auch für jede LED (bei mir sinds 15) die
Helligkeitswerte übertragen bekommen, womit ich bei 112 Bit/Treiber bin

Was ist besser: 1) mehr Leitungen oder 2) mehr Intelligenz auf dem
Modul? Ganz abgesehen von weniger Problemen bei der Datenübertragung und
direkter Autonomie auf jedem Modul würde ich mich für die zweite
Variante entscheiden.

Hallo,


da nun endlich Wochenende ist, habe ich mal wieder Zeit weiter an diesem
Projekt zu werkeln.

Ich habe mal das aktuelle Schematic in den Anhang gepackt. Den
Programmierstecker habe ich einmal fakultativ hinzugefügt, man muss ihn
ja nicht bestücken. Ich hoffe es lässt sich öffnen, ich musste mir ein
paar zusätzliche Libs von der cadsoft-Homepage organisieren (für den
Tiny sowie die pinheader).

Beim Routen stoße ich jedoch auf ein paar Probleme:

1. Wie kann ich für ein Bauteil festlegen, ob es auf dem Top- oder
Bottomlayer platziert werden soll. Aus Platzgründen möchte ich lieber
mit zwei Layern arbeiten. Die Platine werde ich wohl bei PCBPool machen
lassen, die verlangen 50€ für eine Europakarte doppelseitig inkl.
Durchkontaktierung.

2. Wie kann ich die Schaltung, wenn sie denn mal fertig geroutet ist,
n-mal duplizieren. Ziel ist eigentlich 6-8 Platinchen auf einer halben
Europakarte unterzubringen. Oder kümmert sich darum dann der
Dienstleister selbst?


Gruß,
Alexander

... und der Anhang mit dem Schematic

zu 1.

Indem du manuell routest. Wird sowieso besser.

zu 2.

Schematic schließen. Alles kopieren und wieder einfügen (das ist die
Schere)

zur sch:

Ich würde über den R3 den R3 noch einen kleinen C vorsehen, vielleicht
so 1nF. Er muss ja nicht bestückt werden, je nach Frequenz der
Busleitung. Evtl sollte/könnte auch der R2 etwas verkleinert werden...

Sonst sollte das gehen

zu 1:
Ich glaube Du musst zuerst das Bauteil per Move/F7 an den Mauscursor
hängen und dann die mittlere Maustaste drücken. Funktioniert glaube ich
so bei SMDs. Hab gerade kein Eagle zur Hand ums selber zu probieren...

@ Matthias

Das mit dem manuell Routen ist ein Klasse Tipp ... hätte ich soundso
gemacht :)

Wenn ich ein C parallel über den R3 hänge baue ich mir dann nicht einen
Hochpass? Welchen Zweck soll das C erfüllen?

@ Markus

Das mit der mittleren Maustaste klappt, ich hoffe mal cadsoft hat
irgendwo auch einen Menüeintrag dafür vorgesehen, von alleine kommt doch
kein Mensch auf diese Idee ...


Alex

>Wenn ich ein C parallel über den R3 hänge baue ich mir dann nicht einen
>Hochpass? Welchen Zweck soll das C erfüllen?


Richtig. Dafür sorgst du, dass der Transistor schneller zu/abschaltet.

Kann aber bei sehr geringen Taktfrequenzen entfallen.
Ich würde ihn auf der Platine vorsehen, und dann mittels Oszis
nachsehen, ob nötig.

zur Platinenherstellung kann ich dir nur bilex-lp empfehlen, die machen
das echt gut mit Lötstop und Durchkontaktierung und dann noch ein wenig
billiger :P
Hab da schon eine Platine bestellt, die nächste ist im Auftrag

So, nach nem Abend vorm PC habe ich mal meine erste Leiterplatte
geroutet. Schematic und Board File habe ich mal im Anhang gezippt,
vielleicht kann ja einer der Experten einen Blick drauf werfen und mir
die groben Fehler nennen :-)

Insbesondere bezüglich der Leiterbahnbreite sowie der Größe von Lötaugen
(LEDs) bzw. der 4 Vias bin ich mir nicht sicher. Ich hoffe mal eine
professionelle Leiterplattenfertigung kriegt so feine Strukturen hin und
ich den Kram am Ende auch bestückt ...


Alexander

Mach alle Leiterbahnen 0,3032mm breit. Das reicht hier bei den
Stromstärken.
Platinenhersteller kriegen das locker hin. So "eng" ist das ja nicht.

Auf ne sinnvolle Leiterbahnführung musst noch achten:
zB. JP3.Pin1. Die 12V Leitung sollte zuallererst den C2 erreichen, von
hier kannst du das auf IC3 und die LEDs verteilen, wobei die Anode von
LED1 wieder idealerweise nahe dem C2 liegt. genauso ist das mit dem
Emitter von T4: de sollte nahe am C2 sein. ich würde über beiden noch
einen 100nF legen, du willst ja mit ner PWM mit hoher Frequenz
arbeiten..

Als GND kannst du ruhig ne Fläche nehmen..

Vielleicht route ich dann mal spasseshalber..

Ok, dann werd ich wohl noch etwas an der Wichtung meiner
Optimierungskriterien arbeiten müssen. Bisher gab es nur eins und das
war "Flächenminimierung". Um elektrische Aspekte hatte ich mir beim
platzieren der Bauteile keinen Kopf mehr gemacht.

Über die Sache mit der Groundplane habe ich heute schonmal irgendwo was
gelesen, werde ich dann wohl beim finalen Design noch drüberlegen.

Das Routen ist auf jeden Fall ein größeres Gemehre als ich mir das
vorgestellt hatte, unglaublich wieviel Zeit ich für die paar Teilchen
gebraucht habe.

Über welche Bauteile müssen theoretisch noch Kapazitäten?

- R3 hattest du ja bereits angemerkt, da ich jedoch nur Baudraten von
max. wenigen kBaud plane habe ich der Flächenoptimierung Vorrang
gegeben.

- Meintest du zusätzlich R4?

SO. gucks dir mal an...

Ok, offensichtlich kann man durch etwas exzessiven Einsatz von Vias die
mittlere Leiterbahnlänge deutlich minimieren.

Ich habe gesehen, dass du den 330n C am Spannungsregler entfernt hast.
Ist das hauptsächlich durch Platzgründe motiviert oder braucht man das
Ding einfach nicht (ich hatte die Angabe aus dem Datenblatt).