Miért nem jó az internal RC ? Nem fontos a 100% ig pontos frekvencia de azért nem lenne baj ha közel járna a beállított 8 Mhz-hez

https://microchipdeveloper.com/8bit:extrc
Ha mindenáron RC-t szeretnék, betennék saccra egy kondit, meg potmétert, és megnézném hol ketyeg...

Ha nem akarsz quartzot, akkor még a kerámia rezonátor szerintem mindig jobb megoldás. 3 lábú kis helyet foglal. Ha lábas alkatrész nem fér el, akkor van extra kicsi SMD is: 3.2 x 1.3 x 0.7mm

Nem a kvarccal van a baj hanem a hiányával Mindig kvarccal mennek az áramköreim de most éppen 8mHz kellene de nincs itthon olyan kavics , és legalább egy hét mire eljutok a "bótba" a próbához viszont tökéletesen elég lenne az RC oszci is ...

Sziasztok Mesterek!

Egy kis megoldanndó problémám lett megint sajnos. Elkészítek egy próbanyákra forrasztással egy PIC+RAM+DAC dolgot. A +3.3V és a GNDt-t egy kétpólusú kapcsoló választja ki, hogy a PICKIT-3 vagy a rákapcsolt külső tápról működjön. Erre azért van szükség, mert programozni is szeretném, meg tesztelni is, mert a dugaszolós próbapanel rengeteg kontakthibát adott, sokszor el sem indult, gondoltam beforrasztok pár dolgot.

No de a probléma:
Az általam megírt program az RB0-ra a RAM CS lába és a RB1 pedig az SPI óra jele. Namármost épp ezt a két ábat használná a PICKIT3 is, mikor programozza. Mikor a kódot töltöm rá, akkor szerintem nem gond, azonban mikor PICKIT3 végez a feltültéssel akkor ha elkezdi futtatni a kódot akkor gond lesz? Illetve, ha a kapcsolóval átállok renddes futásra a PICKITeltávolítása után,a akkor az óra jel ki lesz vezetve egy szabadonálló kis tüskére. Mondjuk ez jó, mert szkóppal rá lehetne nézni. Szerintetek ez mehet, vagy át kell szerveznem a kódot, hogy a PICKIT lábai más funkciót ne lássanak el. Bár ez szerintem nem jó, mert akkor inkáb külön lábakat csináltak volna neki, mert ígyfeleslegesen pazarolnának értékes lábakat.

Köszi!

AVR-ezek, nem PIC-ezek, de ebből a szempontból ugyanaz a kettő:

A táp átkapcsolása jó megoldás lehet programozáshoz, de arra figyelni kell, hogy minden ami áram alá kerül programozáskor, az bírja azt a feszültséget (például ha a programozó 5V, de az áramkör 3.3V). Illetve, hogy a két tápot véletlenül se kapcsoljuk egymással szembe! Én a negatív oldalt közösnek szoktam hagyni és csak a pozitív oldalt teszem kapcsolhatóvá. Legutóbb két tüskével oldottam meg, ami normál módban egy jumperrel zárva van, és így táplálja az áramkört, programozáskor pedig az egyik tüskére megy a programozóból jövő táp. (Ha a negatív oldal egyszerre be van kötve a saját tápjáról és a programozóról, akkor pedig arra kell figyelni, hogy ne legyen földhurok!)

A programozó lábak használatakor arra kell figyelni, hogy programozáskor ne tegyünk tönkre valami perifériát, illetve a perifériák ne zavarják a programozást. Ez egyedi elbírálást kíván, hogy kitaláljuk mi fog történni programozáskor, előáll-e valami nem kívánt eset? Tönkretevés ellen biztos védelmet ad, ha van a PIN-ek között van egy 470Ohm ellenállás. Ez 5V esetén kb 10mA korlátot ad, amit elbírnak a csipek, lásd adatlap. Például ha a programozó direktben van az MCU lábakra kötve, de a periféria 470Ohm-on keresztül, az jó megoldás. A PICKIT programozót elvileg direktben kell az MCU lábaira kötni, ha helyesek a neten talált rajzok.

Sajnos nem találtam dokumentációt arra nézve, hogy a PICKIT lábainak kimeneti ellenállása mekkora. Klónoknak van kapcsolási rajza, de eredetit nem találtam. Úgy tudom, hogy a programozók kimeneteit egy nagyimpedanciába is kapcsolható bufferrel szokás megvalósítani, azt tippelném, hogy egy gyári PICKIT 3 is ilyen, de klónok esetén már bármi elképzelhető.

Egymás zavarása ellen véd, ha programozáskor a periféria nincsen táplálva, aktiválva, vagy ha a periféria sokkal nagyobb értékű ellenálláson keresztül van bekötve, mint a programozó. Tehát a 470Ohm-os ellenállás erre is jó, a programozó majdnem tökéletesen tudja vezérelni a vonalat függetlenül attól, hogy a periféria "mit akar". (Feltéve, hogy a PICKIT kimenetén nincsen ellenállás. Ha van rajta például 470Ohm, akkor a perifériát péládul 10kOhm-mal leválasztva megint csak a "PICKIT lesz az erősebb".) Mivel a RAM számára ezek a lábak bemenetek, ezért nem lesz problémád.

Az esetedben szerintem a RAM-ot működésre fogja bírni a programozó, de mivel a RAM számára ezek input lábak, ezért nem fog hibát okozni. A RAM kimenetei ne legyenek szembekötve a programozóval közvetlenül!

Amikor a PICKIT végez a feltöltéssel, akkor szerintem "magas impedancia" módba teszi a lábait, azaz úgy csinál mintha ott sem lenne. Tehát nem zavarja a működést. De biztos nem vagyok benne, utána kell nézni, vagy ki kell próbálni. A próbához be lehet tenni egy 470Ohm-os ellenállást a PICKIT és a PIC lábai közé, hogy biztosan elkerüljük a szembe vezérlést. Ha a PICKIT lábán a feszültség követi a PIC lábán lévőt (akár multiméterrel is mérhetjük, ha egy lassan váltogató próbaprogramot írunk), akkor az azt jelenti, hogy magas impedancia módban van.

Srácok, egy régebbi projektemmel kísérletezgetek, amely zenét játszik le. A pontos időzítés miatt timer2-t is használom. A timer2 megszakítás és a zene lejátszás működik is rendesen, ahogyan azt akartam, de van egy összeférhetetlenség és nem értem miért, vagy hogy meg e lehet egyáltalán oldani.

Az eszköz bekapcsolását követően elkezdi az előzőleg feltöltött adatokat feldolgozni (spi memóriában vannak az adatok) timer2 megszakításban, majd ha újabb adatot akarunk feltölteni rá, akkor USB illesztése (ezt a részt értsd UART-on történik a feltöltés) esetén egy főprogramban lévő ciklus vizsgálja, hogy jött e adat. Ha nem akkor nem csinál semmit, ha érkezett, akkor megkezdi a fogadást és feltöltést. (SPI memóriába tölti bele az adatokat)

Ez eddig a működése volt, ahogy működik illetve működnie kellene.
A gondom az, hogy UART is megszakításban van kezelve, UART magas prioritású megszakításban van, timer2 pedig alacsony prioritású megszakításban van elhelyezve.
A probléma akkor jön, ha mind kettő megszakítás engedélyezve van, ilyenkor mikor UART-on érkezik adat nem veszi észre a megszakítás és olyan, mint ha nem történne semmi, de ha kikapcsolom alacsony prioritású megszakítást (ebben az esetben a program zene lejátszó része nem működik mert timer2 megszakítás végzi az adatok pontos időzítését és betöltését) akkor pedig simán észreveszi és működik a dolog a feltöltés.

Hátha találkozott már valaki ilyesmivel, mi lehet a gond?
Ahogy írom a sorokat, arra gondolok, hogy nem e az a baj, hogy a folyamatos timer2 megszakítás miatt elvész az UART-on kapott adat.
Ezt most gyorsan ki is próbálom.

Ellenőriztem és arra jöttem rá, hogy a timer2 megszakítás olyan gyorsan történik, hogy azt elindítva a fő program le sem tud futni, így ezt a problémát fel is derítettem. Megoldásként jelenleg gombbal indítom a timer2-őt, így elérhető a feltöltés is. Majd lehet egyszer újra szervezem, bár kétlem, hogy ez így megfelelne nekem, mert a PCM feldolgozáshoz kevés a 40MHz, amit ez a kis PIC18F452 tud.
Itt hagyom, hátha valaki még fut ilyen hibába és talán kap belőle némi támpontot.

Gondolom a zene lejátszás úgy történik, hogy az SPI memóriából streameled a PCM-et, igaz? Meg kell próbálni optimalizálni valamit a programon, hogy mégis beleférjen a két minta közötti időbe a minta betöltése és lejátszása. 40MHz az 44kHz esetén is majdnem 1000 órajel mintánként. Titkos a kód? Érdekelne, hogy hogy működik.

Üdv, köszi a választ, elfoglaltak nem tudtam válaszolni eddig.

Az SPI RAM (23K256, ami 3.3V-os):

https://www.tme.eu/Document/6c54ffd5e12f5b639d09717876b1d8cc/P-Micr...04.pdf

Az SPI DAC (MCP4821, 12bit, én 3.3V-ról hajtanám meg)

https://ww1.microchip.com/downloads/en/DeviceDoc/22244B.pdf

A feszültég a DAC-nál max 6.5V, A RAM-nál 4.5V. DE ezek az értékek a halálukat jelentik. Namármost a PICKIT3-al mikor töltöm vele az adatokat, akkor a MPLABIPE-ben 3.3V-ra van állítva, de ezzel nem akarom megoldani a biztonságot, mert baj lehet belőle.

Az adatlapokból nem tudtam pontosan kivenni a lábakba befolyó max áramokat, de mintha DAC- input lábán az áram 2mA lehet maximum, de az már megöli. Az adatlapból nem látom, hogy mekkora a bemeneti ellenállása, mert nem vágom a témát sem és az angolt sem, de ha korlátozni kellene az áramot mikor a PIKIT3 van rajta, akkor a 470Ohm mintha kevés lenne. 5K, de inkább 10K lenne jobb nem? Totál belezavarodtam, bocsi!

De ha így is járok el, azaz ha 10K jó lenne áramkorlátozásnak, akkor mi történik a DAC-al és a RAM-al, ha 5V-ot kapna véletlenül? Megöli őket? Rápillantanál az adatlapjukra, mert én már 5-6 adatlapot nézek szimultán, belekeveredek rendesen.

Csatolom a móricka rajzot amivel szeretném megoldani. Az történne, hogy a kapcsoló egyik állsán a PICKIT3 felől kapná a feszt és áramot, majd a másik állásban akkor a normál 3.3V-ot. Szóval ELVILEG a PICKIT, ÉS HA nem felejtem el beállítani a programban, hogy 3.3V-legyen ÉS még véletlenül sem ad ki 5V-ot, akkor mehetne a dolog, de inkább a biztonságra mennék rá.

Minden segítségnek örülök, kösz mégegyszer az eddigieket is!

Sziasztok!
A PIC16C55 és 16C57-ből kiolvasott .bin fájl beégethető-e egy-egy 16F55 és 16F57 tokba és megfelelően fognak-e működni? Az adatlapok alapján kb ugyanazok, de ugye a C-s csak egyszer írható.
Nincs sok tapasztalatom a PIC-ekkel, de rémlenek valami kapcsoló bitek, code protect stb. Ezeket is tartalmazza a .bin fájl?
Egy TL866II Plus programozóval olvastam ki és azzal is írnám az újakat.

44.1KHz-en megy a timer vagy is a megszakítás. A PCM adatot előre kiszedem és elmentem a flash-be, hogy a lehető legrövidebb időn belül tudja olvasni. Az SPI nem tud 40MHz-t, nem a memória miatt, hanem a PIC miatt. 40MHz max órajelet csak akkor tudnám vagy még akkor sem elérni, ha csak az lenne más nem. Vagy assemblerben még lehetne optimalizálni, de annyira ahhoz nem értek, hogy jobb kódot írjak benne, mint C-ben.

SPI a jelen beállításokkal max 10MHz, az adatokat SPI-ből olvasom ki, legalább is azon részeket, amelyek nem PCM adatok. Ez egy VGM vagy is video game music fájl, nem egy MP3 vagy wav. Úgy vélem kevés lesz ez a PIC a teljes és stabil lejátszáshoz.

Én 44.1kHz mintavételezésű audio lejátszással biztos nem kísérleteznék 8 bites mikrovezérlővel. Ehhez szerintem minimum feltétel az i2s periféria (amihez az audio dac-ot rá lehet akasztani), a dma képesség, annyi ram memória, hogy ne 1/100 másodpercnyi hanganyag férjen bele, ha sd kártyán van a hanganyag akkor nem árt ha azt nem spi-vel hanem natív módon tudja olvasni. A hab a tortán, ha az i2s órajele kívülről is beadható, és nem csak valami közelítő mintavételi frekvencia állítható elő ilyen-olyan órajel osztókkal és pll-ekkel.

Ezért írtam feljebb, hogy nem szokványos WAV vagy MP3, hanem VGM vagy is videó játék zene fájl. Egy YM2612-es szintézert hajtok, ami 8bit-es plusz vezérlés. PCM nélkül szépen le is tudja játszani a 18F452-es, viszont, ha van PCM adat is, akkor köhög tőle. Sajnos még a 18F46K22-is a maga 65MHz-ével. De azzal még lesz kísérletem. PCM adat esetén vagy azonnal (ha kisebb a hangminta mint 10kbyte) bufferbe küldöm vagy a PIC falmemóriájába írom és onnan olvasom, ha kell. De tényleg ki kell hegyezni, hogy használható legyen.

Azt vedd figyelembe, hogy a flash memória írása jóval lassabb mint a sima ram-é, ha meg folyamatosan írogatod akkor meg nem lesz túl hosszú életű sem.

Csak egyszer kell írni, ha van PCM. Legalább is 1szer az első indításnál. Tudom, hogy lassabb, de kísérletnek jó, és úgy emlékszem pár kbyet-nál nagyobb tömb változót nem tudtam létrehozni még mélyen a memória szervezés ellenére sem a PIC18F452-nél. Ez ilyen facsargasd amid van itthon projekt..

Még ide, annyit, hogy igaz, hogy 1 utasítás (órajel) jó esetben 25ns, de vannak olyan utasítások, amelyeknek több órajel is kell még végbe megy. A C nyelv pedig nem bánik szűkösen az idővel, tehát sok elmegy "feleslegesen". Optimális esetben kicsit több mint 900 (907) órajelünk van a 44.1KHz-es jelek közt, de ez a 22.7uS elég kevés, ha mondjuk le kell kérni az SPI memóriából adott címről az adatot (megjegyzem, hogy SPI-s flash memória, amelynek szekvenciális az olvasása és az írása is, ami annyit tesz, hogy jó sok utasítás 1 adat vétele) azt kiértékelni és a megfelelő időzítéssel visszatér. Érzésem szerint a PCM esetében vissza sem tud térni ezért vagy torlódás vagy felülírás történhet. Ha bár szerencsésen úgy írtam meg a megszakító rutint, hogy csak akkor engedélyezi újra, ha a kiértékelő rutin visszatért. Tehát maximum lassulás fordulhat elő, és ez van is PCM esetében. Tudni kell, hogy a VGM egy szekvenciális adatfolyam, amely tartalmaz PCM adatot is, a PCM adatokat mindig másként kell kezelni mint a normál szekvenciális adatokat, így párhuzamosan kell a kettő adatot kezelni. Ha szekvencia oda kerül, akkor a PCM adatban kell olvasni vagy ugrani adott pozícióra, ha kell pedig a szekvenciálisan haladunk az adatfolyamon tovább. Elsőre bonyolultnak tűnik, de jól ellehet vele játszani.
Ha érdekel a téma itt találod a felépítést: VGM_Specification

Az SPI írást/olvasást blokkoló módban teszed? Ha átírod interruptosra, akkor a várakozás nem viszi a CPU-t. Ha tartasz egy néhány bájtos puffert, akkor a feldolgozásnak sosem kell várakoznia, és akkor beleférhet az időbe a lejátszás talán. Hány bájtot kell átlagban és maximum kiolvasni és feldolgozni egyetlen mintaidő alatt? Ez az adott SPI órajellel mennyi időt vesz igénybe? Ezekből nagyjából meg lehet becsülni, hogy legalább elvben működhet-e? Szép feladat!

> DAC- input lábán az áram 2mA lehet maximum, de az már megöli
A bemenet lábaknak nagy lesz a bemeneti ellenállása, nem tud ekkora áram folyni rajta, csak akkor, ha a 0 alá, vagy a táp fölé megy a feszültség. De ha aggódsz ezen a kérdésen, akkor meg lehet úgy is oldani, hogy a programozó lábakat is váltókapcsolóval állítod, vagy az egész csipet foglalatba teszed és az áramkörből kivéve programozod. Persze ennek hátránya, hogy macerás.
>De ha így is járok el, azaz ha 10K jó lenne áramkorlátozásnak, akkor mi történik a DAC-al és a RAM-al, ha 5V-ot kapna véletlenül? Megöli őket?
Ha a tápon kap túlfeszültséget, akkor tönkremehet (ha az adatlap szerint nem bírja). A tápot ugye nem szokás ellenállással védeni. Ha egy bementi lábon kap túlfeszültséget egy ellenálláson keresztül, akkor az úgy szokott lenni(nem szükségszerű, de tipikus), hogy a csipben egy dióda a tápra vezeti az áramot. A legvalószínűbb, hogy egy kicsit ettől melegszik és nem lesz semmi baja. De ha peched van tönkremegy. Tapasztalatom szerint az alkatrészek sokkal többet bírnak mint az absolute maximum rating, de erre nem szabad építeni ugye.

Elvileg már forrasztottam sok dolgot össze, tudok javítani rajta, de nem nagyon szeretnék. A másik amit elfeljtettem, hogy a DAC és a RAM gnd-je és a VDD-je teljesen leválasztható a fő áramforrásról függetlenül attól, hogy a fő áramforrás a PICKIT felől jön, vagy sem. Arra gondoltam, hogy ha nem kap semmit, akkor nem lesz baja. Szóval ez megoldott. Akkor a 470 ohm ok lesz mit ahogy a móricka ábármon van? Ki kell próbálnom, de nem olcsók ezek a RAM-ok, meg a DAC-ok a szállítási költség miatt. Ráadásul mindegyik DIP foglalatba kerül, ki is szedhetem, de éppen ezt akarom elkerülni. Azonban könnyen tehetek fel jumpert még esetleg a leválaszás miatt. De tényleg úgy szerettem volna megoldani, hogy csak egy kapcsoló és ok minden, ne kelljen sokat vacakolni.

Nem megszakításban olvasok, az sima rutin, a megszakítást csak az olvasó függvény hetivásárára illetve két adat közti pontos idő miatt illetve az egyes adatok az időt tartják, hogy az a dallamok kellő ideig maradjanak fent.
Két megszakítás van alacsony és magas prioritású, mind kettő foglalt, és egyszerre a kettő biztosan nem fog menni, mint ahogy a fentebbi ábra is mutatja. Az érdekesség nekem is amúgy pont az, hogy miért nem marad idő a főprogram lefutására, biztos, hogy a rutinból nem tud vissza térni két megszakítás közt.

Egyelőre nem tudom elképzelni mire gondolsz mikor megszakításban akarod az spi beolvasást tenni, mert ez feltételezné, hogy bufferelni kellene az adatokat, ami elég gáz mert a 18452 memóriája eléggé karcsú. 1536 byte az adat memória, amiből már csak 559 byte van szabadon. Program memóriám több, de ott meg ügye a flash elérés gázabb és kinyírná hamar a PIC-et. (bár ez utóbbi nem lenne annyira érdekes és van kb 11kbyte hely még szabadon)

Szóval ezzel válaszoltam is szerintem a kérdésedre. A memória olvasás byte-onként történik, tudom, hogy ez sokkal több idő, van illetve lenne lehetőség még elvileg 64 byte-os olvasásra, az lehet segítene, de ahhoz az egész feldolgozó rutint át kell dolgozzam bufferesre, ami megoldható lesz majd egyszer..
W25Q64FV-t használok memóriának, de most nem találtam meg benne hirtelen mennyi és hogy van e benne olyan regiszter, ami a folyamatos olvasást teszi lehetővé. Valamiért nem használtam, pedig a programot megírtam hozzá, az 64 byte-osra van korlátozva.

Én úgy tudom, hogy ha az adatlábakat a VCC fölé húzod, vagy a GND alá az nem egészséges (a tipikus, hogy a bemenetet védő diódán keresztül táplálni fogja a csipet és az azonos VCC-re kötött alkatrészeket, és így könnyen túl lehet lépni ennek az áramkorlátját). Úgyhogy jobb ha inkább tápon vannak azok az alkatrészek is amikor az MCU tápon van.
Túlfeszültség védelemre van egy standard trükk: tehetsz a tápra például egy 3.5V-os Zener diódát, ami elvezeti a nagyobb feszültséget. És akkor biztosan nem lesz nagyobb feszültség, nem tudod elrontani az áramkörödet a programozóval. Persze úgy kell méretezni, hogy a Zener le tudja húzni a feszültséget, vagy az USB-nek az áramkorlátjára lehet építeni, vagy a programozó táp felől beraksz egy kisértékű ellenállást, ami normál esetben még nem zavaró, de a Zener maximum árama mellett már leesik rajta az 1.5V. Pl ez: https://www.hestore.hu/prod_10026227.html és a programozó táp bemenetre egy 4.7 Ohm-os ellenállás megoldja, hogy ha 5V kerül a bemenetre, a VCC akkor sem tud kb 3.6V fölé emelkedni és kb 300mA fog folyni a Zeneren keresztül.

A migrációs doksi szerint nincs funkcionális különbség. Ha nem kódvédett, akkor amit kiolvasol az simán áttölthető az F-es változatba. Intel hex-be ments le, abban biztosan benne lesz a config word is.

Én fordítva vagyok vele! Az eredeti rajza megvan a Microchip oldalán, nekem kinai klónom van ahhoz kéne rajz. ( ha van ötleted honnan lehetne szerezni ... ).

Az jó, ha van kapcsolási rajz, én nem sok időt fordítottam a keresésre. Linket is adsz rá? Biztos lehet tanulni belőle.

PICkit™ 3 In-Circuit Debugger/Programmer User’s Guide
Kapcsolási rajz: 67-68 oldal

Arra gondoltam, hogy az SPI órjelére fentebb írtad, hogy a 40MHz negyede, tehát egy mintára kb 250 órajel jut. Egy bájt átvitele SPI-vel 8 órajel alatt történik meg (gondolom nem valami trükkös QSPI vagy hasonló játszik), tehát osztunk és 31 bájtot tudunk átvinni az SPI-n egyetlen minta ideje alatt. Egyetlen kiolvasást 4 műveletnek tippelek: parancs, cím(2 bájt), adat. Ha így van, akkor 7 bájtot tudunk kiolvasni egyetlen minta ideje alatt, de akkor már csak ezt csináltuk, semmi mást. Ha valóban blokkoló módon használod az SPI-t, akkor valóban 1 bájt küldése vagy fogadása legalább 32 órajelet várakozik és ez elvesztegetett idő. Ez lehet a válasz arra, hogy miért érnek egymásra a megszakítások: a kiolvasás ideje alatt interruptban várakozik a CPU. Plusz még a DAC kimenet is lehet, hogy hasonlóan optimalizálatlanul van megvalósítva és már el is telt a rendelkezésre álló kb 22 mikroszekundumunk.

> már csak 559 byte van szabadon
Szerintem 1-2 mintát kellene pufferelni, annyi azért elfér még ebben a karcsú memóriában is. Egy két mintás ringbuffer 8 bájt az "adminisztratív adatszerkezetekkel" együtt

Tényleg látni kellene hozzá a kódot, de majdnem biztos vagyok benne, hogy sokat lehet javítani ezen még.

Néhány alternaív ötlet:

* Főprogram olvassa a mintákat és egy ringbufferbe teszi (ez lehet 1-2 mintányi méretű is) őket. Így az interrupt felszabadul, az időzítő interrupt csak kiteszi a mintát a DAC-be a ringbufferből, más dolga nincsen.

* A minta beolvasást memóriából interrupt végzi állapotgéppel 1-2 mintát pufferelve. Hátránya, hogy nagyon sűrűk lesznek ezek az interruptok, de kettő között mégis maradni fog egy kis idő "gondolkodni".

* A memória műveleteket úgy csinálod, hogy átlapolod más teendővel:
** SPI felprogramozása
** más feladat elvégzése
** Várakozás SPI végére - mivel az SPI teljesen kiszámítható időzítésű a master oldalon, itt ha a más feladat pont annyi ideig tartott, akkor valójában nem is lesz várakozás

* A zenét előfeldolgoznám PC-n, és mintánként 1 vagy két bájtos PCM folyamként tölteném a mikrovezérlőre, így minden periódusban pontosan ugyanazt kell csinálni az MCU-nak, pontosan be lehet lőni az időzítéseket. Plusz ahogy írtad, ha a RAM-nak van folyamatos olvasás módja, akkor az is nagyon sokat gyorsítana a folyamaton, mivel az SPI-re várakozás saccra a felhasznált CPU idő fele most.

elveszett a bejegyzésem..

Tehát csak a lényeget írom le újra: Disassembly Listing-et nézve debugban, MPLAB-ban lépéseket megszámolva ~1200 órajel egy byte minta vétele. További mérés és számolgatás eredménye....pffffff (ami megjegyzem lehetetlen)

No már csak ilyen szórakozás gyanánt is, írtam egy kis Timer0-ás megszakítást, amit beállítottam a legkisebb vagy is a legalacsonyabb időzítésre amit ki lehet hozni belőle, az 40MHz/4/2/1-re, ami 200nS-os időt határoz meg.
Az eredmény pedig:
Az első utasítás gyakorlatilag egy byte adatot kér le SPI-n keresztül az 128nS alatt végbe megy. A WaveSample() függvény egy komplex kiértékelő függvény, amelyben benne van a lekérdezés és a kiértékelés illetve az egyéb DAC és más vezérlők, ez 196nS alatt megy végbe, ha a parancs nincs hatással semmire, vagy is semleges parancsot olvas. Ha a parancs tegyük fel 0x52, akkor az azt jelenti, hogy legalább egy esetben van kivezérlés és ezzel 202nS-ra nő egy érvényes nem PCM parancs végrehajtása.

Mind három minta esetében 100szor ismétlem és az így kapott eredmény osztom 100-al ezzel kapok egy pontosabb mérést. (Nem ciklusban nézem, hogy az ne befolyásolja az időt)

Tehát normál esetben, ha az adatfolyam nem tartalmaz PCM adatot, akkor 1 érvényes parancs kiértékelése 202nS időbe kerül, amely véleményem szerint elfogadható, mert így 44.1KHz-es időzítésbe ~112 alkalommal fér bele.
Egyébként ebben az esetben, ha nincs PCM adat, akkor teljesen jól és normálisan le is tudja játszani a zenét az eszköz, szóval ez teljesen rendben van.

Ha van PCM adat, akkor a következőképpen alakul:
Ha érkezik 0x8F parancs, amely a PCM adat következő byte-ját olvassa ami flash-be van (vigyorgó jel) 228nS időbe kerül. Tehát, ha nem is sokkal, de lassabb mint az SPI kiolvasás ideje. Ha viszont PCM adatban való címelugrásra megkapjuk az 0xE0 parancsot, akkor mivel az 4byte adatot kér le rögtön 920nS időbe kerül. De még így is 1uS alatt vagyunk.

Kérdés költői: hol van a többi idő?

Az ICSP lábakat tehát a hivatkozott rajz szerint 74lvc1t45 háromállapotú busz meghajtóval hajtja meg a PICKIT3. Ez a csip szintillesztést is csinál, illetve bemenetbe is lehet állítani. Jópofa csip, nem ismertem. Köszi!

Nekem nagyon gyanúsak a számaid, hogy jöttek ki? Pontosan mit mértél és hogyan? A 40MHz egyetlen órajele 25nS, a MemRead SPI-n keresztül kb 5 órajel alatt lefut? Fentebb azt írtad, hogy az SPI órajele fosc/4, ami 100nS lenne. Egy bájt átvitele 8 órajel periódus SPI-n. Valami nem kerek.