Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Sziasztok!
Több napja szenvedek egy proggival PIC18F-es kontrolleren és végre működik...de nem értem, miért... l  Azt vettem észre, hogy bizonyos esetekben nem mindegy, hogy ezt írom: movlw 0x0c movwf temp vagy movf 0x0c,temp ezután jön egy szubrutinhívás ahol azonnal feldolgozom a temp-et, tehát esélye sincs megváltozni. A leírás szerint a movf a z bitet bizgatja, más eltérés nincs. Meg tudná valaki mondani, hogy mi a különbség a két utasítás közt? Másrészről a PORTx és a LATx különbségeit sem nagyon értem, próbálgatással sikerült kisakkoznom a helyes(?) hivatkozást, van valami konkrét szabály, hogy mikor-melyiket kell használni? Köszönöm!
steev!
A kérdésed átkerült IDE, mivel nemigen tartozott a PIC-es topikhoz! Legközelebb erre jobban figyelj, sajnos így sem teljesen homogén már a PIC-es topik...
Szia!
Az az oldal jól leírja a 16-os család használatát, és az alapokat is. Eleinte én is onnan tanultam, aztán megvettem a Kónya féle könyvet. A könyv természetesen nem kötelező, de hasznos. Emellett sok anyag van a neten is, igaz nem mind magyarul. Amit a többiek írtak/írnak neked(is), azt segítő szándékkal írják, és nem kötekedésből, érdemes megfogadni őket. Velem is hasonló volt a helyzet annak idején. Én öt hónapja ismerkedek a PIC-ekkel(úgy, hogy nem az összes szabadidőmet a PIC-eknek szenteltem) és megtanultam használni a szimulátort, timer modulokat, ADC-t, megszakítást, táblázat használatát. Összehoztam egy vizsgamunkát, ami úgy működik ahogy terveztem. A fórumot rendszeresen olvasom, de elég passzív vagyok. Nem elmenekültem, hanem nincs mit kérdeznem. Ha valami nem úgy működik ahogyan szeretném, alszok rá egyet aztán addig csűröm csavarom, amíg rá nem jövök, hogy hol hibáztam. A ledvillogtatás bugyuta példának tűnik, de a segítségükkel a fentebb leírt dolgok mind elsajátíthatók. Sőt soros kommunikáció, CCP modul, komparátor modul is. Végül sok sikert kívánok a tanuláshoz!
Azt megnézted-e, hogy a MOVF utasítás két paramétere közül melyik micsoda? Nézd meg az adatlap Instruction summary fejezetében a MOVF leírását!
A PORTx és LATx használatáról már volt csomószor szó itt a témában, keress rá. Illetve az adatlap IOPorts részében le van írva és a blokkrajzokon le van rajzolva, hogy melyik micsoda.
Az első utasítássorozat a w regiszteren keresztül ügyködik. Ez fontos lehet a szubrutinba való ugráskor, hiszen lehet, hogy valami épp felhasználja a w regiszter tartalmát a szubrutinon belül (és lehet, hogy erre véletlenül nem gondoltál).
Második esetben az egész művelet kikerüli a w regisztert, attól teljesen függetlenül jut az adat az egyik regiszterből a másikba. A PORTx és LATx közti különbség pedig az adatlapban található, mellékelve egy képfájl! A piros útvonal az írási művelet mikéntjét mutatja, a kék útvonal pedig az olvasás útját szemlélteti. A lilával bekeretezett résznek különleges és fontos szerepe van. Ez mondja meg ugyanis, hogy a LATx tartalma megegyezhet a porton ténylegesen lévő jelszinttel, vagy a kettő akár teljesen független is lehet egymástól!
Norberto, potyo!
Köszönöm! Próbálom emészteni. A furcsa az, hogy pont a w regisztert használom a progiban, tehát a movlw 0x0c call subrt helyett a movf 0x0c,w call subrt működik helyesen. (subrt első sor: movwf LATD) valamint a #define bit LATE,1 -> bsf bit nem csak a #define PORTE,1 -> bsf bit működik... csak hogy fokozzam: MPLAB újraindítást követően működik a LATE is... Nah, olvasgatok még egy kicsit erről. Köszi a segítséget! Idézet: „movlw 0x0c helyett a movf 0x0c,w működik helyesen.” Meradjunk annyiban, hogy mindkettő helyesen működik (ha nem így volna, már mehetne is a kukába), legfeljebb nem azt csinálja, amit vársz tőle. Hogy mit vársz tőle azt én sem tudom, de az nagyon helyénvaló, hogy nem ugyanazt csinálja a két utasítás, hiszen az elsőnél az az L betű nem dísznek van ott. :yes: Nem lövöm le a poént, az adatlapból az utasítások részletes leírásánál mindenre fény derül. Az "Operation:" sorra koncentrálj! Abból derül ki, hogy mit csinál. Idézet: „Meradjunk annyiban, hogy mindkettő helyesen működik (ha nem így volna, már mehetne is a kukába), legfeljebb nem azt csinálja, amit vársz tőle.” Jogos!  Mondjuk ettől még nem vagyok beljebb, már ami az idézett kódrészletet illeti. Azt már látom (adatlapból) hogy nem csak a Z bit áll be a movf-től, hanem a N is, ez magyarázatot ad némely kérdésemre, eddig ugyanis nem adatlapot néztem, hanem egy utasításkód-kivonatot (könnyebben kezeltem a vaskosabb adatlapnál) és a kettő nem egyezett. Tanulság: adatlap a Biblia PIC-éknél.
Utolsó lehetőség. Mostmár illene a homlokodhoz csapni :bummafejbe:
Ha vetted volna a fáradságot és az oldalamró elindultál volna az ajánlott úton, akkor ezt az oldalt is megtalálhattad volna a hivatkozások között. Gondolom akkor nem kérdezted volna meg, hogy milyennek találjuk az oldalt...
Bár már le kéne essen, segítek a kelleténél talán többet is, mert ha ezt nem olvasod ki az adatlapból, akkor nagyon sok bajod lesz még ezzel!
Tehát:
illetve:
Egyébként nem is biztos, hogy a fordító elfogadja, ha a temp nem 1, vagy 0, de ezt még nem próbáltam ki eddig soha, mert nem sok értelme van...
:pirul:
Túl jók vagytok hozzám.... Köszönöm a segítségeteket és a türelmeteket! Remélem, nem mentem nagyon az agyatokra.... Most már értem és így már világos Norberto belinkelt magyarázata is (külön köszi a kiemeléseket benne!) :worship:
Én gyanítom, hogy az tulajdonképpen movff utasítás akart lenni, mert úgy még lenne is értelme.
Én is gondoltam rá, de mivel egy értéket akart betölteni egy változóba, ezért nem lehet a MOVFF azt hiszem...
Bocsanat, hogy bele szolok, de ugy erzem egy kis pontositas helyen valo lenne. Jobb lenne valoszinuleg ha nem 'temp'-nek, hanem 'destination'-nek (avagy cél-nak) hivnank azt a parametert ami az adatlap szerint 0 es 1 erteket vehet fel csak -- elmeletileg a forditonak sikoltoznia kellene ha mas szerepel ott. Tehat valahogy igy lehetne inkabb leirni:
Na, es akkor ez a mondat:
...a fenti definialassal mar helyes lesz  Amugy a 18F-nek ot van meg a harmadik parametere is az Access parameter, de ezt megint hagyjuk KipKap-nak, hogy nezze ki az adatlapbol mi a szerepe 
A temp azért temp, mert KipKap így hívta a 'destination' helyére beírt paramétert! :felkialtas:
Minden további magyarázat ebben a szellemben történt...
Rendben, latom mar! Valoban az elozmenyeket olvasva mar ertheto amit irtal.
Nekem inkább úgy tűnt, hogy a 0x0c címről akar kiolvasni egy adatot (lásd itt).
Topinak javasolni kellene, hogy bővítse a Fórum funkcióit: lehessen ilyenkor fogadásokat kötni arra, hogy vajon mi is lehetett a kérdező szándéka.   Egyébként valóban úgy tűnik, de kérdés, hogy miért nem deffiniálta a változót? Kinek és miért jutna eszébe egy fix memóriacímet hexában megadni? Régen az Enterprise gépemen, amihez nem volt assembler fordító, így írtam az első valódi gépi kódomat egy Basic játékprogram grafikus rutinjaként Z80-as platformra, de az MPLAB-ban ez elég érthetetlen. Ezért sem gondoltam volna...
Hehe, en Apple II-re csinaltam ugyanezt, papiron irtam meg a programot, majd gepi kodra leforditva gepeltem be -- a vegen mar on-the-fly ment a "compiler uzemmodja" az agyamnak - neztem a papiron az asm utasitasokat es folyamatosan gepeltem a hex szamokat
Mikor az elso Assembly forditot meglattam aminek Merlin volt a neve, csak kerek szemekkel neztem, hogy jeee, cimkeket lehet adni az utasitasok ele meg a valtozokat milyen kenyelmesen lehet deklaralni Hat Merlin tenyleg varazslatos volt
Szerintem ezért is megy nekünk ez a PIC téma relatív könnyen(mert, hogy nem így születtünk, az biztos). Ha valakinek van egy kis esze, és netán elolvassa a kis félig offunkat, talán rájön, hogy miképpen kell megközelíteni ezt és a PIC mi is valójában!
[OFF] Engem komolyan mondom az idegesit legjobban mikor 'proc'-nak mondjak a mikrokontrollert. Ez ugyanis arra utal, hogy azt kepzeli az illeto, hogy az MCU (Micro Controller Unit) az egy CPU (Central Processing Unit). Kb mintha azt kialtozna: "Tudok banni a lombfuresszel, ide nekem a nagy fejszet had irtsam az erdot!". Mar tisztelet a kivetelnek.
Szia!
Nem,nem!  dec 12-őt szerettem volna az akkuba tenni, ezért nem értettem, miért módosul a tartalma egy szubrutin hívást követően.Azért még én is címkével hivatkozom a memóriváltozóra, még így is elfelejtem a nevüket... Öregszem na!
Szívesen elhinném, de akkor miért írtad, hogy
működik helyesen? Idézet: „Nem,nem! dec 12-őt szerettem volna az akkuba tenni, ezért nem értettem, miért módosul a tartalma egy szubrutin hívást követően.” Nem szeretnelek vegkepp elkeseriteni, de a PIC-ben nincs akkumulator. Helyette WREG (azaz Working Register - Munka Regiszter) van. MOVLW-t ha lebontod 3 betu es parameterekre: MOV L -> W azaz "Move the Literal to the Wreg". Ugyanugy MOVWF-bol szetbontva MOV W -> F azaz Move the Wreg to the File (mivel Microchip a regisztereket mas neven file-oknak szokta emlegetni). Nyilvan innen mar a MOVFF utasitas lenyege hamar kikovetkeztetheto Ha ilyen modon gondolkodsz, akkor joval kisebb az eselye, hogy rossz utasitast hasznalsz -- marmint nem rossz, csak epp nem az amit szerettel volna.
Egy valamit (inkább sok mindent) nem teljesen értek:
Itt most a feladat lényege mindegy (ledvillogtatással kipróbáltam), csak az elvét nem igazán értem, a for cikluson belül ellenőrizni kéne még az interrupt flaget ? ( Mondjuk ez utóbbival se ment, ezért eléggé homályos dolgok vannak itt nekem. )
A második esetben x-nek nem adsz értéket és nem is csinálsz vele semmit a ciklusban, így vagy nullaszor fog lefutni, vagy végtelen ciklus lesz belőle, attól függően, hogy x éppen kisebb vagy egyenlő-e 8-cal.
A megvalósítandó (rész)feladat ismerete nélkül egyébként nem nagyon lehet mit mondani, az első blokkban leírt programrészlet akár még értelmesen is viselkedhet.
Húh, én hibám, x helyett az természetesen "y". Szóval kipróbáltam ezt 4 LED -el, végülis futofény lesz belőle a shiftelés miatt, rendben, ez idáig érthető az első esetben; másodikban, viszont a legalsó értéken levő LED után egyből ( vagy csak nem érzékelem ) az utolsó ( jelen esetemben az RB3 ) LED kezd el világítani. Ezt nem értem teljesen.
Valoszinuleg az interrupt fogalmat nem erted. Az interrupt angol szo aminek a magyar megfeleloje a megszakitas... Megszakitas, azaz a normal kod futasa megszakad bizonyos esemeny bekovetkeztekor es helyette az megszakitas kezelo kezd el futni. Addig fut amig vissza nem adja a vezerlest, azaz jelen esetben a fuggvenybol ki nem lepsz. Ezt kovetoen a normal program ott folytatja a futast ahol abba hagytad.
Namost, a Te esetedben a LED villogtatasahoz gondolom a timert ugy programoztad fel, hogy az bizonyos idokozonkent megszakitast eredmenyezzen. A foprogramod pl atmehet egy ertlmetlennek tuno vegtelen ciklusba ami nem csinal semmit, azonban a timer idorol idore megszakitast fog eredmenyezni azaz az ertelmetlen ures ciklust ideiglenesen abba hagyja, majd lefut az interrupt kezelo (a timer_isr) es utan a megint atmegy a programod malmozoba... Amit Te kerdezel, hogy miert nem jo, mert egy ilyen megszakitas alkalmaval a LATB hirtelen vegig szalag a for ciklusodnak koszonhetoen, majd megint elmegy malmozni. Aztan kis ido mulva megint vegig fut, majd megint malom. Mivel a for ciklusban nincs varakozas a porton olyan gyorsan fog a jel valtozni, hogy a LED latszolag ki sem gyullad -- scope-al meg fogod tudni nezni persze, hogy valoban a jel megjelent a kimeneten... |
Bejelentkezés
Hirdetés |
