Beiträge von synvox

    Ach ja, früher war alles besser :D .


    Nein, Quatsch, natürlich nicht.


    Aber es ist schon so, was einige auch schon erwähnt haben, dass sich in der LED-Technik, aber auch deren Ansteuerung via µC und so in den letzten 5 - 10 Jahren extrem viel getan hat. Heute bekommt man schon vieles fix und fertig von Aliexpress und Konsorten, so dass sich Eigenentwicklungen und Selbstbau zum Teil kaum noch lohnen.
    Ich habe hier früher auch schon mal das eine oder andere Projekt vorgestellt, was ich dann später doch nie wirklich ganz umgesetzt habe, weil einfach das Angebot an Fertiglösungen meine Entwicklungen überholt hatten.


    Ich habe mich zum Beispiel schon immer v.a. für LED-Matrix-Ansteuerungen interessiert. Aber als die WS2812- und APA102-LEDs und entsprechende Strips und Module aufkamen, wurde das für kleine bis mittlere Matrix-Grössen (ohne Multiplexing) für mich persönlich rein von der Elektronik her zu simpel und beliebig. Da habe ich irgendwann das Interesse daran verloren.


    Dann kamen natürlich auch die grossen RGB-Matrix-Module aus China mit gut abgeglichenen RGB-LEDs etc. zu erschwinglichen Preisen auf den Markt, was es natürlich umso weniger sinnvoll erscheinen liess, eigene RGB-Matrix-Module mit irgendwelchen TLC-Chips und Cree- oder Samsung-LEDs (welche bei entsprechend engem Binning doch recht teuer waren) zu entwickeln.


    Mittlerweile finde ich es gerade WEGEN den grossen China-Matrix-Modulen (64 x 64 oder mehr RGB-LEDs pro Modul) wieder interessant ;) . Momentan werden ja in der DIY-Community und Maker-Kreisen v.a. Raspberrys und ev. noch ARM Cortex M4s damit gequält, per Bitbang diese Matrixen mit genügend Graustufen pro Grundfarbe ansteuern zu können, was natürlich entsprechende Prozessor-Auslastungen von 50% und mehr zur Folge hat (ausser bei den mehrkernigen Raspberrys).
    Ich bin der festen Überzeugung (was auch die chinesischen Ansteuer-Module bestätigen), dass die Ansteuerung solcher Matrixen geradezu nach FPGA schreit. Der µC soll sich dann um die Berechnung der Graphik und nicht um das enge Timing der Ansteuerung kümmern, diese übernimmt ein FPGA. Da wird hoffentlich noch was Open-Source- und Open-Hardware-mässiges von mir kommen ;).


    Langer Rede kurzer Sinn, die Totgesagten leben länger :) . Das kommt mir auf jeden Fall so vor, wenn ich alle Schaltjahre mal wieder hier vorbeischaue ;) . Es ist sicherlich nicht mehr so viel los wie früher, aber es lebt und wuselt immer noch, nicht zuletzt, weil eben immer mal wieder die gleichen Fragen auftauchen. Anfänger wird es immer geben, und das ist auch gut so :) .


    In diesem Sinne, es lebe das Ledstyles-Forum und weiter so!


    Viele Grüsse
    Neni

    Ich denke, wenn einfach der Link auf die Facebook-Seite gepostet worden wäre ohne den zusätzlichen, saublöden Satz "...legt euch nen Facebook account zu :) " danach, wäre es auch kein Problem gewesen. Wie auch viele hier schreiben, kann man sich die Bilder auch ohne Account anschauen. Die Facebook-Werbung war also absolut unnötig und für das Projekt eher kontraproduktiv, was ja eigentlich schade ist.
    Ich selbst halte auch absolut gar nichts von Facebook, schaue mir aber trotzdem manche Facebook-Seiten an, wenn dort für mich iteressante Informationen vorhanden sind, natürlich ohne Account. Man kann dann einfach keine Kommentare hinterlassen, nicht 'liken' und sonstigen Facebook-Social-Krimskrams-Quatsch nicht machen, was mich ja eh nicht interessiert.
    Aber wenn jemand dann so penetrant Facebook-Account-Werbung macht, dann stösst es mir leider auch sauer auf und lässt die Säure dann irgendwie auch sein Projekt angreifen, leider.


    Gruss
    Neni

    Mal abgesehen vom MOSFET-Dino (BUZ11) sind die Ausgänge des TLC5940 streng genommen Konstantstromsenken und keine Konstantstromquellen, sie 'schalten' also nach Masse. Mit einem Pulldown-Widerstand am MOSFET kann dieser gar nie durchschalten. Wenn schon, dann müsstest du einen Pullup-Widerstand nach V+ (für einen BUZ11 V+ eher höher als 5V) am MOSFET vorsehen. Dann wird der MOSFET zwar schalten, aber du wirst an der LED eine invertierte PWM bemerken, denn der MOSFET schaltet durch, wenn der Ausgang am TLC5940 aus (hochohmig) ist. Du musst also vor den MOSFET noch eine zusätzliche Inverterschaltung spannen, oder aber einen P-Typ-MOSFET (statt einem N-Typ) verwenden (auch wieder mit Pullup) und die LED dann eben zwischen Drain (des MOSFET) und Masse hängen.


    Gruss
    Neni

    Ein zusätzlich am Ausgang angeschlossenes, längeres Kabel wirkt wie eine unterminierte (bzw. extrem hochohmig terminierte) 'Transmission Line'. Bei Flanken-Anstiegs- und Flanken-Abfall-Zeiten von wenigen ns (beim 74HCT244) bekommst du Signalreflektionen am unterminierten Kabelende, welche dann wieder zum Kabelanfang 'wandern' und dort dein Ursprungssignal überlagern. Das kann je nach Kabellänge und je nach Länge der Signal-Pulse diese mehr oder weniger stark (bzw. signifikant) beeinflussen. Ein Terminationswiderstand von ca. 1kOhm gegen Masse am Ende des Kabels hätte wahrscheinlich auch geholfen, aber das Kabel stark zu kürzen bzw. wegzulassen geht natürlich auch.


    Wenn du auch zur Verbindung mit dem Strip ein längeres Kabel verwendest, würde ich am Strip-Anfang (bzw. Ende des Verbindungskabels) auch einen 1 kOhm Widerstand gegen Masse schalten, denn der Eingang eines WS2812 ist auch sehr hochohmig (d.h. praktisch unterminiert).


    Gruss
    Neni

    OE schaltet ja nur für die Dauer der jeweiligen BAM-Stufe die gesamte Zeile ein (und aus). Die Werte der Bits (0 oder 1), welche in die Schieberegister entsprechend den Daten für die jeweilige Zeile und BAM-Stufe reingeschoben worden sind (während der vorhergehenden BAM-Periode) bestimmen dann ja, ob der entsprechende Pixel während der jeweiligen OE-Aktiv-Zeit ein oder aus ist. D.h. während einer BAM-Periode befinden sich in der Zeile nur die Daten für ein BAM-Bit, d.h. ob die Pixel-Daten an der Stelle des jeweiligen BAM-Bits dann eine 0 oder 1 stehen haben.


    Aber ich denke, du bist da ja noch selbst drauf gekommen ;) .


    Wichtig ist vielleicht auch noch zu sagen, dass das für eine Gesamtmatrix aus mehreren solchen Modulgruppen, wie Andre sie hat, nur deshalb mit 12 Bit BAM pro Farbe funktioniert, weil der FPGA einige serielle Datenstreams parallel an die Module ausgibt. Das wären in der Kofiguration von Andre jeweils 3 x 2 = 6 Streams pro Modulreihe (16 Zeilen zu 3 Farben bei 1/8 Scan). Bei 6 Modulreihen sind das dann 36 parallele Datenstreams. Das ist für einen entsprechend leistungsfähigen FPGA kein Problem, weil ja die entsprechende Logik eben quasi als Hardware implementiert wird und somit die Pixeldaten grösstenteils eben nicht sequentiell sondern parallel verarbeitet werden können.


    Gruss
    Neni

    Nun, eigentlich kann der FPGA relativ problemlos die ca. 200 Hz Refresh bei 20,8 MHz SCK (Serieller Daten-Clock) und 1/8 Scan erreichen, selbst bei 128 Bit pro Zeile.
    Nehmen wir mal an, man will 200 Hz Refresh haben, dann ergibt das bei 1/8 Scan 1600 Hz Zeilenfrequenz bzw. 625 µs Zeilen-Verweilzeit. Wenn wir 12 Bit BAM implementieren wollen, müssen wir diese Verweilzeit in 4095 Zeiteinheiten aufteilen und dann für die 12 BAM-Zeiten folgende Faktoren nehmen: 2048, 1024, 512, 256, 128, 64, 32, 16, 8, 4, 2, 1. Das entspricht folgenden BAM-Zeiten (in µs, aufgerundet): 312,6; 156,3; 78,1; 39,1; 19,5; 9,8; 4,9; 2,4; 1,2; 0,6; 0,3; 0,2. Insgesamt ergibt das wieder die 625 µs. Diese Zeiten werden vom FPGA via OE (Output Enable) jeweils für die ganze Zeile geschaltet. Nun braucht aber die Übertragung von 128 Bit bei 20,8 MHz rund 4,6 µs, also länger als die 5 niederwertigsten BAM-Zeiten. Das macht aber nichts, denn der FPGA (intern läuft er wohl mit einem vielfachen der SCK-Frequenz) steuert OE ja praktisch unabhängig vom Daten-Latch und damit von der Zeilenladezeit (Daten für die nächste BAM-Stufe oder Zeile). Es ergibt sich für die 5 niederwertigsten Bits einfach eine Totzeit, welche sich je Zeile aufsummiert und somit die maximal erreichbare Globalhelligkeit beeinflusst, nicht aber die Auflösung oder die Linearität. In diesem Beispiel wäre die Zeilenverweilzeit dann tatsächlich 643,3 µs statt 625 µs (die 5 kürzesten BAM-Zeiten durch 4,6 µs ersetzt), also 18,3 µs Totzeit pro Zeile. Das würde dann 1554 Hz Zeilenfrequenz oder 194 Hz Refresh ergeben. Wenn man genau 200 Hz haben will , dann muss der FPGA entsprechend alle BAM-Zeiten im Verhältnis etwas verkürzen, so dass die Totzeit im Verhältnis etwas zunimmt und die Gesamtsumme der Zeiten dann 625 µs ergibt. Die Gesamtsumme der BAM-Zeiten wäre dann natürlich etwas kleiner als 625 µs. Man kann sicherlich eine Gleichung aufstellen, um die dann erforderlichen (für 200 Hz Refresh inkl. Totzeit) BAM-Zeiten genau auszurechnen, aber das ist mir jetzt zu mühsam. Wichtig ist ja v.a. das Prinzip ;) .


    Gruss
    Neni

    Hoi Pesi,


    ich denke, das sollte so stimmen wie du es berechnet hast. Mit 8 MHz SPI-Clock (also 4 MHz GS-Clock) dürftest du auf 122 Hz Display-Refresh-Rate kommen. Wenn du die Daten mittels DMA zeilenweise rausschiebst, solltest du einen Ping-Pong-Puffer für das gesamte Display im Arduino-ARM implementieren (Platz genug dürfte dieser haben) und jeweils den Puffer bei Vertical SYNC und wenn neue Daten für ein ganzes Bild in den anderen Puffer geschrieben worden sind switchen. Dies vermeidet Tearing-Effekte, erfordert aber, dass die Frame-Rate (wenn nicht synchron zum Refresh) deutlich niedriger ist als die Refresh-Rate, um sichtbare Ruckler zu vermeiden, also bei 122 Hz Refresh ca. bis 30 Hz Frame-Rate.


    Gruss
    Neni

    Hallo Pesi,


    ich würde bei den 10 Modulen in Serie (x 3) bleiben oder unter Umständen noch weiter aufteilen, z.Bsp. 5 Module in Serie (x 6). Alle 30 Module in Serie wären meiner Meinung nach auf jeden Fall zu viel von der für eine Zeile benötigten Zeit her.


    Da du per BLANK (schaltet die Ausgänge aus und resettet den Counter) ja den Counter des TLC5940 grundsätzlich selbst kontrollierst und der TLC5940 ja klassische PWM (also nicht ES-PWM oder sowas) macht, kannst du prinzipiell auch jede beliebige PWM-Tiefe (PWM-Clocks) pro Zeile realisieren, wobei sinnvollerweise ein Wert teilbar durch 8 (wegen SPI) und grösser oder gleich der maximalen Bitzahl der Zeilendaten gewählt werden sollte.
    Bei 10 Modulen in Serie hast du 1920 Bit Zeilendaten, also würde sich eine 11-Bit-PWM (also 2048 PWM-Clocks) anbieten. Da müsstest du dann nur noch 16 Dummy-Bytes vor den 240 Datenbytes via SPI pro Zeile schicken. Da kannst du entweder bei 4 MHz SPI bleiben und bekommst die doppelte Bildwiederholrate oder du nimmst 2 MHz SPI und gewinnst dafür Verarbeitungszeit.
    Bei 5 Modulen in Serie könntest du sogar eine 10-Bit PWM verwenden und würdest dadurch noch höhere Bildwiederholraten bzw. mehr Verarbeitungszeit gewinnen.
    Klar ist, dass in beiden Fällen die PWM-Daten entsprechende Maximalwerte dann nicht überschreiten sollten, also 11 Bit bzw. 10 Bit, obwohl die Registerbreite pro Wert 12 Bit zulässt.


    Bezüglich USART, ja, bei gewissen AVRs kann man soweit ich mich erinnern kann (mache nicht mehr so viel mit AVRs sondern mehr mit ARM Cortex Ms) den/die USART(s) in einem synchronen Modus betreiben, was glaub ich dann kompatibel zum SPI ist, aber da musst du dir die jeweiligen Datenblätter dazu mal ansehen.


    Gruss
    Neni

    Hallo Pesi, hier mal drei Alternativ-Verkäufer solcher 20 mm Rot-Grün Matrix-Elemente, welche ich auf die Schnelle ergooglen konnte:
    http://www.elecrow.com/display…color-redgreen-p-243.html
    http://www.emartee.com/product/41411/20mm 8*8 Square Matrix LED Red&Green
    http://www.aliexpress.com/stor…MM/829429_1137867408.html


    Was die Ansteuerung von TLC5940 inkl. Multiplexing angeht, so würde ich persönlich GS-Clock und SPI-Clock zusammenlegen (natürlich mit Buffern). Dann schickst du einfach einen Stream mit einer entsprechende Anzahl an Dummy-Bytes (z.Bsp Wert 0) und am Schluss des Streams die eigentlichen Daten (für die nächste Zeile) pro Zeile per SPI, so dass sich insgesamt 4096 Bits (also automatisch auch 4096 Clocks) ergeben, bevor du XLAT und BLANK aktivierst und die Zeile umschaltest, dann wieder von neuem etc. Das würden also 512 Byte SPI-Daten pro Zeile sein, wovon aber nur die letzten ( (n x 192) / 8 ) Byte im SPI-Stream die eigentlichen Daten wären, der Rest sind Dummy-Daten.


    Gruss
    Neni

    Hallo Pesi,


    was dem wohl am nächsten kommt, sind die ICs der Reihe MAX696x, welche eine 8x8 Rot-Grün-Matrix ( 16 x 8 ) direkt ansteuern können (inkl. Scanning), allerdings leider nur mit max. 4 Helligkeitsstufen pro Farbe und Pixel und nur grüne LEDs mit weniger als 3 V Vorwärtsspannung (die eher gelb-grünen LEDs), wobei die meisten Rot-Grün-Matrix-Teile wohl mit solchen LEDs ausgestattet sind.
    Wie alles von MAXIM integrated sind auch diese ICs bei kleinen Stückzahlen eher teuer.


    Sonst gibt's natürlich immer die Option, es mit einem 'normalen' 16-Kanal-Konstantstrom-PWM-Treiber zu machen und das Scanning der Zeilen/Spalten von einem kleinen µC abarbeiten zu lassen (inkl. Verwalten eines internen Bildspeichers). Der µC kann dann natürlich auch als SPI-Slave etc. fungieren. Das geht natürlich nur, wenn neben dem LED-Treiber-Chip auch noch Platz genug für einen µC ist.


    Gruss
    Neni

    Ich persönlich würde heutzutage kein Spektrometer selbst bauen, da es auf dem Markt mittlerweile doch entsprechend günstige Modelle gibt. Die ganze Elektronik etc. ist nicht das Problem bzw. ist sogar relativ einfach. Schwierig ist es, die Optik bzw. die optischen Pfade wirklich gut hinzubekommen, dass das Gerät dann eben über eine entsprechende Genauigkeit, Spektralauflösung und Rauscharmut verfügt. Wenn man keine Erfahrung in dem Bereich hat, wird man bestenfalls ein Messgerät mit sehr limitiertem Verwendungszweck (qualitative Vergleichsmessungen etc.) zustande bringen. Ob sich das dann bei der heute nicht mehr so grossen Ersparnis rechnet, wage ich eher zu bezweifeln.


    Ich habe neben einem eher teueren (um die 2000 €) Handheld-Spektrometer mit Touchscreen (für mobile Zwecke) aus Fernost auch ein kleines Desktop-Spektrometer für den PC-Anschluss (via USB) "LR1" von ASEQ Instruments, welches ich sehr empfehlen kann. Es kostet inkl. der XYZ-Koordinaten-Option (Software-Option) knapp 800 Kanadische $ (ohne XYZ: 750 $). Ich habe die Configutarion A mit 50 µm slit (300 - 1000 nm bei 1 nm Spektralauflösung). Neben der Applikations-Software bekommt man auch die DLLs etc. zum einbinden in eigene Software (Labview- und VC++ -Beispiele sind dabei). Es hat einen SMA 905 Standard-Anschluss, über den man via LIchtleiter einen Cosinus-Korrektur-Adapter (kleiner Diffusor für Lichtintensitätsmessungen) oder einen Licht-Integrator (Ulbricht-Kugel etc. für Lichtflussmessungen) anschliessen kann.


    Gruss
    Neni

    Hab die Firmware von 2.32 auf 2.38.3 geupdated (Ver. 4 bekomm ich irgendwie nicht raufgeladen. Sollte aber ab Version 2.36 gehen laut User Guide)


    Nöö, erst ab Version 2.45 laut aktueller User Guide:

    Zitat

    Roving Networks WiFly modules support several methods for accessing Wi-Fi networks. In addition to infrastructure mode and ad hoc mode, with firmware version 2.45 the modules support access point (AP) mode. You implement AP mode using special firmware. In the future, AP mode will be released as part of the standard firmware and will replace ad hoc mode.


    Vorher gab's nur den ad-hoc-mode, und in version 2.36 haben sie nur den Auto Join Modus per default geenabled (aber eben für ad hoc Netzwerke).


    Du solltest aber unbedingt auf die 4er Versionen updaten. Da gibt's neben einem stabilen Soft AP Modus noch die möglichkeit mit einem kleinen Web-Konfigurationsserver zu starten, was es dann nach Verbindung mit dem Soft AP des Moduls insbesondere sehr einfach macht, dieses dann einfach per Webbrowser (auf dem Handy, PC etc.) auf die eigene Netzwerk-Infrastruktur (den eigenen AP etc.) einzustellen, ohne es per UART konfigutieren zu müssen.


    Ich hatte übrigens auch die Version 2.32 auf meinem RN171, und bei mir ging das Update auf V4 via FTP problemlos. Du musst einfach strikt nach dem User Guide vorgehen. Allerdings stimmt die in der User Guide angegebene und im Modul als Default gespeicherte IP des FTP-Servers nicht mehr. Ich musste per nslookup zuerst die neue IP bestimmen und dann diese eingeben, da man eben nur die IP und nicht den Hostnamen angeben kann.


    Übrigens gehört Roving Networks mittlerweile zu Microchip, und man sollte sich die aktuellen Datasheets und User Guides unter http://www.microchip.com holen.


    Gruss
    Neni

    Hallo Robert,


    ich habe zwar einen kleinen Reflow Ofen für Rapid Prototyping (Protoflow E von LPKF) und einen elektronisch gesteuerten Pasten-Dispenser im Arbeitszimmer, aber ich bin in der Schweiz zu Hause. Das wird sich leider nur schon vom Hin- und Her-Geschicke wohl kaum lohnen (bzw. macht es wohl den ganzen Prozess dann zu teuer).


    Gruss
    Neni

    Ok, also für Servos gibt's z.Bsp. schon folgende, sehr gute Boards, welche per USB oder TTL Serial steuerbar sind:
    http://www.pololu.com/catalog/category/12
    Die Module lassen sich auch in Serie (bzw. an eine serielle Line) schalten und dann individuell pro Board oder pro Servo adressiert steuern. Am Besten kannst du einfach mal die umfangreiche Info auf den Produktseiten studieren, die Funktionalität der Servo-Controller ist immens.


    Für 7-Segment-Anzeigen habe ich zumindest mal auf Anhieb die folgenden seriellen Anzeigen (jeweils 4 Digits pro Anzeige) gefunden (untere Hälfte der Produktliste):
    https://www.sparkfun.com/categories/170
    Diese Anzeigen lassen sich per TTL Serial, SPI oder I2C ansteuern, und zwar alle Segmente inkl. DPs und Colon individuell.


    Das waren jetzt nur zwei Beispiele, es gibt sicherlich noch viele andere Controller auf den einschlägigen Maker-Seiten.


    Gruss
    Neni

    Irgendwie ist's aufgrund des Titels und des Textes ein Bisschen unklar, was genau du haben möchtest. Sollen Chips wie WS28x1/LPD8806 anstatt RGB-LEDs dann 7-Segment-Anzeigen und Servos steuern? Oder eher andersrum, geht es generell um Boards, welche sich möglicherweise ähnlich wie oben genannte Chips ansprechen lassen, aber eben 7-Seg. und Servos steuern können? Oder geht es dir vor allem um's Kommunikations-Protokoll der obigen Chips, und du möchtest z.Bsp. eine schon vorhandene Software, welche mit obigen Chips kommuniziert, auch zum Steuern von 7-Segs und Servos verwenden?


    Es gibt ja schon massenweise Servo- und 7-Seg.-Treiber-Chips und -Boards auf dem Markt oder auch entsprechende Anleitungen zum Selbstmachen. Du solltest deshalb eben vielleicht noch ausführen, was deine gewünschte Implementation speziell können muss bzw. ob an der Verschaltungs-Infrastruktur etwas besonders ist, was nicht schon durch bestehende Lösungen abgedeckt ist.


    Gruss
    Neni

    Hier noch mal eine Vereinfachung der Schaltung (die Lösung mit nur einem Monoflop):

    Die Bauteile sind in kleinen SMD-Gehäusen erhältlich, so dass sich das Ganze sehr platzsparend aufbauen lässt. Der 2G08er ist ein dual UND und der 1G32er ist ein single ODER. Beim 74LVC1G123 (single Monoflop) ist unbedingt die Version von NXP und nicht die von TI (SN74LVC1G123) zu nehmen, da nur die NXP-Version laut Datenblatt mit einer Threshold-Spannung von 0 auf 1 von max. 2,7 V (2,2 V typ.) bei 5 V Betriebsspannung spezifiziert ist. Die Schaltung ist für den SPI-Standardmodus 0 (CPOL=0, CPHA=0) ausgelegt. Die Schaltung hier ist auch noch etwas Timing-Sicherer als die Modifikation von Don Luigi oben und auch als meine mit dem 123er Monoflop, da auf jeden Fall keine 'falschen' Trigger enstehen können, selbst wenn durch widrige Umstände (längere Kabel, versch. Impedanzen etc.) der Pegelwechsel am MOSI mal VOR dem entsprechenden Pegelwechsel am SCK vom Monoflop erkannt wird (in meiner vorigen 123er-Schaltung waren da zur Vermeidung die zusätzlichen Gatter als Verzögerer drin). CS in dieser Schaltung selektiert analog zu der von Don Luigi bei High-Pegel. Für Testzwecke lässt sich die Schaltung natürlich auch mit 74AHCT123, 74AHCT08 und 74AHCT32 in DIP-Gehäusen auf einem Steckbrett aufbauen, wenn man die nicht benötigten Eingänge an Masse legt. Von Wired-OR- oder Wired-NAND-Konstrukten mit Transistoren oder MOSFETs und PullUp-Widerständen (einige kOhm) würde ich bei solchen Schaltungen (mit relativ schnellen/kurzen Timings) generell abraten, weil die Flanken-Zeiten asymmetrisch werden. Fallende Flanken sind schnell, steigende hingegen langsam (je nach der Summe der parasitären Kapazitäten), was zu Timing-Problemen führen kann.


    Ich kenne den Raspi nicht, weswegen ich nichts dazu sagen kann, ob er in der Lage ist, einen ausreichend stabilen Datenstream (Pausen < 50 µs) per SPI aufrecht zu erhalten. Aber viele ARM-µCs haben eingebaute DMA-Controller, welche auch Kanäle vom Speicher zur eingebauten Peripherie (wie SPI, UARTs etc.) anbieten. Hat der ARM im Raspi nicht auch sowas, was man dann ev. nutzen könnte? Dann müsste man 'nur' den jeweiligen Speicher-Block schnell mit daten füllen, der DMA würde dann für das stabile Befüllen des SPI sorgen.


    Gruss
    Neni

    Ach ja, auch nochwas, was die Doppeltrigger auslösen könnte:


    Wenn du den HC-Typ verwendest und SCK vom Raspi mit 3,3 V Pegel kommt, dann bist du ziemlich genau am Rande des Thresholds vom HC bei 5V (0,7 x 5 V = 3,5 V). Wenn dann beim Rechtecksignal bei den aufsteigenden Flanken aufgrund der Verkabelung noch etwas Überschwingen und Ringing auftritt, kann es eben durchaus zu Doppeltriggern aufgrund des Schwingens um den Thresholdwert herum bei kleinen Pulsweiten kommen (weil die Dauer des Ringings länger als die Pulsdauer ist). Mit dem HCT-Typ sollte das nicht mehr auftreten, da dort der Threshold mit ca. 2 V deutlich unterhalb der Schwing-Amplitude liegt. Auch deshalb ist hier ein HCT-Typ eigentlich unabdingbar.


    Gruss
    Neni

    Hallo Tom,


    schön dass es klappt :) .


    Pobier's doch mal auch noch so:

    Das übrig gebliebene XOR ist hier als nochmalige Verzögerungsstufe für MOSI geschaltet. Möglicherweise treten dann auch die Doppeltrigger nicht mehr auf, auch mit dem Drahtverhau. Übrigens ist die HC-Version durchaus kompatibel mit der HCT-Version, was das Timing betrifft. Die HCT-Version wird nur deswegen benötigt, damit die 3,3V-High-Pegel, die üblicherweise vom Raspi kommen, auch sicher als High erkannt werden, wenn die Schaltung bei 5V betrieben wird (was sie wegen der 5V am WS2811 ja auch sollte).


    PS: Wenn du Pusterla kennst, dann bist du sicher auch in/um-herum Zürich beheimatet :) .


    Gruss
    Neni

    Hier ist noch eine weitere, etwas komplexere Umsetzer-Schaltung, welche dafür aber 'rein digital' arbeitet, d.h. ohne irgendwelche Pulsweiten etc. analog einstellen zu müssen. Sie beinhaltet auch das von Irrlicht so sehr gewünschte ;) CS-Signal (Chip Select) in positiver Logik (1 = aktiv, 0 = deaktiviert):

    Das 16 MHz Taktsignal kann vom µC geliefert werden oder aber mit einem dieser kleinen 4-Pin-Quarzoszillatoren (gibt's in SMD oder through hole) erzeugt werden. Die Schaltung ist so wie gezeigt auf den Fast Mode des WS2811 ausgelegt. Für den Slow Mode verschiebt man die drei Verbindungen von den Zählerausgängen (74HC4024) zu den NAND-Gattern einfach eins höher, also anstatt Q1, Q2 und Q3 einfach entsprechend Q2, Q3 und Q4. Man kann es auf einer Leiterplatte auch mit 3 Auswahl-Lötbrücken oder 3 Auswahl-Jumpern realisieren, wenn man die Flexibilität der Mode-Umschaltung benötigt. Man könnte für den Slow Mode auch einfach ein 8 MHz Taktsignal (anstatt 16) nehmen, was ich aber weniger empfehlen würde, da die Zeitauflösung der Schaltung sinkt. Mit 16 MHz ist die maximale Variationsbreite der Pulsweite +/- 62,5 ns, mit 8 MHz wäre sie +/- 125 ns, was dann doch recht nahe an die im WS2811-Datenblatt spezifizierten max. +/- 150 ns rankommt.
    Für das 4-fache AND und das 4-fache NAND sollte man wirklich die angegebenen Typen verwenden, also AHCT, da diese deutlich schneller sind (A) und TTL-Pegel-Thresholds (T) haben (wichtig für 3,3 V Signale). Den Zähler (4024) gibt's 'nur' in HC, aber auch in HC kann er bei 5V im Minimum 30 MHz 'zählen'.


    Gruss
    Neni


    Ich habe hier mal die Schaltung mit dem 74HCT123(A) dual Monoflop gemacht, welches ja problemlos Pulsweiten bis unter 100 ns erzeugen können sollte. Nach gründlichem Studium des Datenblattes bin ich zum Schluss gekommen, dass man es trotz der im vorigen Post erklärten Zusammenhänge mit einer sehr einfachen Zusatzbeschaltung betreiben kann (nur XORs). Wichtig dabei ist, dass der SCK an den beiden Trigger-Eingängen bereits auf Low ist, bevor ein etwaiger Pegelwechsel am MOSI eine steigende Flanke an einem der /RD-Pins erzeugt. /RD triggert bei steigender Flanke nämlich nur dann auch selbst das Monoflop, wenn /A Low und B High ist. /A muss auf Low sein, damit B überhaupt triggert, also muss man darauf achten, dass an /RD nur dann eine aufsteigende Flanke entstehen kann, wenn B Low ist. Da der SPI ja im Mode Pegel 0, Phase 0 erst bei fallender SCK-Flanke den MOSI-Pegel ev. ändert (bei steigender SCK-Flanke wird dann beim Slave gesamplet), muss man 'nur' dafür sorgen, dass diese sicher etwas früher bei B ankommt, als ein etwaiger Flankenwechsel an /RD. Deshalb habe ich die XOR-Gatter nur bei den /RD-Eingängen eingeplant, nicht aber bei den B-Eingängen. Die Gatter sorgen dann für die paar ns Verzögerung, welche ein 'falsches' Triggern verhindern sollten.


    Gruss
    Neni