Mivel csak egy gyors mérést akartam nem ültem neki rendesen összeszedni mindet, hiba volt...

Össze szedtem amire szükségem van és amire nem, mindent IO-t beállítottam.
A nem használt bementek pull down, egy analog láb, egy RX egy TX és egy láb 0-ra van lehúzva mert abban nem volt pull down.
Így kihoztam az 5µA-t aminek örültem.

Amitől viszont szomorú vagyok hogy ha be kapcsolom az UART-ot 150µA-r egyenlőre FRC-ről megy lehet ez a gond megnézem majd 32.768-ról is hátha (alacsony baud kell csak).

Némi szenvedés árán, WAKE bit törlődik ébredés után, dummy az első receive és hasonlók sikerült 50µA kihozni a jószágból.
Ezt a (32.768k) secondary-ról hajtott REFCLK-al (12k) 300-as baud és egy ADC aminek a PMD-je = 0-val sikerül összehozni.

Sziasztok! A készülő PIC-es aramköröm elemes megtáplálásaval kapcsolatban kérdeznék. A PIC-hez 5V, a Shiftregiszteres áramkörömhöz 15V-ot használok, 3 db sorba kötött 9V os elemről akarom táplálni úgy, hogy a 27V-ot (XL4005-ös IC-ét tartalmazó, kínából rendelt) kapcsolo uzemű tápokat használva csökkenteném le 15V-ra illetve 5V-ra. Tudom ,hogy a PIC nem igazán szereti a kapcs üzemű tápokat, ezért bizonytalan vagyok , hoyg jó lesz -e így. Még arra is gondoltam, hogy a kapcs üzemű tápok kimenetére tennék egy 7815 illetve egy 7805-ös stabkockát, viszont így a stabkocka bemenetére 2-3V-al nagyobb feszültséget kell állítsak, hoyg normalisan tudjon a stab IC szűrni és a stabIC-ék disszipálnak is rendesen, ami pedig az elemek gyorsabb lemerítéséhez vezet. Mi a véleményetek a fentiekről ? Szerintettek csak a kapcsolóuzemű step down táp áramkörökkel stab IC-ék nélkül jó lehet a megtáplálás? Köszi szépen!

A 9V-os elem, és a kapcsolóüzemű táp, aminek 3-5mA saját fogyasztása már akkor le fogja meríteni az elemeket, ha semmi más nincs bekapcsolva, bekötve! 9V-os elem helyett valami mást keress. Magas a belső ellenállása, kevés tárolt kapacitás, stb.
Azt írtad, tápokat. Ebben az esetben 100%, hogy felejtős ez a megoldás! A kapcsoló üzemű tápok fogyasztanak 6-15mA-t, a PIC-kel meg majd küzdesz, hogy 100uA alatt legyen a fogyasztása, teljesen feleslegesen.

Pont ahogy Kovidivi előttem írta. - mondjuk ez a kérdés nem értem mit keres a haladóknak csoportban, de mindegy -
Szóval az elektronikai alapokat kéne kicsit tisztába rakni, fogyasztásokat számolni, elvárt üzemidőt meghatározni. PIC-nek semmi baja a kapcsolóüzeművel, de alacsony fogyasztáshoz LDO jöhet szóba. Vannak ultra low fogyasztású LDO-k. Nem a 78xx kategória, mert az 30 évvel ezelőtti technológia, 1-5mA készenléti árammal. 9V elemeket csapolhatod, ne 27V-ból állítsd elő a PIC feszültségét, hanem 9-ből.

Ennél már sokkal jobban hangzik, ha 2X9V-ot használsz csak, és ldo-stabbal csinálsz belőle 15V-ot! Az 5V, ha minimális a fogyasztás, akkor egy kis fogyasztású stabkockával(nem 78xxx és társai!), ha kicsit nagyobb a fogyasztás, akkor érdemes kapcsolóüzeműben gondolkodni. Ez utóbbiak között lehet találni >95% hatásfokúakat is...
De az még jobb, ha a harmadik elemről külön járatod a PIC-et, egy kisfogyasztású stabbal...

Az elektronikai alapjaimat ne kritizalgasd légy szíves ha nem is ismersz! A nagyképűsködést igazán hanyagolhatnád! Köszi a semmit!

Az XL4005 még inkább a 78xx felejtős.

Mit szeretnél pontosan ez egy sok irányból megközelíthető dolog?

Gondolom neked nem kell 3A-t szabályozni, ha kapcs üzemet akarsz MCP16311-et használj ha az áramkör sleep-ben van ennek a szabályzónak elég alacsony a nyugalmi árama.

Lehet azt is hogy van egy LDO-d és egy kapcs üzem és felváltva használod sleep-ben LDO végrehajtáskor kapcs üzem LDO-nak mondjuk használj MIC5233-t.

De ha elemről sokáig akarsz működni akkor az áramkörödön minden alkatrésznek olyannak kell lennie ami kis fogyasztásra lett tervezve. (ez minden esetben igaz)

Más megközelítés felejts el mindet dob ki a 3 db 9V-os elemet az 5V-os PIC-et és CR2032 és használj egy 3.3V-os PIC-et persze az újabbakat mert azok többnyire kisebb energia fogyasztással bírnak mint a régiek.

És ezt persze megfelelően kell menedzselni kód szinten is.

Köszönöm mindenkinek a hasznos tanacsokat, igy mar boldogulni fogok, eddig még csak adapterrol taplaltam meg az aramkoreimet, most ez lesz az első ami elemes ezert gondoltam, hogy időt sporoljak elso korben itt kérek pár tanacsot... Nem kell hogy tul takarekos legyen a rendszerem az elemeket illetően, lesz rajta egy főkapcsolo, amellyel kikaocsolható. Ez egy olyan eszkoz lesz amit ritkan es rovid idore kaocsolnak be.. Koszi még egyszer!

Az előtt fejezzétek be a kakaskodást, mielőtt még belekezdenétek! (Szakmai fórum, nívó, segítőkészség a kulcsszavak...)

Sziasztok!

Görgettem a XC32 manualt és észrevettem, hogy interruptot lehet csinálni prioritás megkötése nélkül is (én eddig azt hittem mindig meg kell adni az IPL-t).
ARM-nál az interruptok-nak kötött neve van és ha nem írja meg az ember van egy default handler.
Ez ha másnak is tetszik, PIC32-n is meg lehet csinálni. Csak ugye meg kell írni az összes interruptot (bár erre érdemes lehet írni egy programot ami ki generálja).

és bárhol ahol meg akarja írni az ember az interruptot

(ez a tx handler-ben direkt nincs semmi csak egy példa)

Az ISR definíciók külön fájlban legyenek mint ahol az Handler meg van írva mert ha ugyanott van implementálva mint ahol definiálva akkor redefinition-ért sír a fordító.

Ha megnézed, mit fordít a fordító, láthatod, hogy akár kialakítasz egy saját megszakítás kezelőt, akár nem, alapban nincs üres megszakítási vektor, a fordító alapértelmezett megszakításkezelőt hív meg egyéb esetekben...

Ezt nem teljesen értem nekem ha be rakom a vektort akkor befordul a kódba az adott megszakításkezelő, de ha nem akkor sima kódot fordít oda. És ha vektoros módban van akkor a vektorra ugrik autómatikusan nem?
És onnan a current priority-t frissíti meg menti a regisztereket.
Valamint ha a vektoron valami más kód van az már problémát okoz nem?

Kicsit sületlenségről beszéltem az előbb mert nem a hívás helyét kerestem meg a dissassyban hanem a függvény definíciót.

Aztán eszembe jutott hogy ebase + offset alapján megy az interrupt.
Bővebben: Link itt minden le van írva szépen és hogy az OFFxxx a startup-ban inicializálódik így amelyik int nincs használva az a _DefaultInterrupt-ra mutat.

Így van! ) Ebből az következik, hogy nem kell ezzel külön foglalkozni kódban már...

Küzdök itt egy SPI kommunikáció megvalósításával.
Adott egy PIC(dsPIC33EP32GS504), melyet slave üzemmódban van.
A jelenség a következő: ha masternak konfigurálom, működik jól, a kiküldött adatok szépen ki is mennek. Ám nekem slave kell. Ekkor viszont az van, hogy befelé fogadja jól az adatokat, viszont kifelé nem tudok semmi értelmeset sem küldeni. Mintha csak valamiféle szemét menne ki a vonalra.

Sőt, már abban sem vagyok biztos, hogyan kellene működnie az SPI perifériának?! Tehát, azt gondolnám, hogy a shift regiszterbe kerülő bitek, az órajel hatására 8 órajel múlva meg kellene jelennie a kimeneten is, mintegy visszakapva a küldött adatot késleltetve. Ekkor ugye minden 8. órajelre a shift regiszter tartalma beíródik az SPIREG vételi pufferébe(vagy jelen esetben a 8 szintű FIFO-ba). Ez elvileg tiszta sor. De mi történik a másik iránnyal? Ekkor szerintem, ha írás történt az SPIREG-be, akkor gondolom az megy tovább a shift regiszterbe, felülírva a korábban beérkezett adatot. Ami nem világos, ez mindig meg történik, vagy csak akkor, ha volt előtte beleírva valami adat, ha viszont nem, akkor ilyenkor nem íródik felül a shift regiszter tartalma?

Próbáltam az inicializálás után azonnal feltölteni az adási FIFO-t ismert adatokkal, amit elvileg vissza kellene kapjak a SDO-n, amikor adatokat fogadok a PIC-el(amit jó vesz is), de csak valami szemét szerűséget kapok...

Van valakinek ötlete, mi lehet az oka?

Idézet a dsPIC család SPI manualjából:

Tehát folyamatosan tudja egyszerre működtetni a vételt és a küldést is.

A master oldalon jó a vétel? Vagy logikai analizátorral nézted a kimenő dolgokat?

Igen, az világos, hogy egyszerre tud adni és venni is, csak számomra az nem világos, amikor nem küldenék vissza semmit sem direkt, akkor az eredeti vett adatok shiftelődnek ki vissza, vagy mindig, mindenkor az SPIBUF adási puffere megy ki vissza?! Bár ez utóbbinak nem sok értelmét látnám...

Nem, nem jó az adat a master oldalon, hiszen ha jó lenne a vétel, akkor nem tudnék a problémáról sem Egyébként logikai analizátoron is látom, mi kerül ki a vonalra. Tehát pontosan tudom, mi zajlik éppen a fizikai vonalakon, csak épp az okát nem értem...

Szerintem meg annak nincs értelme ha az eredeti adatok shiftelődnek vissza. Külön tárolóba kerül a bejött adat, mint a kimenő. Nem lenne neki szabad kishiftelődni.
Errata nem ír semmit erről?

Viszont, ha mindig az adási puffer kerül a shift regiszterbe, és mondjuk nem írtam bele semmit se, akkor mi megy ki? 0?
Az errata-ban csak annyit említenek az SPI kapcsán, hogy van egy parazita órajel, a modul engedélyezésekor, master módban. Más semmi...

Közben kipróbáltam átkonfigurálva SPI2-re. Ugyanez a jelenség...

Nos igazad van.
Ha megnézed a 13. oldalt a 2. és 3. pont tisztázza a kérdést azt hiszem.

Megtaláltam a probléma forrását! Az SSEN bitben rejlik a történet. Valami rejtélyes okból kifolyólag, ha ez nincs engedélyezve, az SDO vonal nagyimpedanciába állítódik, holott ezt csak akkor kellene megtennie, ha be van állítva ez a bit, és log 1-ben van az SS1 vonal.
Mivel én alapban nem akartam használni ezt a vonalat a kommunikációhoz, így értelemszerűen nem állítottam ezt be, felszabadítva ezzel +1 portlábat. Az adatlap elég hanyagul írja le ezt az üzemmódot sajnos
Most engedélyeztem ezt a vonalat is, így működik jól...

Köszi az agyalást!!

Találtam némi doksit PIC32CZ-ről kínaiul, google egész jól beszéli (legalábbis angolra)

Meg lehet azt csinálni valahogy MpLabX-en belül, hogy amikor a Debug gombra nyomok, a forráskódban feltételes fordítás jöjjön létre?!

Ezt meg lehet nézni, hogy az __MPLAB_DEBUGGER_ICD3 direktíva bekapcsolódik-e automatikusan, pl. ha ICD3-at használsz.
Bővebben: Link

ps.: mit szeretnél kihozni? Nem egyszerűbb kívülről, pl. egy IO láb segítségével átbillenteni egy flaget, amit szoftverből kezelsz utána?

Igazából az nem világos, van pl egy release fordításom. Majd szeretném debug-olni a kódot, és a debug gombon keresztül indítom el..., lehet e ezt detektálni, és rábírni az MpLabX-et, hogy fordítsa újra, feltételesen a kódot?

Ez azért kellene nekem, mert a kód a RAM memória nagy részét elhasználja, és valamiért ekkor nem működik jól a debug funkció. Észrevettem, ha kicsit visszaveszek a RAM felhasználtságából, akkor viszont jól működik. Tehát azt szeretném, hogy ez automatikussá váljon, egy feltételes fordítás keretein belül(vagy valami más ekvivalens módon), mivel nem tehetem meg, hogy alapban a kisebb memória foglaltságon hagyjam a végleges kódot.

A kivetkezo tag koze irod, amit csak release-be szeretnel leforditani:
illetve
tag koze, amit csak debug-ban szeretnel forditani.

Igen, letesztelve úgy tűnik ez a makró alkalmas arra, amit szeretnék!

Nekem úgy tűnik, ilyenkor sem fordít igazából új kódot, csak a meglévőt módosítja, dinamikusan feltöltéskor, hogy a kívánalmak szerint fusson.
Ha konkrétan más fordítást szeretnénk, akkor azt nem ezen keresztül lehet megtenni, hanem külön konfigurációk létrehozásával. A konfiguráció kiválasztásával már valóban más kód fog lefordulni is, az ott beállítottaknak megfelelően(és az #ifxxx - eknek megfelelően)

superuser, Zsolt2 - köszönöm a segítséget!

MPLAB-X, CCS-C pároasításnál futottam bele egy olyan problémába hogy nem ment rendesen a Debug ... a töréspontoknál nem állt meg a program, ha én megállítottam nem mutatta hol áll meg, és nem látszottak a változók sem. Nagy nehezen eljutottam ahhoz a sorhoz ami a problémát okozza. ( egy UART vonalra adatküldés) Ilyen sorból több tucat is akad a programban, sőt pontosan ugyan ez a sor máshol is szerepel. Fordításkor hibát, warningot nem jelez, a program hiba nélkül fut. Ha az ominózus sort törlöm, vagy duplán beírom akkor a debug is működik rendesen.
Na ez mitől lehet, és mit lehetne tenni ellene???

Szerintem bug. MC szerint biztos feature.
a) elkezded elemezni az okot, szétboncolod a hívásodat, hogy melyik része okozza a problémát
b) felrakod minden eszközből a legújabb verziót
c) kérsz egy support ticketet a MC-től
d) törölsz minden temp fájlt és létrehozol egy új projektet, hátha...