Első körben nagyon szépen köszönöm mindenkinek a segítséget.
Sikerült megoldani a feladatot.
Mivel gondolom, kíváncsiak vagytok rá mi célt szolgál ez a sok adat, leírom.
Fiamnak ajándék volt egy úgynevezett Ambibox.
Ez egy RGB ledes háttérvlágítás a számítógép monitorának hátulján.
Egy kis videó arról, mit csinál.
A lényeg az hogy a számítógép USB-n át folyamatosan küldi a ledeknek az adatokat. Egy lednek 3 byteot.
Csakhogy míg a géptől uart formaban jöllen az adatok korlátozott sebességgel, addig a WS2812-es ledek 1-Wire kapcsolaton működnek 800000-110000 bit/sec sebességgel. Ezt a jelátalakítást végzi el egy Arduino nano. Sajna a jelátalakító rekord idő alatt megdöglött. Kínosan érintett, hogy az ajándék csak eddig bírta, így gyorsban kellett valami megoldás.
Szerencsére az UNO CH340-es USB illesztőt használ, ami volt nekem itthon, és nem kétirányú a kommunikáció. Azaz a szoftvert csak az érdekli, meg van-e a CH340-es. Ha igen, tolja az adatokat.
Mivel 120db lednek már elég komoly adatmennyisége van, (A PIC18F14K22 jelen alkalmazásban 160 LED kihajtására képes.) a géptől kb 31msec-ig érkeztek az adatok, majd egy rövid szünet és kezdődik előröl.
A szünet ideje messze rövidebb, mint amennyi idő alatt az összes adatot tovább tudom küldeni. bár az 1-Wire csaknem 10x gyorsabb.
Az adatok folyamként történő letárolása és a már továbbküldöttek felülírása nem akadály egy PIC18-nak. Itt csak arra kellett ügyelni, hogy időben kivegyem az RCREG-ből az adatot.
Szerencsére az 1 Wire roppant rugalmas, és akár két bit elküldése között is megszakítható, majd folytatható az adás. (persze azért a megszakítás ideje nem korlátlan)
Egyszóval fáradozásomat siker koronázta, köszönhetően a gyors és hatékony segítségeteknek.

PIC18F14K22I/P (512 byte RAM) @ 820 Ft+Áfa -- PIC18F16Q41I/P (4K RAM) @ 640Ft+Áfa

Bocsánat, hogy belevau de mindenképpen érdemes figyelni arra, hogy a Dallas Semiconductor által kifejlesztett 1-Wire protokoll (Wikipédia) nagyon is kötött időablakokat használ.

A WS2812 alapú szerkentyűk ugyan egy vezetéket használnak kommunikációra de nem a szabványos 1-Wire protokoll szerintit.

Bár már megoldottad, de egy kis megjegyzés. Ahogy a videót nézem semmi gond nem lenne belőle, ha csak minden második adatcsomagot dolgoznád fel. Nekem nem úgy tűnik, hogy extra nagy sebességű animációkat kellene megjeleníteni, nem hiszem, hogy észrevehető lenne, ha a jelenlegi 40msec helyett csak 80msec sűrűséggel lenne újraprogramozva a ledsor (25fps -> 12,5fps lenne).

> Sajna a jelátalakító rekord idő alatt megdöglött.

Ez a pont ütött még szöget a fejembe. Van valami tipped hogy mitől ment tönkre? Eleve hamisítvány volt? Valami védelem hiányzott róla? Csak mert alapból ezek ritkán mennek tönkre, ha így gyorsan tönkremegy, az legalábbis gyanús.

Azért is érdekes lehet, mert ha betettél helyette egy PIC-et, de a környezetében van a probléma, akkor a PIC is hamar elmúlhat esetleg.

Jó kérdés, hogy mitől adta fel a harcot. A kütyü az USB-től kap tápot, a LED-eknek külön tápjuk van. Az UNO panelján a CH340-es működik. A reset gomb megnyomására az Arduino boot ledje villog. De jel nem jön ki belőle. Hogy most a programja sérült, vagy a kimenete szált el én nem tudom kideríteni. Az biztos, hogy egy kóbor ellenállás sincs az Arduino kimenete és a WS LED bemenete között. Én azért oda betettem egy 1K-t.

Mivel gyanús volt, hogy egy nagyobb tudású kontroller olcsóbb, kerestem a csapdát.
Első pont, nincs benne a "PIC micro database" állományban.
Gondoltam újabb, ráfrissítettem az állományra, akkor sincs.
Megpróbáltam nyitni neki egy új projektet az MPLAB X-ben, az sem ismeri.
Én a v3.65-ös verziót használom. Ebbe valahogy utólag beimportálható?
Ugyanis szívesen kipróbálnám.

Az újabb PIC-ek mindig olcsóbbak, és néha váltani is kell, de ha hobbira használod, 1-2db-nál a fenti árkülönbség nem számít semmit, csak emiatt nem választasz egy újabb, egyébként nagyobb tudású kontrollert, ha a régebben használttal is tökéletesen meg tudod oldani a feladatot. A régebbi típusok, lehet, hogy vannak a fiókodban, több forrásból is beszerezhetőek, a jelenlegi programozód ismeri, nem kell újat venni. A korábban megírt periféria kezelő kódjaid teszteltek, működnek a korábban használt típuson, nem kell módosítani, újraírni, újra tesztelni.

Ha kinőtted az adott kontrollert az adott feladatra, akkor is érdemes megnézni, mit is tud például a jelenlegi programozód még felprogramozni.

Én ilyet nem tapasztaltam.
Az általam eddig használt gyári 1_Wire eszközökről mind elmondható, hogy a szinkronjelhez képest a beolvasás ideje plusz - mínusz irányban 30-50% elcsúszást elvisel.Matematikailag ez a következőképpen néz ki: Ha a teljes jelszélesség 10usec, akkor ebből 2usec a startimpulzus. Az optimális beolvasás a start impulzus kezdetétől számított 6. usec-nél van. Ám 3usec-től 9usec-ig hibátlan beolvasás valósul meg. Két bit között is tarthat rövid szünetet az adó oldal (master). USART módban még a legrugalmasabb esetben is csak plusz-mínusz 6%.
Az 1-Wire-t nem az épp használt protokol határozza meg, hanem az adatátvitel mikéntje.
Én két PIC között mindíg 1-Wiret-t használok. Esetenként 30 métert is meghaladó vezetéken. Sosem volt még ebből adódó problémám.

MpLabX V5.5 kezeli. PICkit4 / Icd4 kell hozzá. Avagy módosított PICkit2.

Egy picit még ráfejeltem a projektre.
Mivel a LED szalagnak külön tápja van, így az vagy folyton áram alatt van, vagy folyton ki kell huzigálni a konektorból.
A PIC-nek egy csomó lába kihasználatlan. Ezért úgy módosítottam a szoftvert, hogy ha van érvényes adat a gép felől, Az első 6 byte még nem a ledek működtetésére vanatkozik. Az első 3 byte egy azonosító. A második 3 számomra érdektelen. bekapcsolok egy kimenetet. Ha nincs érvényes adat, 13 másodperc után lekapcsolom. Ezzel tudok üzemeltetni egy relét, ami áramtalanítja a LED szalagot.

> A kütyü az USB-től kap tápot, a LED-eknek külön tápjuk van.

Én nem vagyok ennek a szakértője, de úgy tudom, hogy nem szerencsés külön táplált dolgokat galvanikusan összekötni. Lehetnek ilyenkor zavarok, amik terhelést rónak az összeköttetésekre.
(Ezért amikor mikrovezérlőt programozok, akkor leveszem a saját tápjáról, és csak a programozó táplálja USB-ről. Vagy laptopot használok, de úgy hogy direkt csak akksiról.)

Persze elvben a kettős szigetelésű tápok, amiknek nincs földelése nem visznek át stabil nullát, de mégsem szokás ilyet csinálni.

A másik hasonló "szabály", hogy a mikrovezérlő jeleit nem vezetjük ki a dobozból közvetlenül.

Talán ésszerű lenne a jelet egy optocsatolón keresztül vezetni a LED szalagba, és ezzel galvanikusan szétválasztani a kettőt. Van erre lehetőség?

Én kimérném, hogy a tönkrement Arduino-nak mi a baja, kiváncsi lennék rá a helyedben.

Fikarcnyit sem értek az Arduinohoz, ezért nem tudom tesztelni sem.

Bár ez valóban így van, és a saját áramköreimen szoktam is optocsatolókat alkalmazni, ennek ellénére a gyakorlatban ha csak nem szintillesztés van vele megoldva, nemigen alkalmazzák.
Még a PLC-k bemenetein sincs optocsatoló. Konkrétan a gravírozó gépem és a "labortápom" közös tápegységen osztozik. A gravírozó gép állandó USB kapcsolatban van a PC-vel. A labortápról tápláltam egy áramkört, amit a PC-re csatolt oszcilloszkóppal mértem. Úgy összeugrottak, hogy minden betérdelt. Szerencsére újraindítás után minden működött, de azért ijesztő volt.
Egyébként valami ilyesmi lehetett itt is, mert a fiam elmondása alapján befagyott a PC-je, és az újraindítás után már nem működtek a fények.

Idézet:
„Még a PLC-k bemenetein sincs optocsatoló.”

Én úgy tudom, hogy mindegyik úgy kezdődik ( nem noname-k!) !?

Amiket eddig láttam azok is mind optocsatolós áramkörrel kezdődtek, egy kivétellel, az Unitronics Jazz oplc-jében emlékeim szerint nem volt optocsatoló.

Nem tudom megállni, hogy ne fejezzem ki teljes egyetértésemet a "Miért éppen assembly?" című cikk bevezetőjében olvasható gondolatokkal.
Én magam is assembly-ben programozok pic-eket, jóval nagyobb terjedelemben is. Kezdetben ennek az volt az oka, hogy a Microchip gyári ingyenes C fordítója botrányos minőségű kódot állított elő, a pénzes változat meg szóba sem jöhetett, sem anyagilag, sem elvben. Azután pedig beleszerettem abba, hogy egy komoly képességű logika végeztével is még csak 10%-át használtam fel a rendelkezésre álló memóriának, és a sebesség is ehhez volt mérhető.
Összességében azt tudom elmondani, hogy minden lassabban megy mint magasabb szintű nyelveken. Határozottan azt gondolom, hogy egy jó C fordító képes megközelíteni az assembly teljesítményét, de annak akkor igen jónak kell lennie.
Sajnos a mai mainstream egyértelműen abba az irányba megy, hogy megpróbálnak minden rutint összeguglizni, és mi tagadás, valóban gyorsan tudnak eredményt elérni. De hogy milyen áron, az egyre kevesebb embert érdekel.

Ha a tíz perc alatt összeguglizott kód ellátja a szükséges feladatot, akkor nem sok értelme van az alacsonyabb szintű programnyelvnek. Nagyobb teljesítényű mikrokontroller kell? Annál jobb, még olcsóbb is, mint a régebbi, több periféria van benne, egyre kevesebb dolgot kell megoldani programból.

Félreértés ne essék, van helye az ASM-nek is, csak egyre kevésbé éri meg.

Ezzel a szemlélettel az a legnagyobb probléma, hogy miközben a gyártók igyekeznek nagyobb teljesítményű hardvert előállítani kevesebb fogyasztással, addig a szoftveres oldal teljesen szétcsúszik és rontja a hatásfokot. Fejlődés éppen csak azért látszik, mert a hardver gyorsabb ütemben fejlődik, mint ahogy a szoftver hatékonysága csökken.
Nyilván mindenki a könnyebb utat keresi, ez érthető, de ez nem jelenti azt, hogy ez a helyes és fenntartható irány. Itt vannak például a környezetvédelmi kérdések. Ott is mondhatnánk, hogy "nincs értelme" kevesebb áramot, vizet fogyasztani, ha egyszer úgyis ki tudom fizetni. De azért mégis érezzük, hogy akár plusz erőfeszítések árán is a takarékosabb, hatékonyabb irányba kell mennünk.
Vagy át kell gondolni, hogy például a Linux térnyerése minek volt köszönhető. Annak idején rendelkezésre álltak magasabb szintű rendszerek, mégis mindenki a bőrén érezte, hogy milyen, ha valami nem hatékony.
Persze, nem az assembly a megoldás mindenre, itt azon rossz felfogásról van szó, ami a mai szoftverfejlesztést jellemzi.

A "még olcsóbb is" gondolatot nem értem, tudtommal a legolcsóbb mikrovezérlők éppen azok a kis 8 bites mikrovezérlők, amikről a cikkben is szó van. Ennél feljebb minden drágább.

Szerintem inkább arra gondolt, hogy a régen oly népszerű 16F628A ma már-már kuriózumnak számít, legalábbis az ára ezt tükrözi. Gyakorlatilag harmad áron lehet kapni a 16F1824 típust amiben jóval több periféria van, tudása messze meghaladja a 628A típust.

Kicsavart példa: egy komplex programot megírni C-ben 2 nap, ASM-ben 4 hét. Két nap alatt a számítógép kevesebb áramot fogyaszt mint négy hét alatt. Erről az oldalról is meg lehet vizsgálni a környezetvédelmi szempontot.

Pali79 rátapintott a lényegre. A 628A kontroller 18 lábú, hasonlítsd össze a 20 lábú PIC18F16Q40 vagy PIC18F16Q41-essel.

Nyolclábúak: PIC12F1840, PIC16F15214...

Na azt azért megnézném, hogy amit én asm-ben 4 hétig írok, azt te megírod 2 nap alatt C-ben.
Egyébként a megjegyzéseid híven tükrözik azt a szemléletet, (és itt most nem rólad van szó elsősorban, de tárgyszerűen veled fogok példálózni) hogy hiába lehetne valamit kevés hardverrel, kis helyigénnyel, megbízhatóan megcsinálni, nem fog megtörténni, mert ahoz vagy újat, többet kell tanulni, vagy többet gondolkodni.
Példa:
Van egy cikk itt a HE-n egy csöngető renszerről amit egy Nextion kijelzővel oldott meg a készítője mindenféle miktokontroller nélkül. Ugyanis a Nextionba komplex programok írhatók.
Pár nappal később jelent meg a te cikked, ami egy hasonló felépítésű időzítőről szól, amit egy PIC-el oldottál meg, a Nextiont pedig csak mint kijelzőt használtad.
Szerintem kralg is az ilyen fajta hardverpazarlás ellen szólt.

Ez azért szerintem sem ennyire szimpla. Aki sokat fejleszt programokat annak egy idő után meglesz a saját rutin gyűjteménye akárcsak a C-ben. Azzal a különbséggel, hogy pontosan tudja a fejlesztő, hogy a PIC mit is csinál. Ez főleg idő kritikus programoknál fontos.

Megvan a helye az ASM-nek, ezt soha nem is vitattam. A "gond" ott van, hogy hobbistáknak szóló fórumon jelentitek ki, hogy aki nem ASM-ben írja a programokat, az semmit nem tud sem a programozásról, sem a kontrollerről. Ha adott kontroller úgy viselkedik, ahogy azt elvárják, akkor kb. tökmindegy, mi a forrás. Igény van a gyors előrelépésre, lásd: Arduino, Flowcode, Mikroe, CCS-C. Akinek meg nem lesz elég, majd továbblép.

szerk.:
Az a csengő jóval kevesebbet tud, a kijelző pedig az okosított változat.

Na látod, itt a baj!
Az emberek fejébe beleverték, hogy vágyjanak a nagyobbra, erősebbre, többet tudóbra a racionális gondolkodás teljes kiírtása mellett.
Azaz már holnapra!
Erről szól a fogyasztói társadalom.
Mondjuk viccesnek tartom, hogy egyre nagyobb hangot adnak a zöldeknek. Óvjuk a földet, tisztítsuk meg a környezetet, de a fogyasztói társadalomnak maradnia kell.
Sebaj, hogy a kettő együtt nem megy.

Különvéleménnyel élek.
Szerintem az hardver, és az assembly assembly ismerete ad egy biztos alapot. A magas szintűek nevezett nyelvek elsajátítása során ritka, hogy a bitműveletek rögzüljenek a páciensben, pedig ez a hardverközeli programok hatékonyságának lényege.

C nyelv mellett nem lehet megismerni a hardvert?

Dehogynem.
Csak rászoktunk, rá vagyunk nevelve a decimális gondolkodásra.
Tesztkérdés: egy FiFo puffert kell deklarálni. Ki, mekkora tárterületet foglal le erre a célra? A hardver tetszőleges, a tárterület, adatátviteli, feldolgozási sebesség úgyszintén.
Szeretnék néhány választ kapni erre a kérdésre, utána tovább érvelek.
Rajtad kívül sonajkniz és Pali79 válasza különösen érdekel.

A dolog már az első pár programsornál megbukik, főleg 8 bites mikrokontroller használata esetén, legyen ASM vagy C.

Elnézést, belátom hogy tévedtem, miszerint megpróbáltam pár oldalt felmutatni, ellenkezvén a téma címével és annak rajongóival. Nem kell érvelned, ahogy én sem fogok felsorolni pár Google találatot.

Azert ehhez meg kellene egy kicsit pontosabb feladat specifikacio

Tetszőleges, amit optimálisnak tartasz. Soros portod van. Ha többet árulok el, bukik a teszt.