Csak érdeklődök, hogy mi a célja a szoftver megszakítás használatának? Miben fog különbözni egy sima paraméter nélküli szubrutin hívástól? Vagy csak annyi, hogy így szeretnéd megoldani, hogy a szubrutinodat a magasabb prioritású hardver megszakítások félbe tudják szakítani az alacsonyabbak meg ne?

Határozott idő alatt le kell futnia a szoftveres megszakításnak is, szinkronban a megszakíthatatlan magas prioritású megszakítással! Ez utóbbit rövidebb időkre meg lehet szakítani, ahogy most is történik, de összességében záros idő alatt kell ennek is lefutnia.
A főprogramnak pedig egyéb dolga is akad, semmint hogy állandóan azt figyelje, mikor kell futnia annak a bizonyos kisebb prioritású függvénynek?! Ráadásul ekkor boldog-boldogtalan megszakítaná, ami szintén nem túl jó elképzelés...
DSP jelfeldolgozás témakör....

Csak egy ötlet, nem tudom működőképes-e, ki kellene esetleg próbálni. Ha a főprogramod is megszakítási szinten futna, akkor tudná állítgatni önmagának a futási prioritását attól függően, hogy mennyire sürgős az éppen elvégzendő tevékenysége. Szóval csak egyetlen alkalommal kellene az indulás során egy ilyen szoftver általi megszakítást csinálni, ahol a megszakítást kiszolgáló függvényed lenne a főprogramod, ami ugye sosem lépne vissza. A kérdés csak az, hogy a proci képes-e futás közben változtatni az aktuális prioritási szintjét, vagy ezt csak a megszakításba történő belépéskor állítja be?
Ha így megoldható, akkor megmaradna a határozott időn belül befejezendő függvényednek a paraméterezhetősége is.

Az miért nem elég, ha megszakítás helyett egyszerűen a kritikus részben megnöveled a futási szintet? Tudtommal az IPL bitek közül az alsó 3 bit írható.

Mert a magas prioritásból nem hívhatom meg ezt a függvényt!
Főprogramból indítva meg ki tudja, mikor reagálnék a futási kérelemre! Hisz az egésznek pont az a lényege, hogy a magas prioritásban beállítódik egy flag(megszakítási kérelem), aminek hatására utána azonnal végrehajtódik az alacsonyabb prioritás is(az a bizonyos függvény), miközben a magas prioritás még számtalanszor lefut, mialatt az alacsonyabb végezne....
Nem látom át, ezen hol segítene, ha nekem kellene kézzel meghívnom....?!!

Szerintem egy ilyen szervezésű program elég nagy érzékeny ponton való szúrás lenne összességében!! ))

Nagy eltérés nem lenne, csak a verem tartalmazna plusz egy darab soha fel nem használt visszatérési címet, meg a cpu állandóan úgy futna, mint ha megszakításban lenne (meg sem néztem amúgy mi változik ilyenkor, ha esetleg írhatóak az ezt tartalmazó regiszterek, akkor még erre lépésre sem lenne szükség). Amúgy meg ha több programszálat akarsz, akkor használj valami rtos-t (pl. freertos). Az pont az ilyen dolgokra van kitalálva.

Üdv!

Valaki használt már 3 vezetékes SPI kommunikációt PIC (master) és egy másik eszköz között?
3-wire SPI:
A slave SDO és SDI pinje egyben van, míg a PIC-nél külön pinek.
Hogyan célszerű megvalósítani?
Olvastam egy fórumon, hogy az SDI-n egy 10k soros ellenállás után összekötötték az SDO-val, elvileg működik. Próbálta már valaki?
Esetleg menet közben át PPS-elni a SDI/SDO pineket?
Melyik célszerűbb?

Köszi!

Milyen eszközön közösködik az SDO és SDI láb?

Milyen PIC? Ha olyan PIC, amiben van PPS, akkor vagy az SDI, vagy az SDO-t kapcsolod a megfelelő lábra a kommunikáció előtt (attól függően, hogy adatot írsz, vagy adatot fogadsz). Ill. van olyan PIC is, aminél az SDI és SDO vonalakat le lehet kapcsolni az SPI modulról, ilyenkor akár PPS-el az SDO és SDI lábakat egyszerre is rá lehet konfiguráni ugyanarra a lábra. Ebben az esetben a kommunikáció előtt az SPI modulnál megfelelő láb használatát tiltani kell.
Viszont én a helyedben (nem tudom van-e) a PIC és az eszköz közötti közös adatvonalát úgy kötném össze, hogy egy kb. 470-1k-s ellenállást bekötnék (ha esetleg a PIC is és az eszköz is adatot küldene egyszerre, akkor egy esetleges ellenkező jelszint ne tegye tönkre a PIC-et, vagy az eszközt).

Heló!

SSD1675A 45. oldal példakapcsoláson látszik, meg le is van írva valahol.

helektro
PIC24FJ256GA702
Megnéztem az adatlapot a 204. oldalon van az SPI konfig. regisztereinek a leírása, van DISSDO és DISSDI bit. tehát ha egy pinre PPS-elem a két adatvonalat, majd a config regiszterrel kapcsolgatom ki-be őket, akkor is célszerű az ellenállás?

Köszi a választ!

Felmerült az igény nálam erre: töréspont egy változó értékének megváltozásakor.
Tudja ezt valahogy az MPLABX?

Én az ellenállást azért tenném be, hogy ha a PIC és az eszköz valami miatt egyszerre adna (teszt, programhiba, stb. miatt véletlenül előfordulhat), akkor ne menjen tönkre az eszköz, vagy a PIC. Én mindig beteszem ilyen felhasználás során. De persze mindenki úgy dönt, ahogy jónak látja. Hátrányát még nem tapasztaltam. Értelmes távolságok esetén (5-10cm) 16MHz-el soha nem tapasztaltam problémát.

Persze. Nincs előttem az MPLAB-X nyitva, így emlékezetből: Debug menüpont > Add breakpoint..., és a feljövő ablakban a legördülő menüből ki kell választani, hogy milyen típusú breakpoint-tot akarsz. Ha jól emlékszem, akkor a listában a 2. a változó figyelése. Ja igen, én ICD4-et használok, lehet más debugger ezt nem tudja, mással nincs ilyen tapasztalatom.

Igen, van olyan, hogy New Breakpoint..., azon belül van is lista, de olyat nem látok, hogy változó megváltozásakor állítsa meg...

Nincs olyan, hogy 'Data'? Azt kiválasztva meg tudod adni a változó nevét, ill. hogy írásra, olvasásra vagy mindkettőre álljon meg a program. Ill. még azt is be tudod állítani, hogy mindig álljon meg, vagy csak x. esemény után.

De, van olyan! Ahol is az sfr regisztereket ki tudom választani..., esetleg kézzel valami címet is megadni..., de név szerint hivatkozni user változóra, olyat nem látok!
És hát a reagálás feltétele sem világos számomra: van olyan hogy read, write(X vagy Y bus)... Ezeket nem tudom értelmezni, hogy mit is takarnak..., de valahogy nem azt erősítik bennem, hogy ez az lenne, amit keresek...

A Global Symbols nem aktív? Amúgy megkaptad a kérdésedre a választ és a megoldást. Lehet meg kellene ismerkedni az általad használt dsPIC működésével (X és Y bus) akkor tudnád értelmezni. Nem is értém, hogy programozol olyan eszközt, aminek nem érted a működését. Amúgy googli a barátod, kb. 5 másodperc volt és az első találtok között ott van, hogy működik a dsPIC memória felépítése. De iderakom neked, hogy neked már ne kelljen fáradni: dsPIC Data Memory

Milyen global symbols??! Nincs is olyan! Symbols van, alatta kizárólag az sfr-ek listája! Ha kézzel akarok megadni sajátot, akkor a címét is meg kell hozzá adnom! Azt is kézzel. Kösz...
Igaz, hogy DsPIC-et használok, de semmi hardver specifikus DSP utasítást nem használok, szándékosan, mert nem akarom a szoftvert konkrét hardverhez kötni!
Nem tudom te mit nézel, és milyen google huszárkodástól van ekkora arcod, de a kérdésemre nem látom a választ, csak feltételezéseket, amit kigoogliztál kb! Ezt kb a hajamra kenhetem! De azért kösz a semmit...

Személyeskedés nélkül is lehet eszmecserét folytatni magáról a témáról. Célszerű lenne tennetek egy próbát. Rengeteg személyeskedő és OFF hozzászólás törlésre került.

Köszönjük.

Üdv mindenkinek!

Egy másik fórumon tettem fel a kérdést, lehet nem jó helyre, ezért inkelem ide is, hátha valaki tudja a megoldást!

Az 1176. oldaon a PWM-gondokkal küzdő hozzászólások az enyémek.

Bővebben: Link

Köszönöm!

Az a 737287300 Hz nem 100-al kevesebb akart lenni? 737MHz biztosan nem lehet...

Igen az elírás. Ez nem okozhatja a gondot elvileg, mert az óra beállításoknál a Vco jól be van állítva, ami a megfelelő órajelet kapja, a típustól függöen. Azaz a belső óráról indul, beállítja a vco-t utána átkapcsol arra. Elvileg ez az alap frekvencia nem jelenik meg a PLL beállításában, de okozhat hibát esetleg, hogy a szimulátorokban más típust vagyok kénytelen használni, aminek a belő órája nem ekkora frekvencián megy. Így gond lehet. Megkeresem a szimulált DSPIC-nek az alap óráját, átállítok minent. Bár ez kicsit hoszabb munka, de megcsinálom.

Kicsit pontatlanul fogalmazol! Minden órajel belső, ami tokon belül keletkezik! Azon belül van RC oscillátor, és külön kvarcoszcillátor. Típustól függően ezekre lehet PLL-t húzni...
Tulajdonképpen ha szimulátort használsz, miért nem egyből azon a típuson próbálkozol, amit használni szeretnél? Nem teljesen értem...

Mert azt a típust nem ismeri a szimulátor. A Proteus-ban egész egyszerűen nincs. Elvileg a két PIC nagyon hasonló, sőt az alapjaiban teljesen meg is egyezik.
Amúgy tényleg pontatlanul fogalmazok, mert elsőként tényleg belekeveredtem az oszcillátor beállításokba!

Megnéztem, ez is 7.37MHz belső órával rendelkezik.

Amúgy kissé elgondolkodtató, hogy ez első két csúcs között 10ms van, a második és a harmadik között pedig 20ms, ha jól emlkszem. Mintha egy 100Hz-es alapból indulna ki és egész számú többszörösei jelennének meg. Mintha a a Fourier-hez lenne köze, vagy csak valamilyen két frekvencia(különbség) legkisebb közös többszöröseként jelennének meg ezek a tüskék. Egyelőre nem értem sajnos...

Nem tudom, mi az a Proteus..., de szimuláláshoz szerintem célszerűbb lehet az MpLabX-et használni! Mégiscsak az a hivatalos fejlesztői környezet PIC-ekhez..., és nincs többé az, hogy nem támogatott típus...
Egyébként szerintem érdemesebb nem a periódusidőn keresztül adott bitszámra húzni a PWM-et, hanem fordítva, adott periódusidőt számolni, majd a hozzátartozó felbontást átskálázni 8 bitre(vagy amennyire szükség van)

A Proteusban lehet áramköröket is rátenni, kondit, ellenállást, virtuális oszcilloszkópt stb. Az MPLAB-X-ben minden jónak tűnik, de a Proteusban megjelennek ezek a tüskék. Most átírtam mindent 7.37MHz-ből származtatott értékekre, le is vettem a szűrőt, úgy is megnéztem a Proteusban a szimulált PWM jelet, de továbbra is gond van a PWM-el.

Megpróbálom sokkal alacsonyabb frekvenciájú PWM-el, és egyszerűbb kitöltési tényező váltással.

Talán a Proteus a hunyó?! Ez fel sem merül benned? )

Üdv!

Megvan a gond! Túl nagy a PWM frekvencia, nem ment rendesen. Közel a csúcson, vagy még annál is magasabban ment volna esetleg, ezért nem ment. Legalábbis a Proteusban nem. Most levettem a PWM frekvenciát 10KHz-re, a P2DC1 értékét kiszámoltam az adott óra frekivel (7950), és a kitöltési tényezőt enek megfelelően változtattam.

P2DC1 =(unsigned long int)(7950/256)*t3_szamlalo;

Ahol 256-ig megy a t3számláló. Mindez a t3 interruptban van. Most mintha menne rendesen, csak a jelem nem szép, a szűrőt kell még igazítani hozzá.

De, különben eszembe jutott, hogy az a hunyó, de nem tudom leellenőrizni valós oszcilloszkóppal sajnos. Ezért kell elsődlegesen erre támaszkodnom, majd ha tudok szerezni szkópidőt akkor le is ellenőrzöm.

Ha nem teszem fel a kérdést, és nem válaszolsz, akkor ülök itt magamban és nem próbálom ki alacsonyabb frekvencián. Ez aggaszt inkább...

Köszi a segítséget!