MPLAB Help:

Köszönöm mindkettőtöknek! Tehát a #define sort kell ezek után csak kikommentelnem, szuper!

Na erre mondjatok nekem valami okosat!
Generáltam magamnak Excelben egy gyönyörű szinuszhullámot. Egész pontosan 20480db értékből áll, ezek az Excel munkalapján egy oszlopban egymás alatt sorakoznak. Minden érték 0 és 255 közt van, azaz egy bájtosak. A kérdés, hogy hogyan lehetne ezeket az értékeket az Excelből a PIC programmemóriájába áttölteni? Egy ötletem már van, de hátha mondtok jobbat.

PICkit2, vagyPICkit3 ?
Pontosítsd a kérdést, mert nem egyértelmű. Valami tömörítésre gondolsz esetleg?

Ez egy félhullám(fél periódus)?
Gondolom akkora PIC-et választottál, amiben van ekkora hely?
Ha megfelelően formáztad a táblázatot, akkor copy-paste, fordítás, kész...

Bocsánat ha félreérthető voltam, természetesen nem a PIC-be való beleégetése a probléma hanem hogy az Excel oszlopából az adatok hogyan fognak az MBPAB-ban megnyitott egyik include fájljába kerülni mondjuk minden érték új sorba és például egy "de" fordításvezérlő-utasítás után.
Például, ez van az excelben:
105
109
3
89
12
És ebből ez legyen az inc fájlban:
de d'105'
de d'109'
de d'3'
de d'89'
de d'12'

Közben kipróbáltam az ötletemet és működik szuperül. Mi mindenre jó az Excel...

Ha a B oszlopban vannak az értékek, akkor az első kockába ezt írd: és ezzel kitöltöd az A oszlopot. Utána exportálod .csv formátumba.

Egész pontosan ez egy egy és negyed periódus. Azért, mert szinuszra és cosinusra is szükségem van, az egyiket az elejétől fogom olvasni a másikat pedig a végétől visszafelé. Spórolni kell.
Persze, olyan PIC-et választottam amiben van ekkora hely. Minimum a PIC18F25K80-at a maga 32KB programmemóriájával.

Akkor gondolom nem egy bájton fejezel ki egy értéket...?
Az "összefűz" megfelel?

...és átnevezi .inc-re

Nem vagyok biztos benne, hogy kötelező a .inc kiterjesztés az MPASM használatakor. Mivel én egy külön fájlba írnám, kitölteném hozzá a sallangot, és külön fordítanám.
A hab a tortán, hogy az Excel képes valami.asm néven is elmenteni, ha .csv formátumba exportálunk.

Így is jó lehet, csak megszokás az inc. #include-vel be lehet szúrni a fő forrásba is, de külön is lefordul, ha használjuk a linkert.

De, minden érték egy bájt. Mondtam is hogy 0 és 255 közt van egy érték, azaz egy bájtos minden érték.

Az "összefűz" jó lenne, csak az a baj hogy az értékek nem egész számok. Az oszlopban persze szép kerek egész (0 és 255 közti) számokat jelenít meg az Excel de csak azért meg beállítottam hogy nulla tizedesig jelenítse meg a számokat. Viszont ha az "összefűz"-zel megpróbálom összefűzni akkor oda betesz egy marék tizedest.

Mutatom:

A "B1" helyett használd a KEREKÍT(B1;0) vagy INT(B1) illetve valamelyik kerekítő függvényt.
(KEREK.FEL, kerek.le)

A táblázatban az egyik oszlop fejlécére és az egyik grafikonra "kettes komplemens" van írva. Először azzá akartam konvertálni de aztán rájöttem hogy a sima feszített előjeles ábrázolás jobb lesz és végül az van a táblázatban és a grafikonon is az látható. Csak az oszlop fejlécét felejtettem el átírni még.

Nem értem, hogyan tudod használni ezt a táblázatot szinusz, koszinusz számolására, ha levágod a törteket. Tele lesz a táblázatod ismétlődésekkel. Hogyan akarod ezt használni?

És így tökéletes, köszönöm!

Akkor miért pazarolsz? Egy negyed periódus színuszt bőven elég tárolni, a periódus többi része ezen első rész ismétlése. Egy egyszerű szubrutin néhány feltételes elágazás és kivonás alapján vissza tudja adni a periódus tetszőleges pontját. A koszinusz meg ugyanaz, csak negyed periódussal siet a színuszhoz képest.

Örülök, hogy valaki megértett!
További spórolás lenne, (feltéve, ha ténylegelég ez a gyatra felbontás), hogy az ismétlődéseket arányosan osztani és úgy tárolni. A kiértékelésnél is osztani kell a kiinduló értéket...

Igen, erre is gondoltam. Viszont arra jutottam hogy ennyire azért nem kell spórolni. A legkisebb memóriájú PIC amiben ezt használnám, annak 32KB a programmemóriája, azaz még bő 10KB marad minden másra ami itt most bőven elegendő.

Viszont hogyha csak egy negyed periódust tárolnék le és elágazásokkal rugdosnám a megfelelő helyre a táblamutatókat, az bonyolítaná a programot és több ideig tart a lefutása. Persze nem sokkal tovább, de tovább. Márpedig jelen esetben ezzel is spórolni kell sőt, ezzel (a program lefutásának idejével) kell a leginkább spórolnom.

Úgy akarom használni, ahogy írtam: A szinusz megfelelő értékének kiolvasásához a táblamutatót a hullám elejére (első bájtjára) állítom aztán eltolom annyival amennyivel épp szükséges. A cosinusnál ugyan ez történik majd csak ott az utolsó bájtra állítom a mutatót és visszafelé tolom el a szükséges értékkel.

A törtek levágása nem értem miért lenne probléma.

Írtam, felbontás.
Ha meg nem kell ekkora felbontás, nem kell ennyi érték sem...

A program által megvalósítandó feladat ellátásához szükséges ez a felbontás. A cél ugyanis az hogy a táblából ki tudjak olvasni fix időközönként X, 2X, 4X ... 512X frekvenciához tartozó értékeket. Ha így tárolom a hullámot akkor nagyon egyszerű dolgom van mert X frekvenciánál egyenként kell kiolvasnom az értékeket, 2X frekvenciánál viszont minden másodikat, 4X-nél minden negyediket stb.

Szerk.:
Na, ki találja ki mi lesz ebből?

Ha szinusz generátor, akkor inkább az Ebayon vennék 1800-ért egy dds modult....

Látod sok esetben ezért nem értem amit írsz. Nem inkább azt akartad mondani, hogy a feladat ellátához elegendő? Nem ugyanazt jelenti...
Mert ez a felbontás nem nagy. Amit a kerekítésekkel kapsz, mondhatni, gyenge felbontás.

El ne áruld mi lesz ebből, mert megint dobunk egy hátast!

Nem, a "szükséges" az a jelen mondatban helytállóbb mint az "elegendő". Szerintem.
Ha kicserélnék ebben a mondatomban egy szót akkor az inkább a "felbontás" lenne és helyette ezt írnám: "mintaszám".

A korábbiakból tanulva lehet tényleg jobb is ha nem árulom el... De nem dds.

Szinuszos UPS?

Röviden: egy jelet szeretnék a szinuszhoz hasonlítani egy képlettel. Kicsit olyan mint egy FFT csak nem az.

Nincs kedvem elmagyarázni, feladom...

Megpróbálom elmagyarázni, amire WATT célzott (én megértettem WATT-ot ):
EXCEL-eztem kicsit: egy és egynegyed színusz periódust Attila86 felbontott 20480 részre, azaz egy negyed színusz periódusra az ötöde, 4096 minta jut, így az EXCEL függvénytáblázzon (hopp egy ósdi szakszó: függvénytábla - a mai fiatalok nem is tudják mi az ):
A oszlopba, a sorokba 1-től 4096-ig a minták sorszáma;
B oszlopba, a sorokba INT(SIN(RADIÁN(A1*90/4096))*255), (A1-A4096) azaz a 4096 minta 0-val kezdődik és 255-tel (1 bájt felbontás) végződik a színusz függvény szerint. A többi negyed kivonással és negálással származtatható: a második negyed = 1-első negyed, a harmadik negyed = -első negyed, negyedik negyed = -1-első negyed. Viszont én nem értem, ez miért bonyolult vagy miért kell erre sok processzoridő...
EXCEL Pivot tábla (kimutatás) függvény használatával kiderül, hogy a 4096 mintában az egy bájt felbontású (0-255 decimális érték) színusz negyedhullám ezen darabszámokban fordul elő:
0-100-ig minden érték 10-11 közötti darabszámban ismétlődik;
100-200-ig minden érték 12-16 közötti darabszámban ismétlődik;
200-230-ig minden érték 17-29 közötti darabszámban ismétlődik;
231-240-ig minden érték 24-30 közötti darabszámban ismétlődik;
241 32-szer ismétlődik;
242 33-szor ismétlődik;
243 35-ször ismétlődik;
244 36-szor ismétlődik;
245 38-szor ismétlődik;
246 40-szer ismétlődik;
247 42-szer ismétlődik;
248 46-szor ismétlődik;
249 49-szer ismétlődik;
250 55-szer ismétlődik;
251 62-ször ismétlődik;
252 74-szer ismétlődik;
253 95-ször ismétlődik;
254 231-szer ismétlődik;
255 1-szer szerepel.

Igen-igen lépcsős lesz ez a színusz hullám a bájt-minta diagramban. A két szélső érték kivételével (0 és 255 csak egyszer fordul elő) a többi minimum 10-szer, a 254-es bájt 231-szer fordul elő.

1024 minta esetén a két szélső érték kivételével a minimum ismétlődés 2, maximum 57.
512 minta esetén a két szélső érték kivételével a minimum ismétlődés 1, maximum 28.

Színusz hullám ábrázolása bájt felbontással 512 minta/negyedhullám felett felesleges az ismétlődések miatt. Viszont a mai olcsó, sok KBájt RAM kapacitású mikrovezérlőknél nem gond az Attila86 általi brutal force módszer használata, hisz 20480 bájtnyi adat tárolása könnyen megoldható.
A WATT féle programozási módszerek meg gyönyörűen csillogó gyémántok a szürke brutális sártengerben .
A jobb program(ozó) ugyanazt megteszi fele akkora kóddal negyed annyi idő alatt, mint a másik program(ozó), bár az emberek túlnyomó többsége semmilyen programot sem képes alkotni .