Umieszczam ten post w dziale Asemblera, gdyż póki co piszę w ASM.
Chciałbym podpytać Was o pewien aspekt użytkowania led WS2812. Nie oglądałem końcowych poradników Mirka o WS-Ledach, na forum Atnel też nic nie znalazłem, więc nie wiem czy temat był omawiany. Otóż rozchodzi się o takie zjawisko jak RESET CODE, czyli czas, który trzeba odczekać by ponownie odświeżyć WS-y. Z poradnika jak i z noty PDF WS2812 można dowiedzieć się, że ów czas wynosi >50us. System, do którego podpiąłem WS-y, składał się z 8 kanałów po 128 ledów/kanał (w sumie sterowanie 1024 ledami). Oczywistym jest, że aby wysłać paczkę informacji GRB, w moim przypadku trzeba przeznaczyć 30us*128led (ok 4ms/kanał) Tak się złożyło, że mój Systick, czy jak kto woli Heartbit systemu to 1ms, czyli zmuszony jestem zakłócić transfer z bufora do LEDów na rzecz sprzętowego przerwania co 1ms. Oto jak wysyłam bufor do WS2812 (w uproszczeniu):

Start:
cli;wyłączenie przerwań
rcall wyślij_kolor;GRB (24bity)
sei; zezwolenie na przerwanie
Rjmp Start

Czyli po wysłaniu koloru GRB (po ok 30us) zezwalam na wywołanie przerwania np. Systick.
Wg noty mam do 50us na dowolne działania, by ponownie powrócić do kontynuacji transferu, bez resetu transmisji do WS. I tu niespodzianka. Maksymalny czas na jaki mogę przerwać transfer to ok 5,5us, czyli ok 10 raz mniej niż podaje PDF WS2812. Gdy zwiększę czas przerwania >5, 5 us to zaczyna się „choinka” na Ledach, zamiast konkretnych sekwencji. Okazuje się, że nie tylko ja miałem z tym problem.
Software jest ok, ponieważ poszukałem po sieci i znalazłem :
http://wp.josh.com/2014/05/13/ws2812-ne ... know-them/

Czy Wy również mieliście taki problem?

_________________
Build:succeeded or up-to-date, 0 failed, 0 skipped

Jeszcze się namacalnie nie zetknęliśmy z tym problemem, aleśmy słyszeli.
Temu panu: http://cpldcpu.wordpress.com/2014/01/14/light_ws2812-library-v2-0-part-i-understanding-the-ws2812/ z pomiarów reset wyszedł ok 9us (Inne zależnośći czasowe też są ciekawe i odbiegają od danych z noty np. min. długość H dla zera 62.5ns)
Zmartwiłeś mnie, właśnie dłubię przy tych diodkach i cały czas zakładam, że trzeba się zmieścić w 9us (to i tak niewiele). Pomierzyłeś czas całego przerwania, z wywołaniem i powrotem?

_________________
+++++[>++++<-]>[>++++++<-]>.---------.+++.

Badałem reset przy podstawie 50ns/cykl, a więc z dosyć dużą dokładnością. Czas przerwania razem z wywołaniem i powrotem musiałem zapakować do max 5,6us - 5,7us, a więc jest to jescze mniej niż 9us podane w przykładzie. Używam WS2812B (4pin), niestety nie posiadam wersji 6pin, aby sprawdzić, czy wersja WS ma znaczenie. Pamiętam, że widziałem dokładniejsze badania tego zjawiska przez ludzi z Adafruit, ale jakoś nie mogę tego odnaleźć.

_________________
Build:succeeded or up-to-date, 0 failed, 0 skipped

No proszę, tutaj też im wyszedł Latch Time (low to latch LED colors) > 9370ns: http://hypnocube.com/2013/12/design-and-implementation-of-serial-led-gadgets/

_________________
+++++[>++++<-]>[>++++++<-]>.---------.+++.

Niestety muszę potwierdzić Twoje dane. Wyniki szybkiego i fragmentarycznego (ale chyba wystarczającego) testu są takie, że przy 5.5us diodki działają jak należy, przy 6us wyświetlanie się sypie. Mówię o dodatkowym czasie przedłużającym czas trwania bitu ponad standardowe 1.25us. Diody sześcionóżkowe (bez B w symbolu). Trochę słabo
No nic, trzeba się zadowolić tym co jest.
właściwie powinienem Ci podziękować, dzięki Tobie zaoszczędziłem sporo czasu i nerwów przy uruchamianiu projektu, bo całkowicie polegałem na podanym czasie ok. 9us. No niestety nie widzę batonka "pomógł".

_________________
+++++[>++++<-]>[>++++++<-]>.---------.+++.