Fórum témák
» Több friss téma |
Idézet: Jogos észrevétel. Részben igen, részben nem. Az elő- és utóosztó számlálót törli.„a T2CONbits.TMR2ON=1; nem vonja maga után a timer resetet is?” Idézet: A nyolc bites kategóriában ez viszonylag új dolog, régebbi kontrollerekben fixen Fosc/4 adja az órajelet. „sokszor a Timer2 külső oszcillátorról is mehet”
Tulajdonképpen ezt a rögtönzött programot azért írtam, hogy kiderítsem, hogy működik-e a kontroller és a kvarc. A gomb megnyomásakor a LED-nek világítania kellene azonnal és egy idő múlva kialudnia. De ha ez nem is történik meg, csak világít a LED, akkor a kvarc és a kontroller jó. De ez sem működik. (Gondoltam később kijátszom az időzítést, azért volt benne időzítő is, de már az elején ez megfeneklett...)
Igen, de a kódod sem feltétlen jó, amivel tesztelni szeretnéd. Volatile a flag, no meg lehet reseteli a timert a folytonos bekapcsolása. Ha nem tudjuk pontosan mik okozhatják a programban a hibát, akkor törekedni kell a lehető legegyszerűbb, tutira működő programmal tesztelni. Utána hardver birizgálás, ha az a baja, mert akkor a legprimitívebb LED villogásnak is el kell indulnia. De a te kódodban lehet vannak hibaforrások, ezeket mindenképpen ki kell zárni.
Én így szoktam. A hozzászólás módosítva: Jan 9, 2024
Én rögtön dsPIC33FJ128-al kezdtem kényszerből, annak a lelki világát kezdem kiismerni, ezeket a PIC-eket nem vágom, de szerintem hasonlóképp kell nekifogni. 100x programhiba, 1x hardver. Ezt a saját brőmön kellett megtapasztalnom. Mennyi de mennyiszer fordult ez elő velem
KoblogPerGyok által felvetett, esetleges probléma kikerülésére csupaszítsd le a programot az abszolút minimumra:
Illetve nekem így volt:
Az UL kell a_XTAL_FREQ -nél, hogy a fordító/IDE tudja mekkora a szám valójában, ami bőven nagyobb mint a 16 bit. A másik, hogy a delay-eket tartalmazó libpic include-ja mindenképpen a #define _XTAL_FREQ 79872000UL után kell, mert addig a fordító nem tudja, hogy a lib-ben mennyi is ez az érték. Nekem ilyenek kellettek, de a dspic 16 bites, de szerintem a logikája azonos. Persze, nekem az UL azért volt fontos, mert mint látod azzal számolok is. Szóval lehet nem segít, de nem is árt, meg persze simán tudhatod is, csak gondoltam ide írom, hátha másnak is kell.
Itt egy kis összefoglaló táblázat arról, hogy milyen típuskényszerítési lehetőségek vannak konstans megadásakor. Lehetőség van típus nélkül definiált konstans típuskényszerítésére, ha megszorozzuk egy típusos konstanssal, pl:
A 3. sorban típuskényszerítés nélkül hibás eredmény keletkezne a szorzás túlcsordulása miatt.
Tehát az én esetemben ezeket kellene írni?
#define _XTAL_FREQ 20000000UL #include <libpic30.h> Ezt pedig nem: #define FCY (_XTAL_FREQ/2) void Ora_init(); És a flag volatile legyen. Jól értem? Ha igen, akkor ezeket a módosításokat megcsinálom a tényleges programban (nem a próba, lebutított programban) és tesztelem. Köszönöm!
Nem, a te esetedben nem. A
Sziasztok,
Egy PIC16F18446-os mikrokontrollerből szeretném kiolvasni a belső sorozatszámot (pontosabban a Device Information Area-t). Számomra a legegyszerűbb megoldásnak a
Hogyan lehetne minél egyszerűbben kiolvasni ezt az értéket ami a 0x8100-as címen van? Előre is köszönöm.
A hibaüzenet azt írja, hiányzik a pontosvessző, valószínűleg a mutatott utasítást megelőző sorban.
Adatlap: 13.4 fejezet:
NVMCON1bits.NMVREGS =1 ; NVMADR = 0x0100; NVMCON1bits.RD=1; A kiolvasott érték a NVMDAT regiszterben lesz.
Köszönöm a válaszokat, a Hp41C kódjával működik a regiszterek olvasása.
Bakman: előre én is erre gondoltam, de nekem jónak tűnik ahogyan írtam. Csatoltam egy fényképet a kódról és a hibaüzenetről. Mintha valamilyen szintaktikai hiba lenne a C/C++ nyelv között.
Megcsináltam ezt az egyszerűsítést. Mértem a lábon a feszültségváltozást. DE sajnos folyamatosan 0 V-t mérek ezen az RD4-es lábon. Ez azt jelenti, hogy a kvarcot, vagy a kis kondikat túlmelegítettem és tönkrementek?
Veszek újat és újragyártom.
Erre nem lehet egyértelmű választ adni. Egyrészt maga a PIC kellően bonyolult ahhoz, hogy csak cserével lehessen kizárni a kontroller hibát, másrészt kezdődthet ott is, hogy nem jó a programozód. Sok ismeretlennel rendelkező egyenlet.
Fel tudnál tenni egy közeli fotót, fotókat róla?
Meg kellene vizsgálni, hogy minden kondi, ellenállás a helyén van-e. Minden tápfeszt, vagy egyéb feszt igénylő láb be van-e kötve. Ha minden ok-nak néz ki, akkor még a teljes kódot is feltehetnéd, a sima while-ban lévő LED villogtatással együtt, különös figyelemmel a pragma config-okra. Mekkora LED előtét ellenállás van, milyen a LED stb. No meg a kvarc is. A helyzet az, hogy nálam a dsPIC heyes felprogramozása, valamint a megfelelő tápok, kondik kibogarászása minimim 3 nap volt. Igaz totál az elejétől kezdtem, no meg a belső PLL-je lett felprogramozva 80MHz-re, ami kicsit más. De ettől függetlenül már lehet sanszos a hardver hiba is. Nekem elsőre ment minden, de előtte sokat lapoztam az adatlapot arra emlékszem! A hardver hiba nálam a legkevesebbszer fordult elő, még akkor is amikor olyan láb kapott tápot, ami elvileg ki is nyírta volna az egészet, de nem, kibírta. A másik, hogy a multiméteres mérésekkel nem foglalkoztam miután az IC a helyén (DIP tokban) volt, mert igen könnyen rövidre zárható két láb. Én a DIP tokban a megfelelő helyeken mértem a feszt a GND-khez képest, valamint a többi lábon is, hogy semmiképpen le legyen gond. MINDEN lábon szakadás mérés előtte, csak utána a tápfesz a DIP tokon mérve, ha jó, akkor utána az IC. Utána már semmit sem, vagy a kábel kivezetéseken mértem maximum. De tegyél lécci fel fotókat és a teljes kódot hátha.... De tényleg elfüstölhettek sajnos. A hozzászólás módosítva: Jan 13, 2024
Találtam egy 32 kHz-es kvarcot és két 22 pF-os kondit és kicseréltem. És jó. Az eredeti program is fut, nemcsak a próbaprogram. Mondjuk még nem tökéletes a hőmérő, mert falsot mér, de majd módosítgatom.
Tehát kinyírtam a kvarcot a sok hővel forrasztásnál. Köszönöm a segítségeket!!
Ok, akkor a nehezebb út volt, de a lényeg, hogy megy. Ezek szerint nem voltál szerencsés, tényleg hardver hiba lett a vége. Van itthon egy marék kvarcom...
Győr környéke, ha érdekel.
De rendes vagy! De Fótról talán nem éri meg.
Segítséget kérnék az alábbiakhoz:
PIC18F16Q40-nél nem sikerül a megszakítást megírni Asseblyben. Ez egy új generációs PIC és nem találok rá még hasonló minta progit sem MPLAB X IDE V6.15-öt használok. Feladat: Alaphelyzetben 13. láb, LATB,4 kimeneten LED1 villog. (EZ MŰKÖDIK) Ha a 17. láb INT2-re impulzus jön, akkor a 16. láb LATC,0 kimeneten LED2-nek világítania kell (megszakításba ugrás) majd villog tovább LED1. A megszakításba ugrás nem működik.
A hozzászólás módosítva: Jan 23, 2024
Moderátor által szerkesztve
Szia!
Rég volt, hogy ilyet írtam, megkérdeztem az agyat, hátha:
A megszakításaid címe jó? Nem kell a bank select? Hátha nem törli a flag-et. Datasheet A datasheet 116. oldalán az int0 0x08-on van, a tiéd, ami a programodban van ORG 0X0018 goto ISR_L az nem a SPI1RX (Serial Peripheral Interface) -nek van? De álmos is vagyok, meg nem is tudtam nagyon átnézni, de hátha. A hozzászólás módosítva: Jan 22, 2024
"Az INT2 megszakítási vektor címe: 0x000C"
Nem 0x50? 116. oldal
Szia!
A konfigurációban az MVECEN bittel kikapcsolod a vektoros megszakítási módot. Az adatlap szerint ekkor a megszakítás az alábbi módon működik: Idézet: „11.3.3 Interrupt Vector Table Address Calculation MVECEN = 0 When the MVECEN Configuration bit is cleared, the address pointed to by IVTBASE is used as the high-priority interrupt vector address. The low-priority interrupt vector address is offset eight instruction words from the address in IVTBASE.” A programod nem állítja be az IVTBASE regisztereket. Azok indulási értéke valószínűleg 0, így a megszakítás helyett újraindulás történik.
Ha jól értem, MVECEN = OFF akkor a megszakítás nem vektoros, hanem úgy működik, mint a PIC18F14K22-nél, hogy van egy alacsony és egy magas szintű megszakítás? Nekem ez kellene.
"For PIC18 devices, IVTBASE defaults to 000008h, hence the high-priority interrupt vector address will
be 000008h and the low-priority interrupt vector address will be 000018h." Illetve a két címet kell használnom? A hozzászólás módosítva: Feb 9, 2024
Idézet: „For PIC18 devices, IVTBASE defaults to 000008h, hence the high-priority interrupt vector address will be 000008h and the low-priority interrupt vector address will be 000018h."” elkerülte a figyelmemet. Bocsánat. A következőt ajánlom figyelmedbe: TB3162 "Backward Compatibility" Érdekes dolgokat ír az adatlap 11. fejezete a regiszter mentésekről.
INT2 flag-et a programba beállítva sikerült megszakításba ugrasztani. LED2 (LATC,0) világított.
Debug simualtoron is rendesen fut. Közben kiderült, hogy míg a PIC18F14K22 INT2 a 17-es, adíg a PIC18F16Q40-é a 14. lábon van. Viszont ahogy nézem IOC - Interrupt-on-Change segítségével a 17-es lábra tudom vinni a megszakítást (PCB adott és fontos, hogy ne kelljen módosítani), csak akkor már nem INT2 lesz a leánykori neve ? A hozzászólás módosítva: Feb 11, 2024
PIC18F16Q40 esetén a PPS segítségével arra a lábra állítod, amelyikre akarod.
Interrupt-on-change bármelyik lábra beállítható, ahhoz nem tartozik PPS regiszter, csak a megfelelő bitet kell 1-re állítani az IOCxN (lefutó) és/vagy IOCxP (felfutó) regiszterben. Ha csak az egyik változás kell, akkor érdemesebb ezt használni, mert az Interrupt 0, 1 vagy 2 mindkét élre reagál.
Sziasztok!
Mindig gondot okoz, hogy hogyan tudok egy PIC vezérelte kis villánymotorral meghajtani/megmozgatni valamit. Egy játékautót, porszívó kereket, ablaknyitót, redőny felhúzót, függöny-húzót, szellőző nyílást stb. Ezt hogyan szoktátok megoldani, lehetőleg költséghatékonyan? Fogaskerék, ékszíj, fogasszíj? És honnan lehet beszerezni ilyen kis méretű fogaskereket, egyebeket? Kerékpár láncra gondoltam, de az nagyon nagy ilyesmire. Van erre valami bevált megoldás? Vagy mindenki maga "gányol" össze valamit?
Itt nézz körül
A hozzászólás módosítva: Feb 23, 2024
|
Bejelentkezés
Hirdetés |
