Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
bit 31-0 BMXDRMSZ<31:0>: Data RAM Memory (DRM) Size bits
Static value that indicates the size of the Data RAM in bytes: 0x00002000 = device has 8 KB RAM 0x00004000 = device has 16 KB RAM 0x00008000 = device has 32 KB RAM 0x00010000 = device has 64 KB RAM 0x00020000 = device has 128 KB RAM "device has" ami azt jelenti, az eszköz rendelkezik. Akkor ez most mit jelent? 
Közben kitisztult, találtam adatlap szerint is 128k-s típust, gondolom ott lehet 0x00020000 a regiszter értéke.
Köszönöm a tanácsokat 
Képtelen vagyok a PIC-em (PIC16F1788) C portját digital IN/OUT-ra állítani.
Van ez az "Alternate Pin Function", ill. "OUTPUT PRIORITY" lista, ahol a legkisebb prioritású az RCx pin. Már próbáltam az összes perifériát kikapcsolni, de ez sem segít. Tud valaki segíteni?
Hali!
amit használtam 1789-es initjét el tudom küldeni ha kell
Igen, légyszíves küld el, nagy segítség lenne. Előre is köszönöm!
Sziasztok !
16F628-ra írtam egy progit Proton basic progiban. Minden remekül működik kis szépséghibával. Két gombbal egy változó értékét állítom lefelé-felfelé. Az egyik az RA4 lábon (lefelé) Na ez szépen működik. A másik gomb RA5-ön ( MCLR láb amit a config wordbben I/O-nak állítottam ). Itt már van baj. Ha folyamatosan nyomom rendben növel, ha nyomkodom akkor leginkább csökkent, de néha növel. !!??. Ha egyszerre megnyomom a kettőt, akkor kiugrik a goto ciklusból a megfelelő helyre, ez is rendben. Az a baj, hogy a kijelző miatt elfogytak a lábak. Próbáltam az RB0 ( Int ) lábon azzal sem jó. Maradt még 4 db AN RA bemenet ezeken kívül. -------------------------- GOMB: Print At 1, 6, Dec2 flt Print At 1, 11, "gr" DelayMS 20 GOMBA: If PORTA.4 = 0 And PORTA.5 = 1 Then GoTo csokk DelayMS 10 If PORTA.5 = 0 And PORTA.4 = 1 Then GoTo NOV DelayMS 10 If PORTA.4 = 0 And PORTA.5 = 0 Then GoTo LOJJ DelayMS 10 If PORTA.4 = 1 And PORTA.5 = 1 Then GoTo GOMBA DelayMS 10 csokk: flt = flt - 0.01 DelayMS 250 GoTo GOMB NOV: flt = flt + 0.01 DelayMS 250 GoTo GOMB LOJJ: Cls Print " GOOOOOOOOOOOO ! "
Szerintem a
Nincs kizárva, hogy HW probléma van. Milyen felhúzó ellenállásokat használsz?
Biztosabb megoldás, ha egy segéd változóba egyszer kiolvasod a megfelelő port állapotát, majd azon a változón végzed el az elemzést!
A te verziódban minden egyes vizsgálat(IF ág) során újból olvassa a port értékét...feleslegesen, és hibalehetőséget adva arra, hogy bármilyen impulzus megváltoztassa azt...
Megcsináltam a kettőtök által javasolt változtatásokat. Szuper. Köszönöm szépen a segítségeteket !
Pásztázni szeretnék egy dsPIC-el, összesen 8db analóg bemenetet. Beállítottam az ADC-t a következőek szerint:
Van egy 1ms-onkénti megszakításom amelyben az AD1CON1bits.SAMP bit bebillentésével manuálisan indítom a mintavételezést, és ha a nyolc mintavétel megtörtént akkor az ADC megszakítást generál amelynek kiszolgálásában kimásolom az eredményeket az ADC1BUF0-ADC1BUF7 regiszterekből. A dolog működik, van nyolc mérési eredményem amelyek ha hozzáérek a nyákhoz a kezemmel akkor változnak. Viszont szpóppal megnéztem hogy egy darab ilyen pásztázós mintavétel mennyi idő alatt megy végbe és ez néhány ms-ben mérhető ami rengeteg! Kipróbáltam hogy csak szimplán egyetlen mintát veszek, annak a mintavételnek az ideje csupán 1500ns. Hogyan lehet ilyen sok a 8db minta pásztázós vételének ideje? 
Ránézésre amit elsőre feljövő ref man-ból ki szedtem szerintem nem a mintavételi időd a hosszú hanem a konverziós időd, mert ha az egy csatornás időeredményt nézzük a TAD=~142ns-mal elvileg 10 bit-re 12 TAD a konverziós idő (~1700ns) ami kb ott van amit írtál.
Gondolom szekvenciális mintavételed van Idézet: „If SSRC<2:0> = 111 and SSRCG = 0, the SAMC<4:0> bits should be set to at least ‘11111’ when using one S&H channel or using simultaneous sampling. When using multiple S&H channels with sequential sampling, the SAMCx bits should be set to ‘00000’ for the fastest possible conversion rate.” Az általad írt kódrészletben a SAMC = 0-val és a leggyorsabb mintavételnek 1.5ms "kicsit" sok. (visszacsatolásként az első gondolatra, mert én se vagyok benne biztos hogy jó amit mondok csak sejtés) De a CHPS-ből ítélve több SH-d van nem vagy gyorsabb ha szimultán veszel mintát (bár gondolom a konverziós idő nagyobb mint a mintavétel)?
Nos kínlódtam vele pár napot mire rájöttem hogy az AD1CON1bits.ASAM bitet 1-be kell állítani és rögtön jó lett.
Kíváncsi voltam hogy mennyi időbe telik a nyolc bemenet mintavételezése ezért egy 100us-os timer megszakításból elindítottam a mintavételezést és ezzel egyidőben bebillentettem a PIC egyik lábát. Az ADC megszakításában pedig nulláztam a lábat. A szkópon azonban meglepő módon nem egy konstans idejű impulzus látható hanem az impulzus ideje 500ns és 8000ns közt 16 lépésben változik, az alábbi szkópábrákon ez szépen látható. Van valakinek ötlete hogy ez miért van?
Csak tipp, az AD1CSSH-ban az összes bit létezik? Pl. amivel most ismerkedek (dsPIC33EP32MC204) abban a 27-28-29 nem használt bit. És ez talán magyarázná miért csúszik el a minden nyolcadik megszakítás.
Hülyeséget írtam, nyilván szólt volna a fordító ha nincs olyan bit.
Kérdés, hogy indítod és állítod le a mintavételezést, és ilyenkor mi történik a mintavétel/megszakítás osztóval (újraindul vagy onnan folytatja ahol megállítottad?). Ha hagyod futni az A/D-t, és a megszakításban negálnál egy portlábat akkor lemérheted mennyi a 8 konverzió idő.
Másnak is vannak gondjai a debuggolással? Elindul a debugger, de a töréspontokon nem áll meg, ha pedig manuálisan a Pause gombbal megállítom akkor a debugger összeomlik és az alábbi piros hibaüzenetet dobja ki:
Idézet: „Unable to run the target device. Script GetPC failed with status Type = runScript, Script name = GetPC, Status = 0xc06 . A communication error with the debug tool has occurred. The tool will attempt to recover momentarily.” Próbáltam PICkit4-el, ICD4-el, USB kihúz-bedug, MPLABX újraindít, számítógép újraindít, legújabb MPLABX (5.25) feltelepít, stb nem segítenek. Még egy régi 4.20-as verziót is kipróbáltam de ugyan ezt csinálja. Egy barátomat is megkértem hogy ő a saját számítógépével, a saját PICkit4-ével és a saját áramkörével próbálja meg de ugyan ezt tapasztalta. Gyakorlatilag semmilyen módon nem lehet a debuggert használni, pedig égetően nagy szükség lenne rá... Eddig is voltak gondok a debuggerrel amikkel azért nagyjából együtt lehetett élni de most konkrétan lehetetlen használni.  Idézet: „Kérdés, hogy indítod és állítod le a mintavételezést” Vagy egy timer amely fixen 100us-onként okoz egy megszakítást. Itt bebillentem a SAMP bitet, azaz elindítom a mintavételezést. Ezzel egyidőben H szintbe állítom a lábat amelyet a szkóppal figyelek. Az ADC úgy van beállítva hogy ha végzett a mintavételezéssel akkor megszakítást generáljon. Ez meg is történik, a PIC belép az ADC megszakításába ahol már készen vár a friss ropogós 8db minta. Itt az ADC megszakításában nullázom a PIC lábát (melyet a szkóp figyel).
Ékezet vagy space van a könyvtárban amiben a projekt van?
A debughoz ki van valásztva a használt ICSP láb (configba)?
Az ICSP ki van választva. A projekt elérési útjában ékezet nincs, csak egy darab szóköz. De szóköz számos korábbi projektem elérési útjában volt és azokkal nem volt probléma soha.
Egy korábbi frissítésnél én is futottam bele debugger problémába ...
Bővebben: Link Azt hogy mitől volt, nem sikerült megtudni, de a hibát sikerült "megkerülni" ... Egy program sor okozta a gondot, azt kellett megkeresni, és ha töröltem, vagy dupláztam, a hiba megszűnt!
Az ICSP-n van valami más?
A config-ot copy-zd be hátha ott van a "bogár" elásva. Valamint zöld a bogyó az MPLAB-ban a ICD4/PK4 alatt vagy csak sárga? Ez a szóköz dolog olyan valami megeszi valami nem valami sír érte valami nem és a végén már mindenkit küldesz mindenhova aztán eszedbe jut és jé minden megy. Ez épp Visual Studio ARM-el volt, de az ékezettel már szívtam MPLAB alatt is én mindig azt követem se ékezet se space legalább 1 dolgot így ki tudsz pipálni.
Kb másfél éve nem programoztam mert mással (3D nyomtatókkal) voltam elfoglalva. Azelőtt ezzel a debugger hibával nem találkoztam. Most ismét elkezdtem programozni és az első projektnél belefutottam ebbe.
Most próbaképp előbányáztam egy régebbi projektet amihez egy másik áramkör (a fejlesztőpanelem) tartozik és azt a PICkit4-el tudom debuggolni. Nem értem... Az ICD4 és a PICkit4 is sárga nem zöld, de ez mindig is így volt. A konfig pedig ez:
Az ICSP-n pedig nincs semmi:
Próbáld ki,hogy leszeded az MCLR-ről a kondit,csak a felhúzást hagyd rajta,hátha az kavar be.
Dehogynincs. MCLR 100R-100n hazavágja, szerintem
Az ICSP menjen direktben az MCLR-re(na jó esetleg lehet kis ellenállás), a reset RC tag közepe meg kb 1k-4k7-en keresztül az MCLR-re
Kiforrasztottam a kondit, ugyan az. Minden eddigi PIC-es áramkörömben egyébként így néz ki az ICSP.
A 10k/100n-t
Nekem okozott gondot az a 100n direktben a lábon, azóta mindig soros ellenálláson keresztül vannak, a programozó meg direktben megy a lábakra, így a programozó reset/vpp jelét nem nyalja el a kondi. A hozzászólás módosítva: Aug 26, 2019
Na erre varrjon gombbot valaki!
Próbaképp létrehoztam egy teljesen új projektet és csak a nagyon minimális dolgokat írtam bele (konfigbitek és egy végtelen ciklus a main-be) és megnéztem hogy megy-e vele a debugger. Ment! Ezután szépen lassan elkezdtem bemásolgatni a régi projektből a dolgokat, kezdve a PIC_inic.c fájllal amelyben a PIC lábai és perifériái vannak beállítgatva. A debugger ez után ugyan azt a hibát produkálta. Kikommenteztem a PIC_inic.c bő felét és a debugger ismét működött! Ekkor gondolhatjátok mi következett... Szépen behatároltam hogy mely sort kell kikommenteznem ahhoz hogy a debugger működjön. Ez pedig az alábbi két sor:
Újra megnyitottam a régi (azaz nem debuggolható) projektemet amelyben benne van minden függvényem és minden amit eddig a projekbe programoztam. Kikommenteztem benne ugyan ezt a két sort és láss csodát, a debugger gyönyörűen működik! Na de mi a bánat baja van ennek a két sornak és főleg: ezeknek mi köze van a debugger működéséhez? Van egyébként összefüggés a két sor közt, ugyanis a PORD0 láb azért kimenet mert az SPI1 periféria SDO-ja erre a lábra (RP64) van PPS-elve (RPOR0bits.RP64R=0b000101). Valami fizikai baja lenne ennek a lábnak vagy ennek az SPI perifériának amitől a PIC debuggereléséért felelős része megbolondul vagy mi? Igen... cseréljem ki a PIC-et. Ki fogom. OFF: A szűz projekt létrehozásakor sikerült véletlen letöröltetnem az MPLABX-el a projekt teljes könyvtárát, azaz az összes korábbi projektverziót is, benne az összes eddigi (nem kevés) munkámmal. Ha nincs a NAS-om ami azonnal magába szippantja az elektronika mappám tartalmát amint változik egy fájl, akkor most... nos a debugger lenne a legkisebb problémám...
Erről beszéltem....
Akkor lehet, hogy érdemes lenne neki is először kipróbálni, hogy megduplázza az ominózus sorokat, ahogy te is tetted, még mielőtt leforrasztaná a PIC-et.
|
Bejelentkezés
Hirdetés |
