Beiträge von Irrlicht

Zitat von Pesi

also kann er ihn schlecht um so ne Funktion erweitern wie einen Pin zu toggeln o.ä.

Naja, vielleicht nicht direkt im Bootloader, aber in der Routine, die den Aufruf des Bootloaders enthält?!?!
Bei mir sieht es so aus:

OnRxD:
if UDR=123 then
Porta=&h00000000
PortC=&h00000000
goto &H3c00 'Bootloader aufrufen
end if
Return

Trifft ein serielles Byte ein, wird obige Interrupt-Routine aufgerufen, die testet, ob es der Code für den Aufruf des Loaders ist, der dann auch angesprungen wird (nachdem zuvor noch die Ausgänge genullt wurden, um die Gates der MosFets daran zu entladen).
Dort könnte man das Toggeln einer LED veranlassen. Natürlich floatet der Ausgang, während der Controller auf Reset ist, beim Flashen, aber man kann das zuvor detektieren.

In meinem Fall (ebenfalls über FT232), bei meinem bevorzugten Bootloader, brauche ich keinen Reset am Controller zu drücken. Der bloße Empfang von "123" reicht, dann geht alles seinen Gang.

Zitat

ich weiß nicht, wie es hier ist, der FT232 wird ja über USB versorgt, der Rest der Schaltung extra...? - wenn Die auch über USB versorgt wird, und Du den Reset über ab- und anstecken machst, dann wird mit großer Wahrscheinlichkeit hier das Problem liegen...

Wenn das tatsächlich der Fall ist, würde ich ebenfalls hier ansetzen.
Bzw. auf einen anderen Bootloader umsteigen, der keinen manuellen Reset erfordert.

Zu Deinem Prob mit Waitms:

Waitms ist ziemlich unelegant und unflexibel.
Die Versuche, Waitms mit 'ner Variable zu "laden" habe ich persönlich aufgegeben.

Setze doch lieber einen Zähler auf einen definierten Wert und takte den per Timer-Interrupt auf Null runter.
Dann kann Dein Programm zwischenzeitlich auch noch was anderes machen und steckt nicht im Waitms fest.

Zum Quarz:
Bemühe mal Tante Google mit diesem Suchbegriff (OHNE die Anführungszeichen):
"AVR Quarz-Einstellungen Fuse-Bits"

Das spuckt u.a. diese Treffer aus:
http://www.mikrocontroller.net/articles/AVR_Fuses
http://halvar.at/elektronik/kl…r_kurs/fusebits_standard/
http://www.grzesina.de/avr/fuse/fuse.html

Also von Schottkys etc. würde ich eindeutig abraten.

Bei Li-Ion muss die Endspannung auf 50mV exakt eingehalten werden, sonst leistet man dem Akku aktive Sterbehilfe.
Bei einer nur geringfügig geringeren Spannung errreicht man aber wiederum nur eine wesentlich geringere Ladung.
Man muss also echt präzise sein, mit der Spannung.
Siehe dazu:
http://de.wikipedia.org/wiki/Li-Ion

Ich persönlich habe für mich den MCP73812T auserkoren:
http://de.farnell.com/microchi…-charger-sot23/dp/1627187

Spottbillig und besonders simpel zu beschalten.
Leider braucht der ein Volt mehr am Eingang, als er am Ausgang laden kann. Das ist bei Dir erstmal nicht gegeben.
Ein Wunder an Effizienz kann dieser IC allerdings ohnehin nicht sein, da er linear arbeitet. Aber dass ist bei Dir auch gar nicht wirklich notwendig (siehe weiter unten).

Ein effizienter IC mit wirklich hohem Wirkungsgrad dürfte keine normale Konstantstromquelle integriert haben, sondern er würde Spulen erfordern. Das macht die Sache aber auch wieder relativ anspruchsvoll.

Was bei Dir problematisch ist, ist dass die Solarzellen nur 4,5V liefern, wie Du schreibst (hast Du das mal nachgemessen? Wie ist es bei bedecktem Himmel?), was dammich dicht an der typischen 4,2V Ladeendspannung eines 3,7V-Li-Ion-Akkus ist.
Dieser Typ kommt damit gerade noch zurecht:
http://de.farnell.com/linear-t…n-trickle-8dfn/dp/1648033

Der arbeitet zwar ebenfalls linear, das heißt ohne Spulen, aber um den Wirkungsgrad brauchst Du Dir in Deinem Fall Null Gedanken zu machen, weil bei Dir die Differenz zwischen Eingangsspannung und Ausgangsspannung extrem klein ist. Da kann ja kaum Verlust entstehen.

Hi Elite,

beantworte doch noch meine Frage, ob man irgendwodran erkennen kann, ob die Bootloader-Routine angesprungen wurde.

Kannst Du vielleicht ein Bit zu Fuß toggeln, wenn der Bootloader angesprungen wurde?
Damit man wenigstens sehen kann, ob der Loader überhaupt angesprungen wurde, meine ich.
Ist ja schließlich ein Unterschied, ob der gar nicht erst aufgerufen wird, oder ob er zwar aufgerufen wird, dann aber "hängt".

Und welches Ereignis startet überhaupt den Bootloader?
Ist es das Eintreffen eines bestimmten Bytes per seriellem Port über den FT232?

Noch eine Idee zu Testen:
Angenommen, ein serielles Byte startet den Bootloader:
Kannst Du mal ganz frech zwei dieser identischen Platinen so miteinander koppeln, dass beide den selben seriellen Input erhalten?
Dann könnte man vielleicht sehen, ob eine von beiden "willig" ist und den Loader anspringt, die andere aber zickt.

Hallo Pesi, was ist "BCM"?

flipp86:
Ich glaube ich weiß, wo Dein Problem liegt.

Versuche doch mal, die seriellen Daten immer nur Byte für Byte abzuholen.
Trifft ein serielles Byte ein, löst das einen Interrupt aus. In der Interrupt-Routine werden dann nur zwei Sachen gemacht:

1) Das eine Byte wird in ein Byte-Array gestopft.
2) Arraypointer inkrementieren.

Also nix mit Buffer und so, sondern bei seriellem Interrupt immer nur ein einzelnes Byte "zu Fuß" abholen, statt die Sache Bascom zu überlassen..
Außerhalb der Interrupt-Routine testen, ob das zuletzt empfangene Byte CR ist.
Auch alle übrigen Byte-Dröseleinen, Löschen des selbstgestrickten Empfangsbuffers etc., stets außerhalb der Interrupt-Routine.
Und beim Zerdröseln und Auswerten der empfangenen Daten die Interrupts ausschalten, sonst funkt noch was dazwischen, was ganz merkwürdige Phänomene verursacht.

Deine Stringvariable "New_Command" ist mit 100 Bytes doch reichlich lang. Bascom ist krötenlahm, wenn es Strings zusammendröselt.
Frei aus dem Gedächtnis ist es so, dass Bascom immer den kompletten String umkopiert, wenn auch nur ein einziges Zeichen hinzugefügt werden muss. Man nagle mich auf letztere Aussage nicht fest, aber sowas in der Art könnte hier "unter der Haube" passieren.
Darum also lieber mit 'nem Bytearray arbeiten, immer schön Zeichen für Zeichen.

Zitat von Pesi

Hast Du das DB irgendwo? - von der Herstellerseite http://www.sdo-ic.com/upimg/201132810381563.pdf bekomme ich das nicht runter, das lädt ewig, und dann timeout...

Hmm, bei mir funktioniert Dein Link.

Zitat

wenn ich das richtig sehe, sollte die Ansteuerung aber wie bei TLS3001 sein, da hat turi welche da, wurden ihm versehentlich geschickt statt die bestellten mit WS2801...

Na, dann ist der turi sicher sehr glücklich!
Der TLS3001 erlaubt, wie ich eben herausgefunden habe, 12 Bit PWM.
WS2801 (leider auch der TLS3008, wie eben herausgefunden), erlaubt dagegen nur 8 Bit PWM.

Sicher erzähle ich Euch nichts Neues, aber mit 12 Bit hat man im unteren Helligkeitsbereich erheblich bessere Dimmbarkeit. Stichwort: "Gamma-Korrektur".
Dieses Video verdeutlicht eindrucksvoll den Unterschied:
http://www.youtube.com/watch?v=XlmVjcnP3IM

Zitat

die Frage ist eben, muss es unbedingt dieser Chip sein...? - solche Ketten gibt's ja auch mit LPD6803, WS2801/2811, TM1804 etc. - die sind leichter anzusteuern, ich kann mich so dunkel erinnern (hatte da eben das DB da vom 3001), dass der TLS3001 etwas ekelhaft war von der Ansteuerung her, serielles Signal Manchster-Codiert, da muss man das timing schon deutlich exakter einhalten als bei den anderen Methoden...

Mein Bekannter hat verschiedene Lichterketten getestet und war mit dieser hier besonders zufrieden. Er bekommt die wohl auch besonders günstig.
Obwohl ich ihm das auszureden gedenke, weil der TLS3008 eben nur 8 Bit PWM kann.
Mich persönlich stört auch die räumliche Tiefe dieser Pixel - da gibt es bessere Bauformen, die sicher auch noch bessere Wasserfestigkeit aufweisen.

Zitat

was sind das für Ketten, so mit Einzel-LED-Modulen, Durchmesser ca. 10 mm, zum rein stecken in ein Loch...?

Oh, ich Dussel vergaß die Fotos anzuhängen. Hole ich hiermit nach.

Zitat

wegen dem Entstören könnte ich mir nur irgendwie vorstellen, halt ne leitende Hülle zur Abschirmung um die Adern rum zu machen, "schön" wird man das wohl kaum hin bekommen, aber normal sieht man die Leitungen ja auch nicht...

Stimmt, das sieht man nicht. Aber ich weiß nicht recht, ob das praktikabel und genügend wirkungsvoll ist.
Kann ich natürlich erst testen, wenn ich die Kette am Funzen habe.
Meine Idee wäre, durch Ferritperlen, die man um die Stromleitungen klippt, die Steilflankigkeit des Stromanstiegs etwas herabzusetzen und den Ausbreitungsweg der HF zu verkürzen. Bin diesbezüglich aber unerfahren.

Gestern gelang es mir nicht, das Datenblatt mit Babelfish übersetzen zu lassen.
Habe es eben nochmal mit translate.google.com probiert und damit klappte es so einigermaßen. Da ist zwar noch etwas Detektivarbeit nötig, aber immerhin.

Jedenfalls will ich meinen Bekannten jetzt auf 12 Bit-PWM und eine andere Bauform der Pixel einschwören; insofern ist der TLS3008 wohl erstmal aus dem Rennen, egal wie billig er die schießen kann.

Aber vielen Dank für die Antwort!

Hallo Fasti,

erstmal vielen Dank für Deinen Hinweis!
Aber es hängt natürlich von der Baudrate und der Kalibrierung ab.

Das Datenblatt des Atmega88 besagt, dass bei 8MHz Taktrequenz und 25 Grad die Abweichung vom Ideal bei 19.200 oder 38.400 Baud nur 0,2% betägt.
Bei anderen Baudraten ist die Abweichung höher.
Ich habe daher immer 38.400 Baud genommen, um von daher schon mal möglichst wenig Abweichung zu haben.

Wenn nun der Prozessortakt von den exakten 8MHz abweicht, wirkt sich das natürlich auf die Abweichung der Baudrate aus.
Das Datenblatt besagt:
------schnipp------
The factory-calibrated value is automat-ically written to this register during chip reset, giving an oscillator frequency of 8.0 MHz at 25°C.
The application software can write this register to change the oscillator frequency.
The oscillator can be calibrated to any frequency in the range 7.3 - 8.1 MHz within ±1% accuracy.
------schnapp------

Was ich verschwiegen hatte:
Ich testete nicht nur mit dem Logic-Analyzer, sondern ich ließ gleichzeitig "the quick brown fox" in 'ner Schleife über den "lazy dog" jumpen.

Das Datenblatt sagt zur Temperaturabhängigkeit des RC-Oszillators in diesem Kapitel:
"Figure 27-40. Calibrated 8 MHz RC Oscillator Frequency vs. Temperature"

... dass bei 5V Betriebsspannung die Frequenz im Temperaturbereich zwischen -40 Grad und 80 Grad zwischen 7,82 MHz und 8,24 MHz schwanken kann.
Demnach kommt man in den extremen Temperaturbereichen durchaus in den Bereich von 2% Abweichung, aber unter realeren Bedingungen liegt man eindeutig im grünen Bereich, was sich auch mit meinem Experiment deckte.

OK, im extrem ungünstigen Fall können sich die einzelnen Abweichungen wohl aufsummieren, so dass früher Probleme auftreten.
Aber bei Raumtemperatur wage ich das mal auszuschließen, insbesondere wenn der Oszillator kallibriert wurde, wie im Datenblatt beschrieben (mache ich normalerweise aber nicht).

Vielleicht war es ja echt nur Glück, aber seit diesem Test ließ ich - wo immer möglich - den Quarz einfach weg und wüsste nicht, jemals Probleme mit der seriellen Übertragung gehabt zu haben.
Hin und wieder hatte ich zwar das Prob, dass der Fernbedienungsempfang nicht immer beim ersten Tastendruck hinhaute, aber das schiebe ich auf zwei mir bekannte andere Gründe.

Jedenfalls bin ich dank Deinem Hinweis jetzt stärker darauf fixiert, bei eventuellen Problemen auch mal auf die Taktfrequenz zu achten, vielen Dank!

Ein Bekannter drückte mir eine Lichterkette in die Hand, mit einzeln adressierbaren LEDs.

Der Chip in den Pixeln ist ein TLS3008 - ein 8-poliger SMD-IC.
Die Kette ist dreiadrig aufgebaut. Also Versorgungsspannung plus serielle Daten.

Tante Google lieferte mir dazu zwar ein chinesisches Datenblatt, doch mit dem Lesen hapert es bei mir

Diese Lichterketten sollen sehr preiswert und zudem wasserdicht sein. Löchle bohren, die Pixel snapp-in-mäßig einstecken und fertig ist die Lichtleiste. Hat was.
Dafür würde ich ja liebend gerne eine winzige, ultrabillige Ansteuerplatine entwickeln.
3-Achsen Gyro dazu und man hätte eine außentaugliche Lichtleiste, die auf Bewegung reagieren kann.

Frage: Ist dieser Chip und dessen Ansteuerung hier im Forum bekannt?

Wie ich noch hörte, sollen diese Lichterketten im Radio stören. Die seriellen Daten werden zuletzt also offenbar alle gleichzeitig an die Ausgänge geschaltet.
Hat dafür schon mal jemand hier eine Lösung gefunden, wie man diese Radiostörungen unterdrücken kann?
Ferritperlen oder so?
Die drei Adern lassen sich leicht separieren, es wäre nur schön, wenn man für die Funkentstörung nicht löten müsste, wegen der Wasserdichtigkeit.

OhhhKeehh, ich nehme das mal staunend zur Kenntnis.
Die 306Hz PWM-Frequenz bei 24 Kanälen sind ja schon ziemlich ordentlich.

Mal davon abgesehen, dass ich eine PWM bis etwa 1kHz noch als flimmernd wahrnehme, gerade bei niedrigen bis mittleren Helligkeitswerten. Das war bei mir aber auch die Grenze dessen, was ich mit 'nem AVR noch hinbekommen habe, in Weichware; schneller schaffte ich es nicht, wenn der AVR auch noch Nebenaufgaben erledigen soll.

Ein befreundeter Ing. Nachrichtentechnik und meine Wenigkeit haben mal zusammen 'nen Daddelautomaten entwickelt.
Ich machte den größten Teil der Hardware, mein Freund die Software (in C). Trotz meines Protestes sollte die Schaltung keine Hardware-PWM bekommen, um die Kosten zu senken. Hinterher war mein Freund verzweifelt am Optimieren der Software, bis man so einigermaßen mit dem Ergebnis leben konnte, ohne dass serieller Datenempfang großartig zu sichtbarem Flimmern führte. Und der Mann versteht sein Handwerk.

Für meine Wahrnehmung war die PWM-Frequenz am Ende zwar störend gering, aber anscheinend fiel das sonst keinem auf.

Ich baue aber auch Lauflichter für Schausteller. Da kommt nicht selten Bewegung mit ins Spiel.
Lahme PWM geht da gar nicht, sonst "malen" die bewegten LEDs gepunktete Linien in die Luft.
Aber wie man das in Weichware in den Griff kriegen sollte, mit 'nem lahmen AVR, wäre mir persönlich schleierhaft.

PWM unter 1kHz kommt mir grundsätzlich nicht ins Haus, weil ich es einfach störend finde.
Wenn man direkt drauf blickt fällt es nicht auf, aber aus den Augenwinkeln heraus flimmert es halt (zumindest in meiner Wahrnehmung).
Jedanfalls danke für die informativen Beispiele, Pesi!

Zum Posting Nr. 52 von mike57:

Es ist sogar noch viel dramatischer mit den Stromspitzen, als in Deinem Bild.
Da sind Spitzen von rund 200A durchaus drin. Habe das mal mit LTSpice simuliert.

Übel ist die Kombination solcher LED-Leuchtmittel mit einem Lauflichtgerät. Hat das Gerät SSRs eingebaut, mit Nulldurchgangsschalter, dann schalten die Triacs, wenn sie abschalten sollen, kurz nach dem Spannungsmaximum der Netzspannung ab. Sagen wir mal ... bei 300V. Denn das ist der Zeitpunkt, wo kein Strom mehr fließt.
Erfolgt dann das nächste Einschalten im Nulldurchgang der Netzspannung, dann entlädt sich der noch auf rund 300V aufgeladene Kondensmann schlagartig durch den Triac.

Noch übler ist es, wenn das SSR keinen Nulldurchgangsschalter hat. In dem Fall kommt es immer wieder mal vor, dass der aufgeladene Kondensmann beim nächsten Einschalten auf das Spannungsmaximum der entgegengesetzten Halbwelle stößt.
Dann werden gewissemaßen über 600V kurzgeschlossen - ganz kurzzeitig natürlich nur, aber tausende Male am Tag.
Bei Parallelschaltung von ein paar Hundert dieser Leuchtmittel wird der Triac auf die Dauer doch ziemlich malträtiert.
Von Dimmern wollen wir mal erst gar nicht reden ...

Jedenfalls sind solche Leuchtmitteln bei Schaustellerbuden gerade der große Trend. Und da stirbt (bzw. zickt) ein Lauflichtgerät nach dem anderen, das vorher 20, 30 Jahre lang perfekt mit Glühlampen lief.
Auch die LED-Leuchtmittel halten nicht so lange, wie man naiv erwarten würde.

Wenn man es gut machen will, müsste man durch die Ansteuerlogik dafür sorgen, dass die Triacs immer nur dann einschalten, wenn die Netzspannung in Betrag und Vorzeichen mit der (durch den Kondensmann noch vorhandenen) Spannung am LED-Leuchtmittel übereinstimmt.
Wenn schon Triac statt IGBT, dann zumindest einer ohne Nulldurchgangsschalter, den man zu beliebigen Zeitpunkten einschalten kann.

Interessant war für mich jedenfalls gerade der Hinweis, dass man solche Leuchtmittel auch in Reihe schalten kann. Auf die Idee bin ich noch nie gekommen; das muss ich mal testen, bzw. simulieren.
Dürfte den Stromspitzen ziemlich den Biss nehmen und auch die Empfindlichkeit gegenüber Rundsteuersignalen ein gutes Stück reduzieren, weil die Last insgesamt mehr resistiv wird.

Danke Condor, für diesen Link!

Den hätte ich damals gebrauchen können, als ich eine China-Fernbedienung mit einer LED-Steuerung verheiraten wollte.

Bin damals so vorgegangen:
Zunächst 'ne einfache Empfangsdiode (oder LDR, was auch immer) ans Oszi geklemmt um erstmal die korrekte Modulationsfrequenz des Lichtes herauszufinden.
Z.B. 36kHz, 38kHz, 40kHz ...

Mit diesem Wissen dann einen für diese Modulationsfrequenz geeigneten IR-Empfänger gekauft.
Den dann entweder:
- An einen Logic-Analyzer hängen und sämtliche Tastendrücke auf der FB protokollieren.
- Oder, wenn kein LA verfügbar, einfach an einen Microcontroller hängen, der bei jedem Impuls vom Empfänger (der einen Interrupt auslöst) einen Zählerstand protokolliert, den Zähler resettet (als Vorbereitung, für den nächsten Impuls) und am Ende, wenn man eine Taste am Micro drückt oder so, das Protokoll per RS232 etc. zum PC schickt.
Das für alle Tasten wiederholen.

Am Ende muss man nur die Protokolle der einzelnen FB-Tasten vergleichen und etwas Detektiv spielen.
Was ist eine Eins? Was ist eine Null? Wie viele Bits werden wohl übertragen? Was ist die Vorbereitungssequenz, was ist die Adresse und was sind die eigentlichen Daten?

Als ich das zum ersten Mal machte, hatte ich vom Tuten und Blasen keine Ahnung und habe drei Tage daran getüftelt.
Obige Beschreibung dürfte einem experimentierfreudigen Menschen zwei bis 2,5 Tage ersparen.

Aber der Link von Condor könnte das Prob sehr generell aus der Welt schaffen.
- Viel Erfolg!

Hi Flipp86,

doch, Du hast eine andere Wahl, als Software-PWM einzusetzen.
Für PWM gibt es spezielle ICs, die LED-Treiberstufen gleich integriert haben. Die schließt man einfach per I2C oder SPI an den Atmel an und freut sich, was der dann plötzlich alles kann, ohne sich anstrengen zu müssen!

Eine Weichware-PWM beschäftigt den Controller permanent, und alles, was dazwischen funkt, sorgt für Flackern. Oder (umgekehrt) die serielle Datenübertragung kommt aus dem Takt. Oder ...
Weichware-PWM ist böse! Ist das Werk von finsteren Mächten! Sie verursacht Schlafmangel, schlechte Laune und Eheprobleme!

Man macht das z.B. so:
Kleiner Kondensator in Reihe, der den größten Teil der Netzspannung von dem nachfolgenden Schaltungsteil fern hält.

Solche LED-Leuchtmittel, mit Reihenkondensator, kann man fertig für 2,- EUR und weniger kaufen, z.B. in E14-Fassung, oft mit 8 oder 16 LEDs. Auch farbig.
Bei den Preisen lötet man eigentlich nicht mehr selbst.

Man sollte aber beachten, das sowas nicht gut für die Ansteuerung durch Triacs geeignet ist, weil die resultierende Last dann eher kapazitiver Art ist.

Also ein Quarz ist nach meiner Erfahrung nicht erforderlich. Weder für RS232, noch für das Decodieren einer Infrarot-Fernbedienung.
Habe den internen 8MHz-Oszillator eines AVR mal ausgiebig getestet:
- Schaltung an den Logic-Analyzer gehängt.
- Schaltung mit Heißluft auf über 100 Grad gefoltert.
- Schaltung mit Flüssiggas auf knapp -40 Grad runtergequält.

Ergebnis: Man sieht im Logic-Analyzer zwar eine leichte Verschiebung der Frequenzen, z.B. der RS232 Baudrate, bleibt aber deutlich im grünen Bereich.

Was mir aufgefallen ist: Elite verlinkt auf den Bootloader von Chip45.
Folgt man dem Link, ist da die Rede von automatischer Baudrateneinstellung. Ich weiß nicht, was dieser Bootloader so kann, aber ich würde genau da das Problem vermuten.
Je nach Taktfrequenz gibt es halt eine optimale Baudrate. Das Datenblatt des AVR gibt darüber Auskunft.
Genau die sollte man dann einstellen, dann kann einem auch keine Temperaturschwankung derart in die Suppe spucken, dass die Übertragung aus dem Takt kommt.

Frage: Macht der Bootloader irgendwas, woran man erkennen kann, ob er überhaupt gestartet wurde?
Irgeneinen Portpin toggeln oder so?
Ich habe meine Bootloader immer so modifiziert, dass sie als erstes einen Pin zweimal toggeln. Dann kann man bei Problemen (oder automatischen Resets) wunderbar erkennen, ob (bzw. dass) die Bootloader-Routine angesprungen wurde.
Wenn es dann "hakt", liegt es vermutlich an Baudratenproblemen.

Und natürlich gibt es auch noch die ganz generelle Falle:
Fusebits beider Controller nicht identisch gesetzt.
Das ist immer einen Blick wert ...

Hoffentlich passt meine Antwort zu Turis Frage (kenne das Sedu-Board nicht):

Also: Ja, es gibt Alternativen zu Optokopplern, die teilweise Vorteile haben.

1) In vielen Fällen ist schon der gute, alte MAX232 ein sehr robuster Schutz - sogar bidirektional. Man bedenke: Kein Mensch zwingt einen, ausschließlich RS232-Daten über den Chip zu übertragen, bloß weil der ursprünglich dafür gemacht wurde ...
Und es gibt heutzutage etliche Varianten davon, mit nochmals verbesserten oder speziellen Eigenschaften.

2) Von IC-Haus habe ich mal einen I/O-Baustein gestestet (weiß nur nicht mehr welchen, werde alt ...) und für unkaputtbar befunden, für Spannungen im 24V-Bereich und bei Kurzschlüssen. Schau selbst mal, welcher Typ am besten zu Deiner Aufgabenstellung passt:
http://ichaus.de/
Aber auch hier gilt: Kein Mensch zwingt einen, ICs so zu verwenden, wie vom Hersteller gedacht. IC-Haus hat ziemlich ulkige Bausteine im Angebot, die sich vorzüglich für ganz andere Aufgaben eignen.

3) Jaaa, und dann der Königsweg: Man nehme einen ADUMXXXX.
http://de.farnell.com/jsp/sear…evNValues%3D2008%2B204546

(Urgs, das ist aber ein langer Link ...)

Diese ADUM-Bausteine sind schneller als übliche Optokoppler und trennen magnetisch(!) statt optisch. Ohne externe Bauteile!
Gibt es mit einem bis vier Kanälen, auch bidirektional - muttu Dich mal durchwurschteln.
Der besondere Gag ist der, dass darunter auch Typen existieren, die nicht nur Daten, sondern auch etwas Power galvanisch getrennt übertragen können - ohne externe Komponenten!
Man kann mit manchen Typen z.B. die Gates von Power-MOSFETS oder IGBTs direkt treiben; und zwar schnell (wenn man den richtigen Typen nimmt), weil echt genügend Strom mit übertragen wird - ganz im Gegensatz zu Optokopplern.

Wenn man mit einem ADUM galvanisch trennt und mit der übertragenen Power auf der gefährdeten Seite noch einen I/O-Baustein von IC-Haus versorgt, der wiederum den ADUM schützt, dann dürfte das die ultimativ unkaputtbare Lösung sein.

Aber natürlich reicht in vielen Fällen auch ein simpler Optokoppler, das ist klar.
Doch bei Frequenzen deutlich oberhalb von 1MHz, oder wenn Gates von IGBTs an Netzspannung getrieben werden sollen, etc. blahblah, dann sind die ADUM unglaublich praktisch.

Sorry, wenn das vielleicht nicht ganz zum Problem des Threadstarters passt, aber ich wollte diese verschiedenen Varianten mal vorgestellt haben, weil ja grundsätzlich nach Alternativen zu Optokopplern gefragt wurde.

Von NXP gibt es den PCA9626.
Der kann 24 LEDs (oder 8 RGB-LEDs) per PWM (bei knapp 100kHz) ansteuern, inklusive "Dot-correction" (also individuellem Helligkeits-Ausgleich).

Wird per I2C-Bus angesteuert und treibt Lasten bis 40V bei 100mA pro Kanal.

Auf den bin ich gestoßen, als ich eine Löung suchte, mit 'nem simplen Atmel AVR über 70 LEDs komplett unabhängig anzusteuern.
Nach dem Vergleichen von hunderten LED-Treibern fiel die Wahl auf diesen Chip. OK, ich brauche natürlich drei davon.
Er entlastet den AVR von der PWMerei, belegt nur den I2C-Port und es flimmert absolut nichts, weil die PWM-Frequenz so schön hoch ist.
Bei diesen üblichen Matrix-Geschichten stört mich nämlich immer das Geflimmer, gerade wenn Bewegung im Spiel ist.

Er erfordert pro Kanal einen eigenen Vorwiderstand, aber dafür ist das Gehäuse (LQFP) schnuckelig klein.

Erhältlich z.B. bei Farnell:
http://de.farnell.com/nxp/pca9…/dp/1854076RL?Ntt=PCA9626

Hallo Hunzenplunz,

wie wäre es mit der Idee, in Reihe zu den LEDs 'nen Power-MOSFET zu schalten und den wiederum mit 'nem Mikrocontroller per PWM anzusteuern, der auf 'ne Fernbedienung hört?
Für Atmel AVR habe ich da mal 'ne Routine gestrickt (in Bascom), so dass man mit 'ner billigen 08/15 Infrarotfernbedienung kräftige RGB-LEDs dimmen kann (und noch viel mehr).
Die könnte ich Dir zur Vefügung stellen.

Finde ich viel unkomplizierter, als mit analogen Steuersignalen zu arbeiten, oder gar einen Dimmer korrekt auszuwerten.
Insbesondere lässt sich auch diese Weise so ziemlich jedes System nachträglich modifizieren.

Aber machen diese Module denn echt nur Licht An/Aus?
Ist da keinerlei Möglichkeit on board, auf die Helligkeit Einfluss zu nehmen? Kann man heutzutage ja kaum glauben.

Und kann man intern irgendwo eine Spannung abgreifen, um den Mikrocontroller zu versorgen?
Die 38V sind ja schon mal recht unangenehm viel, aber wenn man die LEDs per MOSFET aus schaltet, könnte die Leerlaufspannung sogar noch deutlich höher sein.
Sonst vielleicht ein kleines Schaltnetzteil einbauen, das direkt aus 230V stabilisierte 5V zaubert. Gibt es als Platinchen zu etwa 10 EUR, oder man schlachtet ein Steckernetzteil mit USB-Ausgang.

Etc. etc. - 1000 Möglichkeiten!
Am Ende bastelt man aber doch ein paar Stunden rum und verheizt knapp 40,- Euronen für alles zusammen.