Indítok egy timer0-át 8bit-es módban. Beállítottam a leggyorsabb megszakításra, amely minimum 200nS / megszakítás. A megszakításban egy változót növelek.
1. timer0 indul
2. 1 byte adat lekérése SPI x 100 alkalom
3. timer0 leállít
Timer0 adatát megkapom: 128nS
Ez úgy jön ki, hogy timer0-ban növelt változó értéke 0.64, ezt úgy kaptam meg, hogy egymás után 100 alkalommal kérdezem le ugyan azt, majd ezt átlagolom. így jön ki a 0.64.
Timer0 200ns/megszakítás, 200*0.64 = 128nS
Minden más értéket is ugyan így mértem.

Mérés:

Megszakítás:

Breakpointtal állítom le a programot, debug módban.

Valami akkor sem stimmel.
Ha az órajelet direktben méred már az 25nsec.
Hogy lesz abból neked kevesebb mint 1nsec?

Én azt írtam, hogy még mindig 1uS alatt vagyok.

Nem értem ezt az 1nS-t.

Csak egy kérdés: Hogyan is akarsz 200nsec-enként megszakítást, amikor ennyi idő alatt 2db. 1 ciklusú utasítás fut le? 40MHz-es cpu clocknál ugye 25nsec a cpu órajel, de 4 órajel egy utasítást végrehajtania a procinak.
A másik: nem tudom milyen módon csinálod a cpu órajelet, de nekem a pll-es órajellel volt gondom anno ennél a típusnál, úgy rémlik egyszerűen nem akart a pll dolgozni, és csak az eredeti órajellel ment a proci. Mondjuk hogy pontosan mi is volt, az már az idő homályába veszett, de érdemes lenne megnézned a valós órajelet mondjuk egy láb billegtetéssel és rá rakott oszcilloszkóppal vagy logikai analizátorral.

Igen PLL-elel használom. 10MHz-s külső kristállyal. ellenőrizve LED billegtetéssel, meg van a sebesség. 25nS egy órajel ez meg van nekem is, még is egy byte olvasás SPI-ről timer0-val mérve 128nS ideig tart. Ez összesen 5 utasításnak felelne meg, ha csak nem rosszul állítottam be a timer0-át, ami nem lehetetten, de oda figyeltem kellőképpen, akkor ez ennyi ideig tart neki. Kicsit én is keveslem, de ennyit mérek sokadjára is. Innentől már csak a timer0 oszcilloszkóp mérése ami per döntő lehet majd, de ezt már csak holnap elkörzöm. elvileg 200nS, de holnap pontosítok..

Ezt írtad:

Ha a 0.64 nem nsec-et jelent, akkor mit?

Szerintem te el vagy tévedve. A PIC nem ATMEGA vagy ARM, hogy egy órajel alatt végrehajtson egy utasítást. A 8 bites PIC-eknek legalább 4 órajel kell egy utasításhoz, azaz a 128nsec alatt csak 1 utasítással végeznek, meg éppen csak belekezdenek a következőbe.

A timer0 megszakításom lefutásának számát mutatja. De ezt írtam is feljebb. 100 egymás után veszek 1 byte adatot, hogy az érték pontosabb legyen, majd a megszakítások számát elosztom 100-al, így kapom meg a 0.64-et.

Hogy érthetőbb legyen: PIC18F452
0. Timer0Count = 0;
1. Timer0 indítása (egy változó értékét növelem minden megszakításban)
2. Sample = MemRead(MemCim); // Kérek SPI-n 1 mintát ( ez egy 1byte)
3. ... 2.*99 összesen 100 alkalommal kérek 1 byte adatot
.
.
.
101. Sample = MemRead(MemCim); // Kérek SPI-n 1 mintát ( ez egy 1byte)
102. Timer0 tiltása
103. Eredmény = Timer0Count/100 = 0.64

Tehát a timer0 0.64szer fut le egy minta vétele alatt, amely összesen 1 byte adat az SPI memóriából kiolvasva.

Ezek után lehet az így kapott eredményt időre váltani:
Timer0 megszakításának ideje (feljebb a teljes kód): FOSC/4/2/1 vagy is 40MHz/4/2/1 = 5MHz és ebből jön ki az idő, ami 1/5MHz = 200nS
Tehát a megszakítások 200nS időnként érkeznek, így 200nS*0.64 = 128nS.
Ebből nekem ez a 128nS idő jött ki, vagy is, hogy 1 minta vétele 128nS alatt érkezik meg.
Remélem így világosabb. Újra átgondolva még mindig úgy gondolom, hogy jó a mérésem, de hátha rá tudtok világítani arra, hogy ha van is hiba azt hol keressem. Ma szkóp is befigyel.

Igen azt értem és olvastam is, hogy 1 utasítás feldolgozása 4 órajel vagy is elvileg 40MHz-nél 100nS idő és egy SPI kezelésnél sokkal több utasítás van mint 1, de még is ezt mérem. Ezért is írok, hogy hátha valaki észre vesz valamit, vagy gondol valamire, amin átsiklottam vagy nem veszek észre. Timer0 megszakításom hibás lenne? Nem tűnik hibásnak elsőre, de ettől még lehet.

Egyébként nem csak 1 utasítás 4 órajel, hanem pl. egy ugrás 8 órajel időbe kerül. És nálam 1 memóriából való 1 byte olvasása véget legalább 3 ugrás van. Ami összességében vagy 600nS.
Szóval ezért is írtam feljebb, hogy nem értem és valami nem kerek, de még is minden úgy fest mint ha jó lenne.

Nem lehetséges, hogy a Timer0Count változód túlcsordul? Esetleg többször is...

Azt se felejtsd el, hogy egy megszakítás kiszolgálás is nagyságrendileg 20 utasításciklus (azaz 80 órajel), ha nem csinálsz benne semmit. Azaz felejtsd el a nsec sűrűségű megszakításokat. A timer0-t használhatod nyugodtan időmérésre, de állítsd be 16 bites módra, és ha 65536 számlálás után túlcsordulva megszakítást okoz, ott növelj egy 8 vagy 16 bites változót. Ekkor ha lekérdezed a "pontos időt", akkor az alsó 16 bitet a számláló aktuális értékéből, a felsőbb biteket meg túlcsordulás általi megszakításkor megnövelt változóban kapod meg.

Szerintem itt van az amit elnéztél. Ha a Timer0 8 bites üzemmódban van, és tmr0 regiszterrel nem csinálsz semmit, akkor a beállításod szerinti megszakítási időd 200nS*256. Azaz 51,2usec lesz.

Megnézted a teljes beállításom és kódot a lap tetején lévő első hozzászólásban?
Megszakításban az újra töltés:

Ez 256szor fut le?
Az elő töltés határozza meg, hogy mennyi ideig tart 1 megszakítás nem?
Mindjárt meg méreg egy szkóppal, hogy milyen ciklussal villog a led a megszakításba.

No ezt nem néztem tényleg, de nem gondolom bár nem lehetetlen. Mondjuk unsigned long változót hoztam létre, ezért nem gondoltam ilyenre. Mindjárt megnézem long long-on is mit csinál aztán szkóp.

ui: ugyan az az eredmény.

Ebbe a hibába már én is beleestem.
A timer nem 255-től 0-ig számol, hanem 0-tól 255-ig.
Azaz ha 1-et írsz bele, akkor tonábbi 244-et fog még leszámolni!

Megmértem és tényleg benéztem. 0x01-es előtöltéssel 107.4uS 1 megszakítás, 0xFF előtöltéssel pedig 7.8uS.
Most padlót fogtam, mert akkor az elméleti számolások szart sem érnek.

Újra mérek és számolok.

Azért azt gondold át, hogy 200nsec-enként (azaz 2 utasításciklusonként) szeretnél egy olyan megszakításkiszolgáló függvényt futtatni, aminek a végrehajtási ideje több microsec, azaz vagy 30-40 utasításciklus. Ez világos, hogy nem fog így normálisan működni.

Írtam egy rövid rutint az időzítés beállítására.
A legrövidebb ciklus ami stabil, 2uS.
Bár C-ben nem tudom, hogy össze lehet-e hozni.
Lásd a képeken.

Igen, furcsa is volt.
Újra számoltam és így sajna nem is férhetne bele a 44.1kHz megszakításba egyetlen olvasás sem, nem hogy egy kiértékelés.
Pl.:
1. 1 byte kérése 68,736uS alatt fut le
2. 1 byte és minimum 1 semleges parancs kiértékelése 105,25uS
3. 1 byte és minimum egy érvényes parancs 108,47uS
4. 1 byte flash-ből érvényes parancssal 122,436uS
5. 4 byte-os cím olvasása 494,04uS

Bármelyik pont ideje több mint Timer2 44.1Khz-es megszakításom 22.6uS ideje.

Köszi srácok, valószínűleg régebben is ezért hagytam abba ennek a projektnek a tovább fejlesztését. Most szkóppal is ránéztem és PCM adatot nem tartalmazó adatfolyam feldolgozása közben a 22.6uS m-os megszakítást elhúzza ~94-150uS időre. Ha PCM adat is van, akkor nagyon durva az eltolódás ~ 330uS, amely már erősen hallatszik is a zene lejátszassa közben. Előbbinél még optimális és élvezhető a zene.
Ugyan ezen projektet elkészítettem 18F64K22-re, majd ott is megnézem mi a maximum amit ki tudok hozni és ha az is gyenge lesz és márpedig az is az lesz, csak hangyányit erősebb, akkor ezen projektek félre is lesznek állítva és már elkészült egy ARM-es verzió, amellyel remélem jobb eredményeket lehet majd elérni. Megjegyzem, hogy már az is egy változatban játssza szépen a zenéket.

Szerintem 16 bit PCM-et ki tudnál olvasni a memóriából 44.1kHz sebességgel, az még beleférhetne a rendszer teljesítményébe, de az ugrándozás a memória címek között már nem. Az nem működne, hogy a lejátszandó zenét feltöltéskor PCM adatfolyamba konvertálod, és abból játszod le?

Ehhez nem értek, legalább is ahhoz nem, hogy egy VGM adatstruktúrát hogyan tudnék egy az egyben PCM adatfolyammá konvertálni. Nem foglalkoztam mélyebben a témával, csak az adatok alapján történő feldolgozással Most behoztam a 18F46K22-őt, megnézem az mit hoz, milyen eredményeket. Az 64MHz-en ketyeg.

Mivel a számaid és a 22.6uS között nagyságrendi eltérés van, nem hiszem hogy egy másfélszeres gyorsítás megoldaná a problémát. Ki tudod számolni, hogy hány bájtot kell legrosszabb esetben kiolvasni a memóriából és hogy mennyi az átlagos bájt szám mintánként. E mellé teheted az SPI órajelet és pontosan kijön, hogy mennyi a késleltetésed. Ha minden hangminta alatt feldolgozod ami hozzá tartozik, akkor kell a legrosszabb esettel számolni, ha előre pufferelsz, akkor az átlaggal.

PCM adatfolyammá úgy konvertálod, hogy pontosan ugyanazt hajtod végre, amit most a PIC csinál, csak nem valósidőben, hanem ahogy a csövön kifér a PC-n, és simán fájlba vagy bájt tömbbe írod az eredményt.

Igen, VGM fájlok pontosan ilyenek, nyers adatok vannak benne, pl így néz ki egy PCM adat:

Írtam egy programot, ami az adatfeltöltést végzi PC-ről és a PC programban egy rész kinyeri a PCM adatmennyiséget, hogy azt kísérletezésként fel tudjam használni.
A VGM fájl eleje pedig így néz ki, ezt csak ellenőrzés miatt emeli ki a PC-s program az adatfolyam elejéről.

Üdv!

Megoldottam, kicsit másképpen, de mintha működne a dolog.

Szóval jumperrel le tudom választani a perifériák tápellátását is és a PICKIT programozó lábait is. Még nem tudtam teljesen kipróbálni, mert sok forrasztás van még hátra, de ma sikerrel jártam. A kapcsoló átbillentésével tudom programozni és a másik állásban simán megy, a blink és a PWM- is.

A Pickit-3 mikor végez a feltöltéssel nem ad tápot tovább, nem üzemelteti a dsPIC-et tovább. De örülök neki, mert amit elterveztem végülis megy.

A RAM-ot és a DAC-ot csak később forrasztom be, mert elég volt egyelőre. Az ólommérgezést is el kellene kerülni. Mondjuk építettem egy elszívót is PC ventillátorokból, az is megy, de néha azért megcsap a páka szele. Teljesen kezdő vagyok a forrasztásban.... (is)

Annyit azéert még megjegyeznék, hogy eléggé süni már most is, de még így is sokkal-sokkal jobb, mert a breadbordon még a blink is kihívás. Rengeteg a kontakt hiba, nem lehet tesztelni a RAM-ot DAC-ot, mert az ember nem tudja mi okozza a hibát.

Szóval kösz mindenkinek, és jelentkezem még, ha lesz kérdésem, de most Egri Bikavér lesz a terítéken!

Hali!
Nem értem azt a táp mizériát... A pickiten nem kell engedélyezni a tápfesz bekapcsolást, a cucc megy a saját tápjáról, akár 3.3V akár 5V, a pickit csatin legyen ott a cucc tápja, a pickit3 meg "igazodik" hozzá automatikusan, nem fog 5V jelszintet kiadni a 3.3V-os cuccodra, megy a programozás-debugolás minden varázslat nélkül

Szia Bakman Köszönöm a segítségedet! Igaz, hogy több hónapja írtad a segítséget, de azóta sokat foglalkoztam, hogy-hogyan oldjam meg, hogy pl. három vagy több gombra más program induljon. Én csak tanulgatom a programozást, tőletek tanulok. /lopom a tudást!/ Ez lehet alprogram vagy közvetlen beírt prg. Sajnos nem sikerült eddig megoldani. Van egy olyan problémám, hogy három gombra külön dallam menjen. /Sajnos a nejem súlyos mozgáskorlátozott, és kell egy dallam a csengetésre, egy a kapunyitásra, egy meg ha pl. az udvarból be kell jönni segíteni. Két PIC12675-el megoldottam két dallamot, de hiába próbálom berakni a PIC16F877-be, amit javasoltál, már az első sornál kiakad a mikroC PRO for PIC programozó. Az eredeti kérdésem itt van Felmerült, hogy nem jó programozót használok, mivel a C-re több is van? Az a kérdésem, hogy milyennel próbálkozzak, hogy meg tudjam oldani? Kérem hogy segítsetek, amit előre is nagyon köszönök!

PICKit2 programozóval szépen lehet ezeket a PIC-eket programozni.
Írod, hogy Szerintem ez a mostani vagy is az első hozzászólásodban lévő program pontosan így működik, csak ha jól látom egy gombra van definiálva.
Több gomb is megvalósítható, csak a megfelelő fizikai részt meg kell építeni hozzá. (pont úgy mint az 1 gomb esetében, csak azt 3 szor vagy ahány gombot akarsz, itt érdemes a PIC manuálját megnézni, hogy mely lábak szabadok és melyikekre akarod kötni a gombokat)
Úgy látom, hogy programodban a PORTB.F0 bitre van kötve a gomb, de a beállításoknál a teljes prot bemenetre van állítva, szóval azokon vagy nincs semmi vagy csak simán bemenetre állította a készítő. (ez szerintem így, amúgy sem jó, TRISB = 0b11111111
A nygfigy(); függvénybe figyeli a gomb kezelést: (ez a függvény minden ciklusban lefut)

Így talán jobban érthetőbb lesz számodra a programod működése, ezen elvek mentén már nem olyan bonyolult megírni a hiányzó részeket.

Üdv. Don_peter! Köszönöm a választ! A PICKit2 programozóval töltöm PIC-be a programokat. A PORTB 0, PORTB 1 és a PORTB 2-en vannak nyg-ok. Igen, jól látod, hogy az eredetinél egy gombnyomásra lép a következőre, én azt akarom, hogy a 3 gombbal három különböző dalt, vagy programot lehessen indítani. A héten próbálkozok vele játszani. Még egyszer köszi a segítséget!

Ez új információ. Lehet egy teljesen új kérdést kellene feltenned az összes releváns információval, hogy érdemben lehessen segíteni.
Pl.: milyen PIC-re szeretnéd megvalósítani az átdolgozást, pontosan hány gombot és azokat mire akarod használni. Van e kiindulási alap, amelyet tovább akarsz fejleszteni. Van e kapcsolási rajz, amely alapján fel lehet mérni mik a lehetőségek és hogyan történt a megvalósítása a mostani rendszerednek. Ezek a fontosabbak.
Majd ezek után írhatnád le, hogy mit szeretnél, hogy az eszköz csináljon és azt melyik gombokra.
Az első bejegyzésedben illetve az ott megosztott programkódban látom, hogy egy PORT csak a LED-ek vezérléséhez van használva. Pontosan minek a fényjáték? Ez a fény valamit vissza jelez? Vagy csak azért van mert jól néz ki? Lényegében van értelme?

Ha pl, gombnyomásra külön dallamot kell lejátszani az eszköznek, akkor nem pontosan annyi gomb kellene, amennyi dallam van? Vagy 2 gomb és azokkal kiválasztani, hogy melyik dallamot játssza le. (a 2 gombos választás, az egyik gomb léptet a másik gomb regisztrálja a választást) Utóbbi esetben kérdés, hogy egy vészhelyzet esetében mennyire jó ez a megoldás. Minden képen a régi programot akarod tovább fejleszteni vagy akár egy új is jó lenne? Fontos, hogy MicroC-ben legyen? Kb. ezek vannak bennem a kérdéseddel kapcsolatban.