Banda led adresabil cu UCS1903

[nico_2010]

Ai reusit sa depasesti pag.122 din DS? Vezi ca la pag.125 exista explicatia rolului registrului SPCR. Ia citeste ce rol au bitii 1 si 0 din acest registru! 

RTFM si dupa aia comentati!

[informer]

Apropo de "RTFM" nici eu nu prea inteleg ce legatura au driverele integrate in banda aia si modul lor de comunicare seriala "inlantuita" cu SPI-ul si cu frecventa clock-ului acestuia.

Am scris si eu ca-i nevoie de un timing precis (de ex. +/-150ns pt. driverele despre care-i vb in postarea asta) dar afirmatia facea referire la duratele impulsurilor (conform cu "TFM"-ul driverelor /"led-urilor adresabile") nu cu altceva.

Mi se pare mult mai usor sa modifici nivelul pe un pin la timpi precisi (conform "TFM") decat sa folosesti ceva ce nu-i facut pt. asta... pana la urma ai si mai putin de citit... :D.

Da` ma rog, daca esti fan de librariile altora n-ai incotro... le folosesti pe alea care sunt si in general cum sunt... :|. 

[Bandi Szasz]

Si ce te faci cand ai sute de LED-uri ? sa modifici un pin precis inseamna ca trebuie sa dezactivezi toate interrupt-urile sa fi sigur ca nu iti da peste cap acei timp precisi care inseamna ca CPU-poate sta si pana la 50ms doar sa comande ledurile, dupa care trebuie sa se apuce sa calculeze din nou date pentru multe led-uri, de acolo nu mai iese nici o animatie fluenta. Aici intervine SPI care e hardware deci CPU nu are treaba, precalculezi datele intrun buffer pentru toate  ledurile si dupa aia dai drumu la SPI care consuma acel buffer si comanda ledurile fara nevoia CPU-ului si atunci in aia 50ms cat ii ia SPI-ului sa transmita toate datele CPU poate precalcula datele pentru urmatoarea secventa, cand SPI a terminat poate deja primii noul buffer sa se apuce din nou de treaba. Acei +/- 150ns nu sunt chiar atat de critici daca incerci pe partea de LOW poti fenta destul de mult si merge foarte bine. 

Editat Septembrie 12, 2018 de Bandi Szasz

[informer]

20 minutes ago, Bandi Szasz said:

Si ce te faci cand ai sute de LED-uri ? sa modifici un pin precis inseamna ca trebuie sa dezactivezi toate interrupt-urile sa fi sigur ca nu iti da peste cap acei timp precisi care inseamna ca CPU-poate sta si pana la 50ms doar sa comande ledurile, dupa care trebuie sa se apuce sa calculeze din nou date pentru multe led-uri, de acolo nu mai iese nici o animatie fluenta. 

NU am intentia sa discut in contradictoriu pe aceasta tema insa ma indoiesc sincer ca o sa obtii vreo animatie fluenta cu sute de LED-uri comandate de un 328 pe un pin de date SPI... nu de alta da i se cam termina RAM-u` .

I-adevarat ca nu stiu la ce animatie te referi insa am facut la un moment dat o estimare pt. cineva care dorea un panou realizat din astfel de benzi, pt. reclama.

Chiar la o rezolutie modesta raportata la un LCD uzual am ajuns la concluzia ca asta ar fi o aplicatie care s-ar preta mult mai bine la FPGA decat la "n" uC-uri si oricum redarea unei secvente "video" elementare (genul desen animat sacadat) e mai complicata decat pare la prima vedere.

Dar, daca nu ma insel, era vorba de 6 benzi cu 8 led-uri si alea in paralel, nu?

Editat Septembrie 12, 2018 de informer

[Bandi Szasz]

Ai perfecta dreptate pentru sute de LED-uri trebuie ceva mai serios nu un 328, am vrut doar sa scot in evidenta unde ar merge un SPI si de ce multi il folosesc,  la lungimi mari se pun in paralel si se folosesc uC uri cu 3-4 SPI-uri hardware care pot lucra independent unu-l de altul transferand datele la LED-uri simultan din buffere. Ca animatie m-am referit la orice efect de lumina, de exemplu deplasarea unui LED aprins (LED chaser), eu personal vad "fluent" adica nu mi se pare sacadat tot ce e sub 40-45ms, daca exista un delay mai mare inainte de deplasarea catre urmatorul LED mi se pare putin sacadat acel efect de lumini".  Eu m-am jucat un timp cu WS2812b si prin SPI am reusit sa comand aprox 900 de LED-uri cu refresh rate de aprox 35ms daca nu gresesc. Uc de comanda a fost un ESP WROOM 32 un uC destul de potent la 240Mhz cu RAM si ROM din belsug.