Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Bepötyögni úgy lehet egyszerűbben, ha makrót írsz hozzá. A fordítás végeredménye nyilvánvalóan nem egy utasítás lesz...
Vagy ha egy subrutinba rakod a felteteleknek megfelelo ertekadasokat es a feltetel vizsgalat utan van a CALL utasitas... Akkor a rutinodban mar nem kell ezernyi BTFSS/BTFSC...
Ötletadónak ajánlom Karl Lunt cikkét: A High Power PIC Macro Library
Ne tegyünk több utasítást tartalmazó makrót BTFSC, BTFSS, INCFSZ, DECFSZ, stb utasítások után, hiszen ezek az utasítások csak 1 utasítást lépnek át, ha a feltétel teljesül...
Lehet, hogy valamit félreértettem, vagy én voltam félreérthető, de én nem a BTFSC után gondoltam makrót tenni, hanem a BTFSC helyett.
Ha nem akarod a BTFSC-t, akkor mivel akarod tesztelni a Z-t?
Az értékadás ASM-ben minimum 1 sor, tehát, ha a,b,c,d,e változók, akkor legalább ennyi sor + az érték W-be töltése. Ha ezek egy bájt bitjei, akkor 2 sor.
Talán azért nem ment el semmit, mert ezzel kezdődik a program:
org 0 goto start Vagy tévednék?
Idézet: Nyilván a makróban elhelyezett BTFSC (vagy egyéb) utasítással. A makró arra jó, hogy ügyesen paraméterezve minél kevesebb begépeléssel és minél áttekinthetőbben megírt programodba automatikusan beszúrja azt az utasítássorozatot, amire szükséged van. „Ha nem akarod a BTFSC-t, akkor mivel akarod tesztelni a Z-t?” ennek a fejezetnek a végén még egymásba ágyazott FOR...NEXT ciklust is láthatsz, makrókkal megvalósítva.
A helyzttol fuggoen akar DECFSZ-el is lehet egy változó nullás értéket vizsgálni, de most azt hiszem nem erről van szó.
Icserny ötlete szerint az egész Makroba kerül a BTFSC-vél együtt, szerintem CALL-ba kell rakni, mindkettő működik és meg vagy ezer másik megoldást lehetne találni erre. Nem is értem mit szorszal hasogatunk itt mikor nem ez volt a kérdés.
Egy 4x4 -es billentyűzetet próbálok kezelni 887-essel.
a PORTB-re kötöm mind a 8 vezetéket. A portot beállítom bemenetnek, és bekapcsolom a felhúzó ellenállást. Most az a gondom, hogy a szimulátorban tesztelve, a port alacsony szintű marad. Nem kellene átváltania 1-be minden lábnak?
A szimulator nem tudja a harvert tesztelni, nem tudhatja, hogy a kulso aramkor esetleg hogyan huzza le vagy fel a labat (igy az irrevelans, hogy bekapcsoltad-e a belso felhuzo ellenallast vagy sem, hisz attol meg a kulso aramkor lehuzhatja a port labat).
A stimulusoknal lehet a port labak allapotat megadni, ott meg tudod adni melyik idopillanatban melyik lab milyen allapotot vegyen fel... azaz kvazi azzal szimulalod a hardvert. Ha nagyon kell, akkor Virtualbreadboard-dal vagy Proteus-szal lehet a PIC melle kulso aramkort is szimulaltatni. A Proteus professzionalisabb (az ara is), a Virtualbreadboard pedig ingyenes, es sok esetben az is kielegito segitseg tud lenni.
Szia!
Az MPLab Stimulusával és egy külső programmal (Excel) meg lehet oldani a szimulációt. Bővebben... A stimulus állományt a feladathoz kell igazítani..
Letiltottad az analóg bemeneteket a lábakról?
A 16F88x -nél a PORTB -n nincs analóg funkció...
A debugger korlátairól a Debugger / Settings ablak Limitation fülén tájékozódhatunk. Részleteket a Details gomb megnyomásával megjelenő ablakon kapunk. Köztük: Idézet: „Weak pull-ups on ports not implemented.”
Bocsánat! A 16F87x adatlapját néztem meg, a 16F88x helyett...
A 16F88x -nél vannak alalóg funkcióval rendelkező kivezetések a B porton, ami az ANSELH regiszterrel vezérelhetők, de az RB7 és RB6 kivezetésnek digitálisan kellene működnie, ha az analóg funkciók nincsenek letiltva. Továbbá a port működésébe beleszólhat a LVP, ha nincs letiltva (RB3, RB6, RB7).
Köszönöm, ez megoldva.
Most már csak azt nem tudom, hogy a válozóimat miért nem tudom a watch ablakba tenni? Valahol itt olvastam már a megoldást, de nem találom.
Hello!
C ben írok egy PIC progit és igény lett rá hogy a kimenet állapotát lekérdezem! Kérdés ugyan úgy megtehetem mintha bemenet lenne?? Jelenleg egy kiment vezérlése, beállítása így néz ki #define x_ki() LATDbits.LATD0=0; #define x_be() LATDbits.LATD0=1; #define x_allapot PORTDbits.RD0; #define x_kimenet() TRISDbits.TRISD0 = 0; Értelemen szerűen x_ki() kikapcsolás x_be() bekapcsolás x_allapot valahol máshol a programban ezzel szeretném megtudni hogy ki vagy be van kapcsolva? Ha így megy nem szeretnék egy külön jelzőt mivel nem csak ez az egy kimenetem van! Meg akkor kapcsolni is kell meg jelzőt is állítani elég macera!
Megteheted, de en amugy nem igy csinalnam... LATD0-at kerdeznem le, hiszen a PORT az aktualis allapotot tukrozi, a LAT pedig a kivant allapotot, es nyilvan Te erre lennel kivancsi nem? Ugyanis elofordulhat, hogy egy nagyobb terheles miatt pl a PORT nem kepes eleg gyorsan kapcsolni a kimenetet, mint ahogy Te le sazeretned kerdezni, es az hibas mukodeshez vezethet.
Amugy en valahogy igy csinalnam:
(most ez lehet nem tokeletes igy, mert nem probaltam meg forditani, de remelem jol latszik az elmelet amit kozeliteni probalok)
Szia!
Az elképzelés jó, működik... A #define x_allapot LATDbits.LATD0; - mindig az utoljára kiadott vezérlés értékét adja vissza, még akkor is, ha közben a kivezetést bemenetnek vagy analóg módra állítottuk át. #define x_allapot PORTDbits.RD0; - mindig a kivezetésen megjelenő szint szerinti értéket adja vissza - digitális módban. Itt figyelembe kell venni a komparálási szinteket, a láb terhelését. Előfordulhat, hogy a kivezetésen a statikus terhelés (túl nagy áram) vagy dinamikus túlterhelés (túl nagy kapacitás) miatt a szint nem éri el a kívánt értéket ( dinamikus esetben a váltás után történő beolvasásig).
Köszönöm akkor ez lesz
#define x_allapot LATDbits.LATD0; mert engem az érdekel mire állítottam és idővel úgyis arra áll a kimenet. Kimenetekre Optotriakok lesznek kapcsolva tehát gondolom nagy áram nem lesz. Elvileg bőven percekbe mérhető a váltogatások közötti különbség Elv ez lenne Vezérlés1 / kapcsolgatás / Vezérlés2 / kapcsolgatás / Vezérlés3 / kapcsolgatás / Vezérlés4 / kapcsolgatás / LCD Megjelenítés az alapján hogy mire kapcsoltam. Ide kell, az állapot lekérdezés hogy tudjam mire kapcsoltam. Szándékosan van külön a megjelenítés és a vezérlés Úttó kérdés: #define x_ki() LATDbits.LATD0=0; lehet igy is írni () nélkül #define x_ki LATDbits.LATD0=0; akkor egy kapcsolás így nézne ki??? x_ki;
Neked is Köszönöm Végül is a lényeg hogy a LATD0 kérdezem
A #define direktívákat a C preprocesszora dolgozza fel, a C fordító már a kifejtett szöveget kapja...
A
sorból a
direktíva hatására keletkező sor helyett a fordító a
utasítást kapja, amit hiba nélkül fordít le.
A define-hoz ne tegyel pontosvesszot! Amugy jo lesz ez.
UI: Ha ezt irod:
akkor az elofeldozgozo amirol Hp41C meselt ezt teszi be:
...igy ket db pontosvesszovel... ami persze ebben az esetben nem egy nagy dolog, de nem szerencses erre raszokni.
Van egy kis sikerélményem a Devfile editorral: a device file átszerkesztése után sikerült PICkit2-vel beégetni egy LED villogtató programot egy PIC32MX795F512L mikrovezérlőbe (Explorer 16 kártyához való PIM modul). Ebben az a vicc, hogy a PICkit2 hivatalosan nem támogatja ezt a típust.
Innen vettem az okosságokat: Először duplikáljuk a PIC32MX460F512L MCU bejegyzést. Majd átírjuk az alábbiakat benne: PartName: PIC32MX795F512H DeviceID: 0x0000E000 ProgramMem: 0x00020BFC Az MPLAB nem engedte a PICkit2-őt kiválasztani, de a PICkit2 saját programjával hajlandó volt beírni, s a VDD bekapcsolása után működött. A dolog még tesztelés alatt van, a konfigurációs bitekhez még nem mertem hozzányúlni.
Ezzel én is játszottam, 18F46K20-ból 18F46K22-t csináltam. Majd észrevettem, hogy a PK2 alapból támogatja, csak frissíteni kellett volna a programozó saját programját. Mivel aztán tényleg frissítettem, össze tudtam hasonlítani a két kontroller eredeti device file-ját, kb. 10 különbséget vettem észre.
Ennek ellenére sikerült felprogramozni egy-egy AN1310-es bootloaderrel két ilyen PIC-et a frissítés előtt, amely működött is! Egészen az első bootloaderrel működő program rátöltése utánig, mert az még ugyan futott, de a következőt már nem lehetett rátölteni, és innentől a PK2 sem volt hajlandó írni őket (törlés után sem), frissítve sem. Én többet ilyen agyontuningolt PIC-et nem tervezek venni.
Sziasztok!
Itt olvasgatom az EEPROM írását. Ha jól értelmezem akkor az PIC adatlapja szerint megadott írási ciklusok száma 1 bájtra vonatkoznak? Ha nem akkor hogy is van ez? A másik, hogy egy 18LF4320 20MHz futna és a BOR feszültségét 2.7V-ra állítom az jó e?
Igen, minden egyes bájt legalább/tipikusan annyiszor írható, amennyi az adatlapban meg van adva.
Jó.
Helyesbítenem kell magam, mert tegnap figyelmetlenségből a Microchip fórumáról az PIC32MX795F512H mikrovezérlőhöz tartozó DeviceID-t másoltam be.
Nálam viszont PIC32MX795F512L típus van, ehhez a DeviceID: 0x00007000 értéket kellett beírni a Devfile erditorba. |
Bejelentkezés
Hirdetés |