Rendben, én ezt értem. Persze hogy lehet még egyszerűsíteni hogy még kevesebb helyet foglaljon, de cserébe egy halom elágazás, számlálás stb kerülne be. Emiatt lassabban futna le a program ezen része. Ha olyan nagyon spórolni akarnék a programmemóriával akkor a SIN és COS függvények értékeit kiszámoltathatnám a PIC-kel és akkor aztán semmilyen jelalakot nem kellene a memóriában letárolni. Ez lenne az igazi spórolás! De persze egy szinusz függvény kiszámoltatása relatíve hosszadalmas feladat lenne.
A program ahol ezt a szinusz-cosinusz táblát használnám úgy fog működni hogy az A/D folyamatosan, fix időközönként mintákat vesz egy jelből és két mintavétel közt míg az A/D dolgozik, a legutóbb vett mintát összehasonlítja a szinuszfüggvény valamelyik értékével. Hogy melyikkel, azt ki kell számolnia a PIC-nek és táblamutatóval ki kell olvasnia a memóriából. Ezt az értéket pedig lehetőleg elég gyorsan meg kell találnia a PIC-nek mert még az A/D mintájával össze is kell szoroznia meg göngyölnie egy sok bájtos számhoz. Ennek az egésznek mindenképp le kell futnia azelőtt hogy a következő A/D konverzió befejeződik, különben mikor az A/D megszakítást okoz akkor kutyulódik az egész. Hogyha csak egy negyed hullámot tárolok el és abból némi számítással és elágazásokkal találom ki hogy melyik értéke kell a hullámnak, akkor ez növeli a két mintavétel közti időt amit a PIC számolással végez. Jelen esetben pedig törekedni kell arra hogy ez a számítgatás minél hamarabb lefusson.
Valóban, a watt által vázolt megoldás sokkal elegánsabb (gyönyörűen csillogó gyémánt) de ebben a felhasználásban most igenis nem az a jó megoldás.

A programmemóriával való spórolás célja micsoda? Az, hogy beleférjen a program a mikrovezérlőbe. Tömöríteni, okoskodni csak addig szükséges míg bele nem fér. Tovább már felesleges. 32KB a PIC memóriája és a legpazarlóbb megoldásban a szinuszhullám kb 16KB, a cosinus szintén 16KB azaz pont tele lenne a memória. Akkor jött az ötlet hogy akkor legyen csak egy egy és egynegyed szinusz ami már csak kb 20KB, így 12KB marad a program érdemi részének. Ami bőven elegendő mert az maximum csak néhány száz bájt. Ha tovább csökkentem, tömörítem a hullámot akkor csak azt érem el hogy a programmemóriában nagyobb lesz az üres hely. Ebből milyen előny származik? Semmilyen! Ja de bocsánat, nem másfél hanem csak 1,4 másodpercig fog tartani a mikrovezérlő felprogramozása. Ezen felül semmilyen más előnye nincs, csak a szépérzékünk lesz tőle boldogabb hogy elegánsabb, okosabb kódot írtunk. Valójában viszont a fentebb vázolt működésből eredően lehet hogy a kódunk elegáns, csak működni nem fog. (Mert túl sokat számol két mintavétel közt.)

Az pedig hogy miért áll ilyen sok értékből a hullám mikor már 512db érték is elegendő lenne:
Azért, mert (mint egyébként már egyszer említettem); nem minden értéket olvasok ki a táblából. Van hogy mindegyiket, de van hogy csak minden másodikat, minden negyediket stb. A legnagyobb ugrálás az értékek közt 512.

Egyetértünk!
Ha a sebesség kritikus, gyorsabb órajelű mikrovezérlő kell(het).
A 32 bites 40-120 MHz órajelű mikrovezérlők gyorsak, elérhetőek, olcsók, több gyártótól is.
A PIC18F25K80 16 MHz-es ha jól olvastam...

Egy-két shifttel(osztás) fele, negyede, nyolcada lehetne a tábla mérete. Ha e miatt nem elég az idő, akkor neked van igazad. Meg ahogy látom itt csak neked lehet, tehát legyen úgy... Csak azt nem értem, ha ennyire penge vagy, mi a fenének kérdezel miket? PIC kérdésed nem is volt ebben a táblázatos részben...

Ennek a PIC-nek az AD-je nem valami gyors egyébként...

A PIC18F25K80 maximum 64MHz-en tud menni. És sajnos egyenlőre csak a nyolc bites mikrovezérlőkkel tudok operálni.

Én csak annyit kérdeztem hogy az Excelből hogyan lehetne az MPLAB-ba valahogyan "kiexportálni" adatokat úgy hogy mind előtt egy DE direktíva legyen. A választ erre megkaptam, meg is köszöntem, meg is valósítottam és működik. Ennyi.

Innentől már ti (pontosabban te) kötöttél bele abba hogy erre miért van szükség, mi értelme ennek és egyébként is felesleges ennyi érték stb. Ha elhittétek volna elsőre hogy nekem tényleg pontosan erre van szükségem akkor nem kellett volna elmagyaráznom. Most hogy elmagyaráztam így már elhiszitek hogy tényleg így a jó ahogy kitaláltam. De most meg az a baj hogy akkor meg mi a fenéért kérdeztem. Hát nem kérdeztem!

Az összes PIC18 alatti sorozat 8 bites.

Felesleges felkapnod-felkapnotok a vizet, igazán nincs mire, hiszen magunk között vagyunk javító, tanuló, tapasztaló, problémamegoldó céllal. Mindketten kicsit nyersek vagytok, nem kell rögtön harapni, szavakon lovagolni, fogalmazást kritizálni, hamár nem tudtok olyan kifinomultan, pallérozottan, türelmesen fogalmazni (mint én ) vagy amilyen jó programot írni .

Én azért kíváncsi vagyok mi a feladat, mit kell megoldanod.

Nem az értelme a fontos, mert valószínűleg az emberiség túlnyomó részének teljesen értelmetlen a Te gondod és sz...k rá nagy ívben. Mi legalább kérdezünk és próbálunk segíteni. Hiába mutatsz egy nagyszerű célszerszámot, ha nem tudható mire való, hogy kell használni, akkor nem lehet értékelni, ötletelni, javítani, továbbfejleszteni, tanulni belőle...

Sziasztok! Az alábbi problémával szembesültem ws2812b intelligens RGB led meghajtásánál:

A ledet 16f886 PIC-kel vezérlem 20Mhz-es órajellel. A led időzítései miatt (800kbit/s jelet vár) 6 assembly utasítást tudok adni a picnek egy bit átviteli ideje alatt. 24 bitet kell kiírni G7 G6 G5 G4 G3 G2 G1 G0 R7 R6 R5 R4 R3 R2 R1 R0 B7 B6 B5 B4 B3 B2 B1 B0 sorrendben.



Ezek megfelelő ismételgetésével egy (vagy több) konkrét színt be is tudok állítani a leden, de nem tudom pl. egy változó értékétől függően változtatni a színeket vagy a fényerőt. Lehetséges ez ezzel a piccel valahogy egyáltalán vagy túl lassú a feladathoz?

Talán így:

Ha összeállítottad a 24 bitet, az MSSP modul jó lehet kiküldeni az adatokat.

Az a gond, ha lassabban jön az adat, össze-vissza színeket és fényerőt eredményez. Még a hardwer megszakítást is tiltani kell, az átvitel idejére. 6 utasítás ideje áll rendelkezésre, amiből 1 db. goto máris elvisz 2 részt...

Akkor a ciklusok helyett mind a 8 bitre le kell írni külön külön...

Igen, kellene egy 3 byte hosszú buffer, amit egy parancsra az adott időzítéssel kiír a pic az egyik portján. Az MSSP Fosc/4 vagy Fosc/16-tal megy de a buffere az csak egy byte ügye? Hogy töltöm fel két byte között?

A feltöltés lehet poll alapján, és lehet interrupt alapján is. Jelen esetben valószínűleg folyamatosan kell kérdezni a BF bitet. Az MSSP tud működni az SSPADDR-ben megadott osztó alapján is.

Ha külön szedném a 8 bitet, akkor is bajban lennék, mert a "0" értékél az első hi->lo váltás 1 utasításon (4 órajelen) belül van. Tehát nincs idő a scrollozásra, csak akkor lehetne, ha az egész PORTA -t scrolloznám és a többi 6 bitre raknám be az értékeket a maradék időben...

Én is az SPI-re szavazok...

Megtaláltam a kiskaput Szerencsére a led nem teljesen úgy működik mint ahogy a leírásban van.

Ezt a szín minden bitjére meg kell csinálni (7x24 sor COLOR_G, COLOR_R,COLOR_B 7-0 bitjére) nincs idő közben számolgatni. A csalás ott van, hogy a 0 érték bitmintája 100000 helyett 110000 (az 1 maradt 111000)...

Két kevert szín:

SPI esetén nem kéne visszakódolni a színt, csak kitenni a pufferre.

Hogy néz ki az kód szintjén? Hogy kell beállítani a 3 byte-os puffert?

Biztos meg lehet csiálni, csak nem tudom a módját: ws2812b 4Mhz SPI

Az SPI puffere (SSPBUFF) 8bites. Beteszed az első bájtot, majd figyeled az SSPIF-et, hogy kiért-e az adat. Beteszed a következőt, törlöd az SSPIF-et és így tovább a 3 bájtig.

Megpróbálom, mert ez az asm megoldás (még ha működik is elég lábbalhajtós). Csak fel kell szabadítanom az spi-hez a PORTC.5-öt lévén ez egy meglévő óraprogramomba menne bele utólag... így, hogy látom hogy megy 4mhz-en érdemes kipróbálni.

A SPI nem igazán tetszett. Két byte között egy extra szünetet tesz be, így már borul a teljes időzítés. Én egy 16f1503-mal csináltam. 16Mhz 5 utasítás/bit. Le kell tárolni az egész képet.Címzéshez az FSR-t használtam.
Egy bit kb így néz ki:


Azért 16 részből áll egy ciklus, mert a picbe nem volt több memória, így a 60 ledhez feláldoztam a fényerő alsó biteit Ha a clrc-s programrészek törlésével egy Byte egy szín állapot elérhető
Sajna ez alatt a port másra nem használható, az összes kimenete változik a kiírás alatt.

Ha ez zavar akkor állítsd lassabbra az SPI-t. Nem tudom ez az adott áramkörben megengedhető-e, de ezzel eltűnik (jelentéktelen mértékű lesz) az a szünet. És/vagy nagyobbra is állíthatod az órajelet.

Más részről a SPI hez a byte-okat szét kell darabolni, ami szintén problémás a rendelkezésre álló idő alatt.(egy byte 2 bitet meg egy kicsit tud csak postázni.)

És az nem járható hogy előbb szétdarabolod, elteszed három külön regiszterbe és utána küldöd csak ki? Így az egyes bájtok kiküldése közt kevesebbet kell gondolkodni.

Egészen lassúra állítottam, így derült ki.Sajna az adott alkalmazásban (WS2812B) ez nem tehető meg, mert igencsak szűk időzítéssel rendelkezik.(kb 400ns) És mielőtt nagyobb processzort javasolnál, ez volt otthon, és ezzel is tökéletesen működött (azzal az apró hibával hogy a fényerő csak 4 bites.)
Ami megkötés az egész füzér képét egyben megszakítás nélkül pontos időzítéssel kell kiküldeni (60*3 byte).

A ws2812b kötött időzítéssel működik...