Igen, most hogy írta megnéztem.

Akkor lehet a legegyszerűbb lenne a szoftveres megoldás. Azt írtad fentebb hogy 6 utasítás ideje áll rendelkezésre bitenként. Szerintem akkor ez jó lehet:

Így elvileg pont 6 utasításciklusnyi idő telik el minden egyes bitbeállítás közt. És mindegy hogy 00, 01, 10 vagy 11 követik egymást. Persze a WREG-et cseréld ki annak a bájtnak a nevére amire akarod. Ja és természetesen a rutin lefutásának idejére a megszakításokat tiltani kell!

Mondjuk ha ezt kiegészíted mind a hét bitre, aztán egymás alá másolod 60*3-szor akkor elég hosszú lesz és amíg fut addig nem tudsz semmi mást csinálni a mikrovezérlővel de sajnos ez van.

1. a goto és a btfss nem 1 utasítás
2. nem proba volt, aki a kérdést feltette.
3. nekem nem kell bebizonyítanod, milyen...

Láthatóan működik SPI-vel is, neked milyen probléma volt vele?

1. Nem mondod?! Tényleg? Ezt eddig is tudtam. És akkor mi van ha nem egy utasítás?
2. Valóban, elnézést a figyelmetlenségemért!
3. Nem próbáltam neked bizonyítani semmit, de még csak nem is írtam neked semmit...

1. találd ki
2. ...
3...izzadságszagú az előzmények után...

Igazából amikor láttam, hogy plusz időt pakol bele, valamint 16Mhz-n eléggé necces kiszolgálni, úgy döntöttem a tisztán szoftveres megoldást választom.Ami elég egyszerűnek tűnt, és működött, így mivel csak játék volt egyenlőre, nem is próbáltam SPI vel.

A plusz idő biztosan ott van, de ez egy határon belül nem okozhatna elvileg gondot. Kiszolgálni sem annyira időigényes, csak egy mov. Az indirekt címzés itt is jól használható lenne. Még C-ben is meg lehetne írni gyorsnak.
Jelen esetben nem azt akarom mondani, hogy a megoldásod nem jó, csak azt, hogy érdemes lenne sooty-nak kipróbálni az SPI-t. Ha nem megy, akkor marad a szoftveres. Amit ő használ, az is működhet és a tiéd is ötletes a shiftekkel. Az SPI azért lenne jó, mert több idő maradna másra(bár ez nem sok) és kicsit egyszerűbb.

Lehet rosszul álltam hozzá , én SPI vel a data outon akartam kiküldeni a soros adatokat, így kb 0,3 v 0,2 byte-onként kellett volna újra tölteni ( 1 bit egy 3 v 4 SPI órajel) 16mhz esetén a SPI sebessége az órajel/4 kell legyen így egy újra töltésre kb 8 utasítás jut, ez alatt kellett volna kiszámolnom az új értéket, ami szerintem hasonló időzítési problémákba ütközött volna, bár nem használta volna el az egész portot.De csak egy csík kipróbálására készült, így nem számított semmi.

Az SPI egy bájtot kijuttat, majd a következőt. El se tudom képzelni, hogyan lehetne ezt "megerőszakolni" bájtnyi időn belül, de szerintem nem is kell.
Ha előre megírt képet akarsz kivinni, az a memóriában megtalálható, csak rá kell állni, áttölteni az SSPBUFF-ba.
Ha ki kell számolni egy változó véletlenszerű változást, akkor azt ki lehet számolni két kivitel között, letenni memóriába, majd áttölteni. Ha több LED-et használsz, azt is ki lehet számolni előre, majd kivinni. A kiszámolás időtartama mindenképpen meghatározó idő, közben nem változik a kép így se, úgy se, de ez olyan rövid idő lehet, amit a szem folyamatos változásnak lát. Én így látom.
Egyébként szerintem nem offolunk, nem kell offba tenned a válaszod...

Rendben, megpróbálom kitalálni!
Azt írod, hogy a goto az nem egy utasítás. Ez pontosan így van, nem egy hanem kettő darab utasítás. De miért írod ezt le nekem? Nyilván azért mert szerinted emiatt nem jó a program amit fentebb bemásoltam. Vagyis nem 6 utasításciklus alatt történik a PORTC,0 változtatása. Erre próbáltál utalni? Nos a szimuláció szerint nálam pont 6 utasításnyira van egymástól minden BCF és BSF.
Viszont elkövettem egy égbekiáltóan nagy hibát! 18F-en szimuláltam le és nem 16F-en. 16F-el tényleg nem jó a kód amit írtam. Na de nem azért nem jó mert a goto nem egy utasítás, hanem azért mert a btfss a 18F-en három, a 16F-en pedig két utasításciklus.
16F-en így a jó:


Oké akkor hogy tisztázzuk a dolgokat mondom: Nem próbáltam bizonyítani neked a fentebbi hozzászólásaimmal semmit. A későbbiekre való tekintettel pedig előre jelzem, ez a továbbiakban is így lesz. Ha mostantól bármikor úgy érzed hogy valaki bizonyítani próbál neked bármit is, az teljesen biztos hogy nem én leszek!

Csak úgy: WS2812B adatlap
SPI: A leírásban szereplő időzítésel 1 bit kiviteléhez 3 .. 4 SPI bit tarozik, az SPI adatregiszterének feltöltése lesz időkritikus. Fix címekken levő bufferrel lehet bűvészkedni.
Érdemesebb egy Advanced Midrange -re (32MHz) vagy egy 18F -re váltani.

Nem megerőszakolni akartam, a WS-nek az első két bit ment volna az első csomagban (első led színinformáció első két bit) a második két bit a második csomagban....így a tényleges információ összerakásához az aktuális byteot beolvasni, aktuális két bitet kivenni, megfelelő helyre besorolni a SPI regisztereibe nekem már túl bonyolultnak tűnt 8 utasítás alatt.( aztán az időzítés sem stimmelt..)
A SPI be töltendő adatokat előre formázottan igazából eszembe sem jutott letárolni, mellékesen az 3* annyi helyet foglalt volna minimum mint így.
Bár most hogy mondod, a fényerő információkat a SPI-hez a romban letárolhattam volna, így már szerintem bele férhet a 8 utasításba minden és a ramból sem foglalna több helyet.

Ebben igazad van. Elég béna megoldás ez az időzítés, de hát ez van. Lehet, hogy tényleg a szoftveres megoldás az egyszerűbb...

Szerintem igazából csak ötletelünk, miután van már megoldás. Az időzités miatt az SPI elég macerássá válik, de megoldható, csak kérdés van-e előnye.

Mennyi utasításciklus alatt kellene betölteni az SSPBUF-ba az újabb bájtot az SSPIF változása után?

A 4 bites változatban 2.5us alatt.

2,5us alatt szerintem megoldható az SPI buffer frissítése:

Így elvileg maximum 1,6us alatt (8 utasításciklus) frissül a buffer. Jól gondolom?

Ebben a formában egy szalaghoz(60 led) 60 led *3 szin * 4 byte kell. A SPI státusz figyelése egy kiszámíthatatlan késleltetés (2-4) Egyébként az egész 10 utasítás ciklus -szerintem- (1,2,1,1,1,1,1,2)

Ha az SPI státusz kiszámíthatatlan lenne összedől az egész protokoll.

Amikor én ezt régebben nézegettem ezt a két megoldást találtam figyelemre méltónak:
PIC18F 32MHz,
Microchip megoldás: AN1606 (Tudom nem az a PIC de ez kb. 400Ft).

Tudom, nem pont a te problémádra megoldás, csak gondolatébresztőnek szántam.

Na ez az. Nem gondoltam ennél bonyolultabbra. Szerintem 16F-en is fut apró módosításokkal. A 16F886-al az a gond, hogy csak 20MHz-el fut max és a leggyorsabb SPI így a 8 helyett csak 5MHz. Érdemesebb lenne olyan PIC-et választani, amiben van belső 8MHz-es oszci és PLL. Esetleg külső kristályról is mehet, ha pontosabb freki kell valaminek.

Gondolom itt arra gondolsz hogy a btfss-nél vagy a goto $-1-en van-e mikor az SSPSTAT,BF 1-re vált. Ha a goto-n akkor 2+2+1+2+1 azaz 8 utasításciklus. Ha a btfss-en van akkor kettővel kevesebb.

Szerintem.

Ráadásul a BANKSEL makró két utasításra fordítódik. "Kézzel" meg lehet oldani egy utasítással is, ha csak két bankot használunk a teljes memóriában, de ha többet, akkor az se megoldás...

Szerintem felesleges figyelni a BF flaget, adott órajel alatt ki kell mennie az adatnak, ezt kell kiszámolni.

Igazad lehet, elég egy megfelelő számú ciklus, vagy NOP-ok.

A különbség a kettőnk számításai közt ott van hogy egyrészt a BANKSEL az két utasítás, másrészt én azt írtam hogy az SPI-n egy bájt kivitelének befejezte és a következő bájt SSSPBUF-ba való betöltése közt maximum 8 utasítás telik el. Ez igaz is, mert az új bájt betöltése a "movwf SSPBUF"-al megtörténik.

De ktamas66-nak teljesen igaza van.

Én is szenvedtem egy sort ezzel a protokollal és végül szoftveresen oldottam meg. A helyzet az, hogy 16-20 MHz-en csak fix képet tudsz megjeleníteni. Ha változtatni akarod a színeket folyamatosan ahhoz magasabb órajel kell. Bár ez a memóriába eltárolom és onnan kiolvasom megoldás nem jutott eszembe, ki kellene próbálni. Ráadásul, szerintem nem olyan kritikus a színek közti változtatás, ugyanis az jutott eszembe, hogy a LED hosszu alacsony jelre resetel, ha magasan tartjuk a kimenetet szerintem megtartja a színt és addig lehet számolgatni meg egyéb műveletekkel foglalkozni. Ki még nem próbáltam, de amikor ezzel a leddel szórakoztam volt, hogy működés közben kihúztam az adatvonalat és tovább világított amíg volt tápja.
Hamarosan úgyis megint kell vele foglalkoznom, ha kész leszek a hozzá tartozó egyéb áramkörrel.

A btfss mindig 2 ciklus (pont azért, hogy ne nyírja ki az időzítéseket), vagy a következőt, vagy NOP-ot hajt végre: