Controller IC für digitale RGBW LED-Streifen

[Ingo F. (ingof)]

Hallo,

ich möchte über eine Platine mit Mikrocontroller digitale 
RGBW-LED-Streifen ansteuern (z.B. SK6812).

Dummerweise wäre mein Mikrocontrolle komplett ausgelastet nur das Signal 
für die RGBW-LEDs zu erzeugen.

Hatte mir überlegt einen Controller zu basteln der zwischen 
Mikrocontroller und RGBW-Streifen sitzen soll.

ALs erster Gedanke wäre mir ein Mikrocontroller mit Parrallel-Interface 
eingefallen.
Intern als den Speicherplatz für z.B. 256 LEDs (256*4Byte =1KByte).
Der Controller erzeugt dann permanent aus den Speicher das SIgnal für 
bis zu 256 LEDs.

Über den Parallel-Bus könnten die Farb-/Helligkeitswerte in den 
Controller geschrieben werden.


Der Vorteil:
Ich könnte relativ schnell über den Parallel-Bus die Daten in den 
Controller schaufeln und hätte dann den Mikrocontroller wieder frei für 
andere Sachen.

Hatte irgendwo ein ein ApplicationNote gefunden mit einem PIC dieses 
Signal erzeugt über den konfigurierbaren Logikblock. Kann sie allerdings 
nicht wiederfinden...

Besteht an soetwas interesse?
Gibt es sogar schon solche "Interface-Chips"?

[Torben K. (tokuhila)]

http://ww1.microchip.com/downloads/en/AppNotes/00001606A.pdf

[Marc V. (Firma: Vescomp) (logarithmus)]

Torben K. schrieb:
> http://ww1.microchip.com/downloads/en/AppNotes/00001606A.pdf

 LOL.
 Zitat aus dem PDF:

 State 2 is a high output for 120 ns ± 150 ns,
 followed by a low output for 130 ns ± 150 ns.

 Wie lange dauert denn (120ns - 150ns) ?

 Und auch der Rest ist sehr schön, nur ist nSDO beim PIC16F1509 nicht
 vorhanden.
 Kenne den PIC16F1509 kaum,  kann deswegen auch nicht sagen ob dieser
 Signal auch intern erzeugt werden kann oder ob man dazu ein extra
 NOT-Gatter braucht.
 Für mich nicht mehr als ein Reklame-Flyer.

[IngoF (Gast)]

Marc V. schrieb:
> Und auch der Rest ist sehr schön, nur ist nSDO beim PIC16F1509 nicht
>  vorhanden.

So wie ich das sehe wird kann dieses nSDO im CLC (Configurable Logic 
Cell) vorhanden (!SDO auf Seite 4)

Mir geht es auch nicht nur generell um diesen Lösung. Ich hatte eine 
Seite gefunden auf der 5 Lösungen für dieses Problem waren. Eines davon 
war Bit-Bang und eine andere Lösung war dieses ApplicationNote.

Es gibt auch wohl noch andere Lösungen:
http://hackaday.com/2014/09/10/driving-ws2812b-pixels-with-dma-based-spi/

Am besten wäre natürlich eine Lösung in der der Mikrocontroller nicht zu 
100% damit beschäftigt ist Das Signal zu erzeugen.

Und am besten kein SMD-Mikrocontroller mit >100 Pins.

Und mich würde interessieren ob es noch mehrere Leute gibt die an 
soetwas interessiert wären.

[AVR Spezi (Gast)]

Sowas wäre doch ideal für Dich geeignet:

http://www.led-genial.de/DIGI-DOT-Booster-WS2812-und-SK6812-ueber-SPI-Schnittstelle-ansteuern

Wird einfach über die SPI-Schnittstelle angesteuert und entlastet deinen 
Controller zu fast 100%.

[Ingo F. (ingof)]

AVR Spezi schrieb im Beitrag #4615349:
> Wird einfach über die SPI-Schnittstelle angesteuert und entlastet deinen
> Controller zu fast 100%.

Habe gerade mal zwei bestellt..

Was noch ein Problem sein könnte ist die Ansteuerung...

Dort stehen Sachen wie 256-Byte Befehlsspeicher und nach jedem Befehl 
2-4ms Warten.

Wenn ich jetzt für jede LED einen bestimmten Farbwert geben möchte sind 
bei RGBW 7 Byte notwendig. 256/7 = 36 LEDs?!

Oder kann mann mehrere 256-Byte Befehlspakete abschicken bis man den 
"Übernehmen"-Befehl schickt.

Bin mal gespannt wie das so klappt.
Werde dann mal berichten wenn ich damit herumgespielt habe.

Das kann aber noch etwas dauern...



Aber sehr wahrscheinlich müssen bei mir nicht alle LEDS eine Eigene 
Farbe bekommen. Die "Copy" und "Füllbefehle" werden bestimmt auch für 
meine Spielereien ausreichen...

[Ingo F. (ingof)]

So habe schon mal ein wenig herumgespielt.

Ich steuere die DigiDotBooster über einen PIC an und habe dahinter zum 
testen einen Meter RGBW-Schnur mit 30 LEDs/Meter und SK6812-LEDs.

Dummerweise scheinen die Datenblätter vom PIC und vom DigiDot-Booster 
fehlerhaft zu sein.

Beim PIC müssten eigentlick die Bits CKP und CKE auf Null sein um im 
SPI-Mode0 zu kommen. Das scheint wohl ein Standartmode zu sein den auch 
der DigiDot-Booster verwendet. Jedenfalls musste ich bei mir das CKE 
Bit auf 1 setzen damit es lief.

Beim SK6812-Datenblatt oder DigiDotBooster-Datenblatt scheint die 
Reihenfolge der Farben nicht so recht zu stimmen. Die DigidotBooster 
Anleitung widerspricht sich zumindest bei der Farbzuordnung selber.

Laut DigiDotBosster soll nach jedem Befehl dem DigiDitBooster 2-4 
Millisekunden Zeit geben die Befehle zu verstehen.
Bei mir sind aber meistens 7-10ms notwendig damit die LED auch wirklich 
hinterher leuchten.

Ob die ganze Warterei Probleme macht wenn ich eventuell bei >100 LED die 
Farbe selber setzen möchte wird sich noch zeigen.

Die Bedeutung der Status-LED habe ich auch nicht in der DigiDotBooster 
Anleitung nicht gefunden oder mehrfach übershen.

Nach Anschalten der Spannung leuchtet die LED für fast eine Sekunde und 
fängt dann relativ langsam an zu blinken. Wenn was bei der 
Initialisierung schief läuft scheint sie schneller zu blinken.
Wenn alles richtig geklappt geht die LED aus.

Poste hier einfach mal zwei Codeschnipsel die bei mir jetzt laufen.

#define BOOSTER_INIT        0xB1
#define BOOSTER_SHOW        0xB2
#define BOOSTER_SETRGB      0xA1
#define BOOSTER_SETRGBW     0xA2
#define BOOSTER_SETHSV      0xA3
#define BOOSTER_SETLED      0xA4
#define BOOSTER_SETALL      0xA5
#define BOOSTER_SETRANGE    0xA6
#define BOOSTER_SETRAINBOW  0xA7
#define BOOSTER_SHIFTUP     0xB3
#define BOOSTER_SHOFTDOWN   0xB4
#define BOOSTER_COPYLED     0xB5
#define BOOSTER_REPEAT      0xB6
#define BOOSTER_RGBORDER    0xC1

void sendSpiLed(int data) {
    SSPBUF=data;
    while(!SSPSTATbits.BF);
}

    LATCbits.LATC1 = 1; //Disable !CHipSelect
    //SPI-Bus initialisieren mit 10MBit/s
    TRISC &=11010101;   //clear: TRISC<5> for SDO and TRISC<3> for SCK. TRSIC<1> for CS
    SSPSTAT = 0x40;     //  Set SMP=0 and CKE=1.
    SSPCON1 = 0x20;     // Enable SPI Master with Fosc/4)
//    SSPCON1 = 0x22;     // Enable SPI Master with Fosc/64

    // send command block 1
    LATCbits.LATC1 = 0; // enable Chip Select
    sendSpiLed(BOOSTER_INIT);
    sendSpiLed(12);   // 12LED 
    sendSpiLed(32);   // 32 Bits (RGBW))           
    LATCbits.LATC1 = 1; // Disable Chip Select
    wait_1ms(7);

    // send command block 2
    LATCbits.LATC1 = 0; // Disable Chip Select
    sendSpiLed(BOOSTER_RGBORDER);   //  for SK6812(RGBW)
    sendSpiLed(0x02);      // IDX_R
    sendSpiLed(0x03);      // IDX_G
    sendSpiLed(0x01);      // IDX_B
    wait_1ms(10);
    sendSpiLed(BOOSTER_SETRGBW);   // 
    sendSpiLed(0xff);   // R
    sendSpiLed(0xff);   // G
    sendSpiLed(0xff);   // B
    sendSpiLed(0xff);   // W  
    sendSpiLed(BOOSTER_SETALL);  
    sendSpiLed(BOOSTER_SHOW);
    LATCbits.LATC1 = 1;

[Ingo F. (ingof)]

Was ich noch schön fände wenn die letzte Konfiguration im DigiDotBooster 
"gespeichert" würde.

Also Spannung anlegen und alle LED gehen auf eine bestimmte Farbe und 
Helligkeit. Also z.B. Weiß 50%. Oder die letzte Einstellung der LED 
würde gespeichert bleiben.

Aber dafür ist der DigiDotBooster ja auch nciht gedacht.

Auch wäre es schön wenn mann mehr als 256 LEDs ansprechen könnte. Vom 
selben Mikrocontrolle gibt es zumindest noch einen mit doppelt so viel 
Speicher.

Vielleicht wäre es auch ganz schon zumindest den Speicher der 256 LEDS 
für z.b. 512 oder 1024 Leds zu verwenden.
Also z.B. DIe Farbe der LED1 wird für LED 1-4 verwendet. Der Farbwert 
der LED2 für LED 5-8.

Werde vermutlich meine 5Meter leuchtschlauch in der Mitte aufteilen und 
jeweils mit einem DigiDotBooster die Hälften getrennt steuern.

[Ingo F. (ingof)]

Also für einen Leuchtstreifen mit 150 Leds kann ich über den 
Digidot-Booster in 6ms die Farben für alle LEDS setzen. Also wenn die 
eingebauten Funktionen nicht ausreichen kann ich eben alle LEDS selber 
ansteuern.

Es gibt zwar Sachen die ich in den DigiDot-Booster oder eine 
selbstgebaute Platine einbauen würde.

Aber dafür lohnt sich der Aufwand nicht.

In der Zukunft nehme ich dann einen LED Streifen mit AP102 Chip.

Der kann über SPI mit bis zu 32MHz gesteuert werden und das Timing ist 
unwichtig. Nicht so wie bei meinem RGBW-Streifen mit SK6812 CHip.

Bei den LED mit APA102(C) wirde keine Controllerplatine benötigt.

Das Thema hat sich für mich dann erledigt...

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Ingo F. schrieb:
> Das Thema hat sich für mich dann erledigt...
>
Für mich beginnt dieses Thema erst ;-)

Hallo zusammen,

da ich mich zur Zeit auch mit RGBW-Stripes mit SK6812 IC interessiere, 
bin ich auf diesen Thread gestossen. Mittlerweile besitze ich ich vier 
käuflich zu erwerbende LED-Stripe-Controller. Ein RF Remote Control 
basierender für einfarbige 12V Stripes aus China, der leider an einem 
5m-Stripe, der ca, 2,2A aufnimmt total versagte und es schon ein Problem 
war den zum Laufen zu bekommen, da die fehlende Batterie bzw. deren 
Schublade genau anders herum einzuschieben war. Danach gab es Dauerlicht 
und die Dimmfunktion erzeugte nur ein kurzes flackern genau wie der 
ON/OFF Button. Die 12A Peak die angegeben waren dürften wohl bei dem 
Litzenquerschnitt für den Atto-Sekundenbereich angegeben worden sein 
;-).

Einen Kabelgebundenen für Digital-Stripes SK6812 usw. ( Digi-Dot-Starter 
von DIAMEX ) der seinen Dienst tut, einen China für 12V RGB-Stripes per 
IR Remote, der ebenfalls seinen Dienst tut und einen weiteren China 
Digital-Stripe Controller auf RF Remote Basis deren Fotos zu sehen sind 
( SP103E ). Leider bedient dieser nicht wie angegeben das SK6812 IC 
sondern das WS2812B IC. Diese drei habe ich jedoch nur an Test Stripes 
( max 6 LEDs ) laufen.

Was mir an allen missfällt sind die vorhandenen Programme. Daher suche 
ich etwas auf ATMEL AVR Mikrocontroller basierendes, um darauf andere 
Programme flashen zu können, da ich mich weigere zu glauben, das die so 
etwas als TSSOP 20 Pin Typen nicht auch bewerkstelligen können. Die Idee 
ist die Mainstream ARM Cortex-M0 Value MCU with 16Kbytes Flash und 48MHz 
CPU ( STM32F030F4 ) auf dieser Platine durch einen ATMEL AVR 
Mikrocontroller zu ersetzen.

Vorerst die wichtigsten Fotos.

Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Hat hier schon jemand einen auf dem SK6812 IC basierenden 
RGBW-Digital-Stripe-Controller in ATMEL AVR-Assembler geschrieben und 
ist bereit den Quellcode hier rauf zu laden ?

Bernd_Stein

[ingof (Gast)]

Bernd S. schrieb:
> ...auf dem SK6812 IC basierenden RGBW-Digital-Stripe-Controller
> in ATMEL AVR-Assembler geschrieben
>
> Bernd_Stein

Bernd S. schrieb:
> Was mir an allen missfällt sind die vorhandenen Programme. Daher suche
> ich etwas auf ATMEL AVR Mikrocontroller basierendes, um darauf andere
> Programme flashen zu können
> Bernd_Stein

Als erste Idee würde mir kommen einfach den vorhandenen DigiDot-Starter 
zu nehmen und neu zu programmieren.

Eventuell wäre es auch sinnvoll auf C umzusteigen. Habe mich auch immer 
geweigert auf C umzusteigen und habe mich hinterher gewundert warum ich 
das nicht früher gemacht habe... (wurde "gezwungen" ;-))

Auch wenn dafür eigentlich Assembler wohl schon ausreichend ist. Mein 
Testprogramm iat aja auch nichts anderes als Assembler

Das Problem ist meistens dass viele Controller schon zu fast 100% 
ausgelastet sind und dann nicht wirklich großartig viel andere Aufgaben 
erledigen können. Leichte verzögerung bei dem Protokoll führen zu einem 
Reset und dann flackert und blinkt es nur wild.

Bernd S. schrieb:
> der leider an einem
> 5m-Stripe, der ca, 2,2A aufnimmt total versagte

Mein 5M-Streifen hat 150 LED (30/Meter) und benötigt bei voller 
Beleuchtung  etwa 8 Ampere (etwa 60mA pro LED??). Was bei mir geholfen 
hat war entweder nur die ersten 10 LEDS zu benutzen oder halt die 
Helligkeit der LEDS stark zu "dimmen" dass der Strom ausreichte. Der 5 
Meter Streifen benötigt etwa 150mA für die Logik.

Ich habe mich dazu entscheidene den DigiDotBosster über meinen 
Controller anzusteuern. Auch ein komplettes setzen der einzelnen LEDs 
über den DigiDot Bosster geht relativ schnell.

[c-hater (Gast)]

ingof schrieb:

> Eventuell wäre es auch sinnvoll auf C umzusteigen.

[...]

> Das Problem ist meistens dass viele Controller schon zu fast 100%
> ausgelastet sind und dann nicht wirklich großartig viel andere Aufgaben
> erledigen können.

Das ist der Brüller. Wenn's bei der Performance klemmt, empfiehlst du 
den Umstieg auf die ineffizentere Sprache...

> Leichte verzögerung bei dem Protokoll führen zu einem
> Reset und dann flackert und blinkt es nur wild.

Jepp. Und wenn man das nicht will, nehmen halt manche C (und eine 
fetteren Controller oder gar noch einen zweiten dazu) und die Asm-Leute 
kitzeln halt einfach die angeblich "fehlende" Leistung aus der 
vorhandenen Hardware...

Ein Lösung, die 1024 WS2812B-LEDs kontinuierlich mit 30Hz Framerate 
ansteuern kann (und dabei ca. 45% der Rechenzeit für "anderes" über 
lässt!), habe ich hier bereits gepostet. Sollte sich ohne allzu grossen 
Aufriss auf die RGBW-Geschichte der SK6812 umfummeln lassen. Wenn man 
denn wirklich Assembler kann...

Aber natürlich wird die mögliche Framerate um 33% sinken müssen, da ja 
für RGBW 33% mehr Daten über den "Bus" zu jagen sind. Bei den 
gewünschten 256 LEDs käme man aber auch dann immer noch auf ca. 80Hz 
Framerate. Auf den Anteil freier Rechenzeit würde die Änderung übrigens 
(nahezu) keinen Einfluss haben, der bliebe fast unverändert bei ca. 45%.

[ingof (Gast)]

c-hater schrieb:
> Das ist der Brüller. Wenn's bei der Performance klemmt, empfiehlst du
> den Umstieg auf die ineffizentere Sprache...

Ja, bei genauerem nachdenken ist das grober unfug ;-)

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

ingof schrieb:
> Als erste Idee würde mir kommen einfach den vorhandenen DigiDot-Starter
> zu nehmen und neu zu programmieren.
>

Wenn die einen ATMEL-AVR-µC dafür benutzt hätten, würde ich dies 
sicherlich versuchen, aber leider ist dort ein ARM irgendwas verbaut.
Die Programmiersprache C wird oft empfohlen. Ich möchte aber erstmal 
Assembler beherrschen, da ich keinen externen Zwängen unterworfen bin 
;-).

>
> Ich habe mich dazu entscheidene den DigiDotBosster über meinen
> Controller anzusteuern. Auch ein komplettes setzen der einzelnen LEDs
> über den DigiDot Bosster geht relativ schnell.
>

So etwas möchte ich vermeiden, extra ein Baustein bzw. Modul zu kaufen, 
welches nicht nötig ist, da ich denke das ein ATMEL-AVR-µC mittels 
Timer/Counter1 ( 16Bit ) in einem geeigneten Modus fast autark ein 
PWM-Signal erzeugen kann ( nach Übergabe der Parameter ohne weitere 
Softwareeinmischung ).
Die Ansteuerung des SK6812 scheint ja nichts anderes zu sein, als ein 
PWM-Codiertes Verfahren, um die logischen Zustände 0 & 1 diesem IC 
mitzuteilen, die dazu dienen die unterschiedlichen Helligkeitswerte der 
vier Farben zu erzeugen ( Rot, Grün, Blau und Weiß ).

c-hater schrieb:
> Ein Lösung, die 1024 WS2812B-LEDs kontinuierlich mit 30Hz Framerate
> ansteuern kann (und dabei ca. 45% der Rechenzeit für "anderes" über
> lässt!), habe ich hier bereits gepostet.
>

Mit hier meinst du wahrscheinlich Mikrocontroller.net. Wo denn genau - 
konnte hier nichts von dir finden ?

https://www.mikrocontroller.net/forum/codesammlung?filter=ws2812b&x=0&y=0

>
> Bei den gewünschten 256 LEDs käme man aber auch dann immer noch auf ca.   80Hz 
> Framerate.
>

Von meiner Seite sind 300 LEDs gewünscht ( 5m Stripe mit 60LEDs/m ).

Ist ein Frame das Senden der acht Bytes pro Farbe ( 32Bit ) plus 
Pausenzeiten ?

Wie errechnest du die Framerate und wie ermittelt man die Auslastung 
bzw. Rechenzeit des µC ?

Bernd_Stein

[Stefan R. (kroko)]

Marc V. schrieb:
> Torben K. schrieb:
>> http://ww1.microchip.com/downloads/en/AppNotes/00001606A.pdf
>
>  LOL.
>  Zitat aus dem PDF:
>

>  State 2 is a high output for 120 ns ± 150 ns,
>  followed by a low output for 130 ns ± 150 ns.
>

>
>  Wie lange dauert denn (120ns - 150ns) ?
>
>  Und auch der Rest ist sehr schön, nur ist nSDO beim PIC16F1509 nicht
>  vorhanden.
>  Kenne den PIC16F1509 kaum,  kann deswegen auch nicht sagen ob dieser
>  Signal auch intern erzeugt werden kann oder ob man dazu ein extra
>  NOT-Gatter braucht.
>  Für mich nicht mehr als ein Reklame-Flyer.

Wenn man diese AppNote gelesen hat, dann weiß man, dass keine 
zusätzlichen Gatter benötigt werden. Dieser PIC und viele andere haben 
diese integriert (CLC).

Abgesehen davon ist dieses Feature auf uC.net dokumentiert.

Mit dieser internen Verschaltung hat man das Interface in Hardware und 
braucht nur den SPI mit den Daten füttern.

[c-hater (Gast)]

Bernd S. schrieb:

> So etwas möchte ich vermeiden, extra ein Baustein bzw. Modul zu kaufen,
> welches nicht nötig ist, da ich denke das ein ATMEL-AVR-µC mittels
> Timer/Counter1 ( 16Bit ) in einem geeigneten Modus fast autark ein
> PWM-Signal erzeugen kann

Das kann er sicher. Nur brauchst du für WS2812B und auch für SK6812 
überhaupt kein PWM-Signal. Die PWM machen die Dinger nämlich selber. Was 
sie brauchen, sind die Steuerdaten für ihre PWM. Und diese Steuerdaten 
sehen zwar fast aus wie PWM, haben aber mit der eigentlichen PWM rein 
garnix zu tun. Ist mehr sowas wie ein serielles Datensignal auf einem 
phasenmodulierten Träger.

Das Problem ist, dass man ziemlich schnell ziemlich viele von diesen 
Steuerdaten absondern muss (selbst wenn die Framerate unwichtig ist ist 
das so) und obendrein das Timing der Steuerdaten sehr eng ist.

Ja, man kann das Steuersignal tatsächlich auch mit einem Timer im 
PWM-Modus erzeugen, aber ein PWM-Zyklus entspricht nur genau einem 
Datenbit des seriellen Datenstroms.

> Die Ansteuerung des SK6812 scheint ja nichts anderes zu sein, als ein
> PWM-Codiertes Verfahren, um die logischen Zustände 0 & 1 diesem IC
> mitzuteilen

Du hast das Prinzip der Ansteuerung dieser Dinger offensichtlich absolut 
nicht begriffen.

> Mit hier meinst du wahrscheinlich Mikrocontroller.net. Wo denn genau -

Genau hier im Forum. Stichwort WS2812.

> Ist ein Frame das Senden der acht Bytes pro Farbe ( 32Bit ) plus
> Pausenzeiten ?

Ein Frame ist komplette Datenübertragung an alle LEDs + Pausenzeit für 
Sync.

Diese Pausenzeit ist bei naiven Implementierungen (egal ob per 
Bitbanging oder per Timer-PWM) die einzige Zeit, in der dein µC Zeit 
hat, etwas anderes zu tun, weil er während der Datenübertragung vollauf 
allein damit beschäftigt ist.

Immerhin kann man die Pausenzeit beliebig lang ausdehnen (natürlich zu 
Lasten der möglichen Framerate). Das liegt eben daran, das die LEDs sich 
ihre PWM selber machen. Wenn sie erstmal ihre Steuerdaten haben, halten 
sie ihre Farbe beliebig lange bei.

Aber die Daten müssen für die gesamte LED-Kette in einem Rutsch 
übertragen werden, darin dürfen keine weiteren Pausen entstehen, sonst 
kommt nur noch Gurkensalat bei den LEDs an.

> Wie errechnest du die Framerate

                      1
----------------------------------------------
Bitdauer * Bytes/LED  8  nLEDs + Pausendauer


> und wie ermittelt man die Auslastung
> bzw. Rechenzeit des µC ?

Verstehen, was passiert, Takte zählen und rechnen.

[Ingo F. (ingof)]

c-hater schrieb:
> Genau hier im Forum. Stichwort WS2812.

Sorry, aber nicht falsch verstehen...
Aber man kann nicht wirklich erwarten dass jemand mikrocontroller.net 
komplett auswendig kennt.
Und bei der Suche von WS2812 kommen genau 618 Threads bei mir.

Denke da wäre schon ein Link angebracht oder ein vernünftiger 
Suchbegriff.


Bernd S. schrieb:
> Wenn die einen ATMEL-AVR-µC dafür benutzt hätten, würde ich dies
> sicherlich versuchen, aber leider ist dort ein ARM irgendwas verbaut

Kenne den ARM selber nicht. Aber der wird auch wohl Assembler können.
Das hat den Vorteil dass man keine neue Schaltung entwickeln muss.
Ist eventuell nicht soooo einfach wie man denkt. Habe ich gemerkt als 
ich die Möglichkeit haben wollte das Signal zu den LED-Chips zu 
unterbrechen (LED-Chip mag kein Eingangssignal ohne Versorgungsspannung.
Beitrag "Re: Signal für LED-Streifen elektr. unterbrechen"

c-hater schrieb:
>> und wie ermittelt man die Auslastung
>> bzw. Rechenzeit des µC ?

Also bei 300 LEDs werden etwa 9ms benötigt um alle Farben einmal 
komplett zu übertragen.

Wenn Du z.B. 30Hz Refreshrate haben möchtest hast Du dann ja 24ms Zeit 
andere Sachen zu machen.

Wenn Du die restlichen Tätigkeiten des AVR immer für 9ms komplett 
unterbrechen kannst spricht ja nichts dagegen.

Oder eben irgendeine Hardware die das erzeugen der Signale für Dich 
übernimmt. Aber dann hast ja eigentlich wieder einen anderen Chip neben 
dem AVR. Oder bist auf die wenigen PICs beschränkt die Das Siganl 
erzeugen können.

Beim dem PIC wird dann dadurch der MSSP "verbruacht" und dann ist hast 
Du dann nur noch einen USART (beim Standalone-Player ja kein Problem)

Diese Harware verschafft wir dann etwa 12us Zeit bis du das nächste 
Datenbyte schicken musst.

Vielleicht wäre der

Bernd S. schrieb:
> Was mir an allen missfällt sind die vorhandenen Programme. Daher suche
> ich etwas auf ATMEL AVR Mikrocontroller basierendes, um darauf andere
> Programme flashen zu können, da ich mich weigere zu glauben, das die so
> etwas als TSSOP 20 Pin Typen nicht auch bewerkstelligen können.

Vielleicht wäre ja auch ein LED-Player was für Dich. Habe mal einen 
LED-Player-S2 von Diamex zum spielen gekauft.

Mit der entsprechenden Software kannst Du Dir Deine eigenen Lichteffekte 
zusammen basteln auf die SD-Karte schieben und über die Tasten am Player 
durchschalten.

Allerdings ist man dann wohl noch auf die "Farbmischung" für das Weiß 
angewiesen. Die TPM2-Datei unterstützt nur drei Farben und das Weiß wird 
aus en drei Farben "berechnet". Auch nicht soooo toll finde ich dass 
dort mit der Firmware auf meinem Blayer immer etwas weiß beim Blau 
zugemischt wurde. Außerdem war 100%Rot als komplett weis definiert. Kann 
sein dass sich das inzwischen durch neuere Firmware geändert hat.

[Patrick J. (ho-bit-hun-ter)]

Hi

Bernd S. schrieb:
> Ist ein Frame das Senden der acht Bytes pro Farbe ( 32Bit ) plus
> Pausenzeiten ?

Meinem Verständnis nach dürfen beim Senden KEINE Pausen integriert 
werden, da nach der Pause ALLE LED den dann enthaltenen Wert übernehmen.

Habe die LED-Streifen (WS2812) bisher aber nur hier - über 'streicheln' 
bin ich noch nicht hinaus :)

Der 'Frame' wird hier der Datenstrom an ALLE LEDs sein, also bei Dir 
300x8bit im unteren µs-Raster/oberen ns-Raster, wenn ich mich recht 
Erinnere.
Erst durch eine Pause, laut Forum aber WESENTLICH kürzer als im 
Datenblatt angegeben, werden die Werte übernommen und die LED erstrahlen 
in neuer Farbe.

MfG

[c-hater (Gast)]

Ingo F. schrieb:

> Also bei 300 LEDs werden etwa 9ms benötigt um alle Farben einmal
> komplett zu übertragen.

D.h.: du hast 9ms, in denen du auf garnix anderes reagieren kannst. Das 
ist das technische K.O. für sehr viele Anwendungen. Nur ein Beispiel: 
IR-Empfang.
Bedenke: du weisst nicht, wann genau ein IR-Kommando kommen wird...

[Robin S. (der_r)]

Nur aus Interesse: Was spricht denn dagegen, auch in der eigenen 
Steuerung z.B. einen STM32F1 zu nehmen unddas ganze via DMA zu machen?

[Robin S. (der_r)]

Nur aus Interesse: Was spricht denn dagegen, auch in der eigenen 
Steuerung z.B. einen STM32F1 zu nehmen und das ganze via DMA zu machen?

[Ingo F. (ingof)]

c-hater schrieb:
> D.h.: du hast 9ms, in denen du auf garnix anderes reagieren kannst.
Man kann schon, aber man hat eben nicht viel Zeit dafür. Mann muss eben 
alle x00 ns eben den Ausgang für die Kommunikation mit den LED-Chips 
setzen.

Es sei denn irgendwelche Hardware nimmt das einem ab...

[Patrick J. (ho-bit-hun-ter)]

Hi

Dann müsste man doch nur einen entsprechend schnell getakteten µC per 
CTC die Bits rauswerfen lassen.
In der Zwischenzeit, wo also der CTC beendet und noch nicht erneut 
aufgerufen wurde, kann der µC der normalen Arbeit fröhnen.

Wobei der CTC-Interrupt recht weit hinten sitzt, wäre blöd, wenn ein 
IR-Kommando empfangen wird und der PC-INT bevorzugt wird - dann ist das 
Leuchtmuster matsch.

MfG

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

c-hater schrieb:
> Genau hier im Forum. Stichwort WS2812.
>
Ich hab's gefunden, aber weiß noch nicht einmal wie ich es mir im ATMEL 
AVR-Studio ansehen kann. Bekomme immer eine Fehlermeldung, wenn ich die 
.aps über File => Open => File öffnen möchte. Wahrscheinlich, weil das 
Studio auf einer anderen Festplattenpartition installiert ist, wie der 
Download der .zip -Datei wo sich unter anderem die BlinkingLights.aps 
befindet. Für mehr habe ich jetzt leider keine Zeit.

Beitrag "The secret of WS2812B"

Bernd_Stein

[c-hater (Gast)]

Bernd S. schrieb:

> Ich hab's gefunden, aber weiß noch nicht einmal wie ich es mir im ATMEL
> AVR-Studio ansehen kann.

Installiere dir lieber das AVR-Studio 4.19. Ist für 
Assembler-Entwicklung sowieso besser geeignet. Du kannst es problemlos 
auch parallel zum Atmel-Studio installieren, die beiden kommen sich 
nicht in's Gehege.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Nachdem ich nun auch das AVR-Studio 4.19 Build 730 von hier 
heruntergeladen und installiert hatte und auch hiermit die Dateien nicht 
öffnen konnte, weil nun die Fehlermeldung lautete: " es wäre keine 
AVR-Studio Datei".
Hab ich den Fehler lokalisieren können. Und zwar waren die Dateien nicht 
100% entpackt, was sich mit Zip-Ordner anwählen und Mausklick rechts => 
Alle extrahieren - beheben lies.

https://www.mikrocontroller.net/articles/Atmel_Studio#Downloads


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Den ARM-µC im TSSOP-20 Gehäuse gegen einen ATMEL-AVR-µC zu tauschen 
würde theoretisch mit einem ATtiny261/461/861 verkehrt herum, wo noch 
Vcc und GND zu vertauschen wären oder mit einem ATtiny87/167 richtig 
herum, wo jedoch auch Vcc und GND zu tauschen wären möglich.

Praktisch müsste man allerdings erst die weiteren Verbindungen der Pinne 
des ARM auf der X-lagigen Platine herausfinden, wobei man schon den 
Schaltplan teilweise erstellt.

Ich denke ich konzentriere mich jetzt erstmal auf das Assembler 
programmieren mit hilfe dieses Kurses :

http://www.weigu.lu/tutorials/avr_assembler/index.html


Bernd_Stein

[c-hater (Gast)]

Bernd S. schrieb:

> Den ARM-µC im TSSOP-20 Gehäuse gegen einen ATMEL-AVR-µC zu tauschen
> würde theoretisch mit einem ATtiny261/461/861 verkehrt herum, wo noch
> Vcc und GND zu vertauschen wären oder mit einem ATtiny87/167 richtig
> herum, wo jedoch auch Vcc und GND zu tauschen wären möglich.

Warum musst du unbedingt nur den IC ersetzen? Wirf doch die ganze 
Platine raus und mache eine neue.

Übrigens gibt es Beschränkungen für die Anwendbarkeit meines Codes. Er 
braucht unweigerlich eine SPI-fähige UART. Die von dir genannten Tinys 
haben aber allesamt nichtmal eine UART. Also unbrauchbar für den Zweck.

> Praktisch müsste man allerdings erst die weiteren Verbindungen der Pinne
> des ARM auf der X-lagigen Platine herausfinden

Das kannst du dir schenken, wenn du sie einfach komplett ersetzt. Das 
ist kein Verlust. Das aufwendigste (die Stromversorgung für die LEDs) 
ist sowieso nicht mit auf der Platine und von dem 
Funk-Fernbedienungskram auf der Platine wirst du mangels Dokumentation 
wohl auch eher nicht profitieren können. Es sei denn, du wärest zu 
reverse engineering in der Lage, was ich kaum annehmen würde...

Also weg mit dem ganzen Kram!

> Ich denke ich konzentriere mich jetzt erstmal auf das Assembler
> programmieren mit hilfe dieses Kurses :
>
> http://www.weigu.lu/tutorials/avr_assembler/index.html

Das kann niemals schaden. Als Einstieg. Richtig lernen tut man 
Assemblerprogrammierung (oder ganz allgemein: Programmieren) aber nur 
dadurch, dass man es selber tut.

Wenn du also glaubst, dass dich allein die Lektüre dieser 
Kursunterlagen zu einem guten oder auch nur brauchbaren 
Assemblerprogrammierer macht: Das kannst du ganz getrost knicken...