Fórum témák

» Több friss téma
Fórum » PIC - Miértek, hogyanok haladóknak
 
Témaindító: G-Lex, idő: Jan 9, 2006
Lapozás: OK   1302 / 1305
(#) cs_gabor hozzászólása Júl 12, 2019 /
 
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?
(#) cs_gabor hozzászólása Júl 12, 2019 /
 
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
(#) haffre hozzászólása Aug 12, 2019 /
 
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?
(#) pipi válasza haffre hozzászólására (») Aug 12, 2019 /
 
Hali!
amit használtam 1789-es initjét el tudom küldeni ha kell
(#) haffre hozzászólása Aug 13, 2019 /
 
Igen, légyszíves küld el, nagy segítség lenne. Előre is köszönöm!
(#) vandorbot hozzászólása Aug 16, 2019 /
 
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 ! "
(#) Bakman válasza vandorbot hozzászólására (») Aug 16, 2019 / 1
 
Szerintem a
  1. GOMBA:
  2. If PORTA.4 = 0 And PORTA.5 = 1 Then GoTo csokk
  3. DelayMS 10
  4. If PORTA.5 = 0 And PORTA.4 = 1 Then GoTo NOV
  5. DelayMS 10
  6. If PORTA.4 = 0 And PORTA.5 = 0 Then GoTo LOJJ
  7. DelayMS 10
  8. If PORTA.4 = 1 And PORTA.5 = 1 Then GoTo GOMBA
  9. DelayMS 10
Cseréld ki erre:
  1. GOMBA:
  2. If PORTA.4 = 0 And PORTA.5 = 1 Then GoTo csokk
  3. If PORTA.4 = 1 And PORTA.5 = 0 Then GoTo NOV
  4. If PORTA.4 = 0 And PORTA.5 = 0 Then GoTo LOJJ
  5. GoTo GOMBA
Ha nincs lenyomva gomb, az előző három feltételes elágazás nem fog az igaz ágra ugrani, felesleges a negyedik opciót vizsgálni mert az az előző három sikertelensége okán igaz lesz. A gombok közötti késleltetés is felesleges.

Nincs kizárva, hogy HW probléma van. Milyen felhúzó ellenállásokat használsz?
(#) sdrlab válasza vandorbot hozzászólására (») Aug 16, 2019 / 1
 
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...
(#) vandorbot válasza Bakman hozzászólására (») Aug 16, 2019 /
 
10K-s fémrétegeket.
(#) vandorbot válasza sdrlab hozzászólására (») Aug 16, 2019 /
 
Megcsináltam a kettőtök által javasolt változtatásokat. Szuper. Köszönöm szépen a segítségeteket !
(#) Attila86 hozzászólása Aug 18, 2019 /
 
Pásztázni szeretnék egy dsPIC-el, összesen 8db analóg bemenetet. Beállítottam az ADC-t a következőek szerint:
  1. //A/D konverter:
  2.     AD1CON1bits.ADON=0;         //A/D modul kikapcsolva!
  3.     AD1CON1bits.AD12B=1;        //12 bites mód
  4.     AD1CON1bits.FORM=0b00;      //Eredmény jobbra igazítása, előjel nélkül
  5.     AD1CON1bits.SSRCG=0;
  6.     AD1CON1bits.SSRC=0b111;     //Automatikus konverzió
  7.     AD1CON1bits.SIMSAM=0;       //Nincs szimultán mintavételezés
  8.     AD1CON1bits.ASAM=0;         //Automatikus mintavételezés kikapcsolva
  9.     AD1CON2bits.VCFG=0b000;     //AVSS és AVDD használata referenciaforrásnak
  10.     AD1CON2bits.CHPS=0b00;      //Csak a CH0 mintavevő csatornát használjuk
  11.     AD1CON2bits.ALTS=0;         //Nem használjuk az alternáló módot
  12.     AD1CON2bits.SMPI=0b0111;    //Minden 8. konverzió után történhessen megszakítás/DMA címléptetés
  13.     AD1CON3bits.ADRC=0;         //Az ADC konverziós órajelének a forrása a rendszer órajeléből származtatva
  14.     AD1CON3bits.ADCS=0b00000100;//TAD=5*TCY=142,85ns
  15.     AD1CON4bits.ADDMAEN=0;      //DMA nincs használva az A/D-hez, a konverzió eredményei az ADC1BUF0-ADC1BUFF bufferba kerülnek
  16.     AD1CHS0bits.CH0NA=0;        //A CH0 csatorna negatív jelének forrása a VREFL lesz
  17.     AD1CON2bits.CSCNA=1;        //Pásztázás bekapcsolva!
  18.     AD1CSSHbits.CSS24=1;
  19.     AD1CSSHbits.CSS25=1;
  20.     AD1CSSHbits.CSS26=1;
  21.     AD1CSSHbits.CSS27=1;
  22.     AD1CSSHbits.CSS28=1;
  23.     AD1CSSHbits.CSS29=1;
  24.     AD1CSSHbits.CSS30=1;
  25.     AD1CSSHbits.CSS31=1;
  26.     AD1CON1bits.ADON=1;         //A/D modul bekapcsolva!

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?
(#) cross51 válasza Attila86 hozzászólására (») Aug 18, 2019 /
 
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)?
(#) Attila86 válasza Attila86 hozzászólására (») Aug 25, 2019 /
 
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?
(#) dzsolt válasza Attila86 hozzászólására (») Aug 25, 2019 /
 
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.
(#) dzsolt válasza dzsolt hozzászólására (») Aug 25, 2019 /
 
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ő.
(#) Attila86 hozzászólása Aug 25, 2019 /
 
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.
(#) Attila86 válasza dzsolt hozzászólására (») Aug 25, 2019 /
 
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).
(#) cross51 válasza Attila86 hozzászólására (») Aug 26, 2019 /
 
É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)?
(#) Attila86 válasza cross51 hozzászólására (») Aug 26, 2019 /
 
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.
(#) Lamprologus válasza Attila86 hozzászólására (») Aug 26, 2019 /
 
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!
(#) cross51 válasza Attila86 hozzászólására (») Aug 26, 2019 /
 
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.
(#) Attila86 válasza cross51 hozzászólására (») Aug 26, 2019 /
 
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:
  1. // FGS
  2. #pragma config GWRP = OFF               // General Segment Write-Protect bit (General Segment may be written)
  3. #pragma config GSS = OFF                // General Segment Code-Protect bit (General Segment Code protect is disabled)
  4. #pragma config GSSK = OFF               // General Segment Key bits (General Segment Write Protection and Code Protection is Disabled)
  5.  
  6. // FOSCSEL
  7. #pragma config FNOSC = PRIPLL           // Initial Oscillator Source ion bits (Primary Oscillator (XT, HS, EC) with PLL)
  8. #pragma config IESO = ON                // Two-speed Oscillator Start-up Enable bit (Start up device with FRC, then switch to user-ed oscillator source)
  9.  
  10. // FOSC
  11. #pragma config POSCMD = HS              // Primary Oscillator Mode  bits (HS Crystal Oscillator Mode)
  12. #pragma config OSCIOFNC = OFF           // OSC2 Pin Function bit (OSC2 is clock output)
  13. #pragma config IOL1WAY = OFF            // Peripheral pin  configuration (Allow multiple reconfigurations)
  14. #pragma config FCKSM = CSDCMD           // Clock Switching Mode bits (Both Clock switching and Fail-safe Clock Monitor are disabled)
  15.  
  16. // FWDT
  17. #pragma config WDTPOST = PS32768        // Watchdog Timer Postscaler bits (1:32,768)
  18. #pragma config WDTPRE = PR128           // Watchdog Timer Prescaler bit (1:128)
  19. #pragma config PLLKEN = ON              // PLL Lock Wait Enable bit (Clock switch to PLL source will wait until the PLL lock signal is valid.)
  20. #pragma config WINDIS = OFF             // Watchdog Timer Window Enable bit (Watchdog Timer in Non-Window mode)
  21. #pragma config FWDTEN = OFF             // Watchdog Timer Enable bit (Watchdog timer enabled/disabled by user software)
  22.  
  23. // FPOR
  24. #pragma config FPWRT = PWR128           // Power-on Reset Timer Value  bits (128ms)
  25. #pragma config BOREN = ON               // Brown-out Reset (BOR) Detection Enable bit (BOR is enabled)
  26. #pragma config ALTI2C1 = OFF            // Alternate I2C pins for I2C1 (SDA1/SCK1 pins are ed as the I/O pins for I2C1)
  27.  
  28. // FICD
  29. #pragma config ICS = PGD2               // ICD Communication Channel  bits (Communicate on PGEC2 and PGED2)
  30. #pragma config RSTPRI = PF              // Reset Target Vector  bit (Device will obtain reset instruction  Primary flash)
  31. #pragma config JTAGEN = OFF             // JTAG Enable bit (JTAG is disabled)
  32.  
  33. // FAS
  34. #pragma config AWRP = OFF               // Auxiliary Segment Write-protect bit (Aux Flash may be written)
  35. #pragma config APL = OFF                // Auxiliary Segment Code-protect bit (Aux Flash Code protect is disabled)
  36. #pragma config APLK = OFF               // Auxiliary Segment Key bits (Aux Flash Write Protection and Code Protection is Disabled)

Az ICSP-n pedig nincs semmi:

ICSP.png
    
(#) Tasznka válasza Attila86 hozzászólására (») Aug 26, 2019 /
 
Próbáld ki,hogy leszeded az MCLR-ről a kondit,csak a felhúzást hagyd rajta,hátha az kavar be.
(#) pipi válasza Attila86 hozzászólására (») Aug 26, 2019 /
 
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
(#) Attila86 válasza Tasznka hozzászólására (») Aug 26, 2019 /
 
Kiforrasztottam a kondit, ugyan az. Minden eddigi PIC-es áramkörömben egyébként így néz ki az ICSP.
(#) Attila86 válasza pipi hozzászólására (») Aug 26, 2019 /
 
Mit értesz "reset RC tag" alatt?
(#) pipi válasza Attila86 hozzászólására (») Aug 26, 2019 /
 
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
(#) Attila86 hozzászólása Aug 27, 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:
  1. TRISDbits.TRISD0=0;     //SD-kártya MOSI
  2. SPI1STATbits.SPIEN=1;       //SPI1 engedélyezve

Ú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...
(#) Lamprologus válasza Attila86 hozzászólására (») Aug 27, 2019 /
 
Erről beszéltem....
(#) fsub válasza Lamprologus hozzászólására (») Aug 27, 2019 /
 
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.
Következő: »»   1302 / 1305
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu