Řetěz WS2811 s malým jednočipem, aneb tohle nepůjde

 Myšlenka byla původem docela jednoduchá. Někde v paměti ATtiny85 vyhradit videoram a periodicky z ní kopírovat data do LED, jenomže nic na světě není jednoduché a tohleto prostě nejde.

Maximální hodinový kmitočet, kterého s ATtiny85 dosáhnu, je 8MHz. Jistě, nechci tomu dávat externí krystal, protože v ten moment to ztrácí kouzlo jednoduchosti. Pokud se vyhnu skokům, dosáhnu jedné instrukce na takt, což v tomto případě znamená, že jedna instrukce bude trvat 125ns. Ono nějaké číslo ve stovkách ns vypadá, jako že je to prudce použitelné a ono v praxi také je, ovšem ne s čipem WS2811. Použití tohoto čipu vypadá jako veliká úleva, jenomže ona prostě není, po delším zkoumání jsem dospěla k závěru, že touto věcí si spíš nadělám do bot než že bych si pomohla, ony se totiž do toho tlačí data takovou docela zvláštní modulací.

V datasheetu si přečtete, že se tomu říká NZR, na což ale nikde nenajdete referenci, no a v podstatě jde o to, že náběžná hrana synchronizuje hodiny a časová poloha sestupné rozhoduje o tom, jestli se přenáší jednička, nebo nula. A rozdíl mezi požadovanou hodnotou pro jedničku a nulu je pouhých 200ns. Pokud si myslíte, že s WS2812 na tom budete trochu lépe, protože přenáší data pomaleji, vyvedu vás z omylu, v tomto případě je rozdíl 250ns, což vás nevytrhne, za tu dobu zvládne ATtiny85 udělat dvě instrukce, čili pokud chcete tu modulaci vyrábět softwarově, můžete leda počítáním instrukcí, no a i tak vás z toho bude bolet hlava, tudy prostě cesta nevede.

Já se tady ale chci zamyslet nad něčím jiným. Vzestupná i sestupná hrana je na reálném signálu nějak široká, přičemž ona je to nějaká varianta TTL, no, zkrátka, není to ECL, MECL, LVDS, nebo prostě něco diferenciálního, takže ona skutečná šířka pulzu docela silně vandruje s rozhodovací úrovní. Ono vám to nechá cca 100ns variabilitu, jenomže když se podíváte kde v čase bude rozhodovací úroveň mezi jedničkou a nulou, potom reálně nemáte ani polovinu. A protože do šířky pulzu se vám promítne jak náběžná, tak sestupná, pak vám, pokud chcete zaručit spolehlivou funkci, na náběžnou či sestupnou zbývá necelých 50ns. Náběžná hrana 50ns v praxi znamená šířku pásma alespoň 8MHz. A tohle prosím táhnete náhodným drátem na vzdálenosti v desítkách cm, no jistěže tohle nepůjde budit přímo výstupem procesoru a pochopitelně to bude dělat problémy.

Aby ta věc ale nebyla jednoduchá, tak rozhodovací úroveň H-L/L-H není stabilní, přesněji řečeno zvedá se s napětím na GND LED proti napětí na GND budiče, přičemž na tomto máte zase nějaké vedení, přes které jde napájení té LED a k dovršení děsu je to vylepšené o produkty PWM regulace jednotlivých LED.

Do toho všeho neexistuje způsob jak to zpomalit. Vy prostě tímto tempem a s touto přesností musíte nahrnout data do těch LED a pak to jednoduše nechat být. Takže pokud máte několik takových LED těsně u procesoru, máte nějaké větší AVR na 20MHz krystalu a můžete si dovolit občas na chvíli zastavit kompletně celý jeho přerušovací systém, pak pochopitelně nemáte problém. 

Pro moje potřeby to ale chce něco, co se přibrzdit dá, tj. má to oddělené hodiny a data, přičemž hodiny mají nějaký rozumný dolní limit.

Mimochodem, zajímalo by mne jak je tam udělaný daisychaining, ale v každém případě je jisté, že průchod tou LED zpomalí přeběh na hraně signálu. Ať už je to přemostěné, nebo se to znovu generuje. Takže čím víc LED v tom řetězu máte, tím strmější hranu musíte mít na jeho vstupu a tím přesněji musíte signál generovat. Takže s nějakým delším řetězem se radostně dostanete spíše do vyšších desítek MHz šířky pásma, což definitivně není nic pěkného a pochopitelně vám to nemálo namlátí. To, co já potřebuji, je řetěz prostorově dlouhý (řádově jednotky metrů) a s velkým počtem LED (cca 50ks). Definitivně vidím, že tudy cesta nevede a prostě se to musí udělat jinak.