Fórum témák

» Több friss téma
Fórum » PIC - Miértek, hogyanok haladóknak
Lapozás: OK   386 / 1319
(#) trudnai válasza watt hozzászólására (») Jan 12, 2009 /
 
Idézet:
„De csak a magas szintű megszakításnál mentődik el, illetve csak akkor állítódik onnan vissza, ha a RETFIE FAST utasítást adod ki a visszatérésre a végén.”


Ill. ez egeszen pontosan ugy hangzik az adatlapban, hogy egyetlen hely van a contextus tarolasara, es mivel a low priority int megszakadhat a high altal, ezert ha ketszintu megszakitast hasznal az ember a low-ban "nem biztonsagos" ennek hasznalata. Azaz ha nem kovetkezik be high int mikozben a low szolgalodik ki, akkor minden ok, de abban a pillanatban hogy bekovetkezik a high minden borul... Ezert szokas a low-ban a "hagyomanyos modon" menteni a contextust, mig a high-ban a fast-tal. De amugy is, a high interruptnal mar lehet szamit a sebesseg, szoval ott mar van is ertelme a dolognak.
(#) watt válasza trudnai hozzászólására (») Jan 12, 2009 /
 
Eddig oké, de mi van a kétszavas utasításokal?
Meg aztán "azonnal" a hardveres veremmel sem érünk a célhoz, mert számolni kell a forrás azonosításához szükséges idővel is. Ha valami 6 gépi cikluson múlik, akkor ott már gáz van.
Mindenesetre kényelmesebb és gyorsabb lenne, ha nem lenne vele ennyi nyűg.
(#) MPi-c válasza potyo hozzászólására (») Jan 12, 2009 /
 
Idézet:
„Ezügyben érdemes az adott chip errata-ját is megnézni, mert egyes revízióknál volt probléma a RETFIE FAST visszatérésnél...”

Üdv!
Erről meg én nem tudtam.
Most próbálkozom C18-ba belemerülni. Meg is néztem, hogy mi a helyzet a megszakításnál a fordított kódban. Azt látom, hogy egyszintű megszakításnál a gyors regisztermentést és visszatöltést használja. Adott PIC-nél az általad jelzett hibát a fordító kezeli? Egyébként milyen módon lehetne megadni a fordítónak, hogy ne használja és helyette a „normál” megoldás kerüljön a kódba?
(#) trudnai válasza watt hozzászólására (») Jan 12, 2009 /
 
Idézet:
„Eddig oké, de mi van a kétszavas utasításokal?”


Ahogy irtam akkor van gaz, ha MOVFF-el WREG-et vagy STATUS-t avagy BSR-t cimzel meg - egyebkent minden ok.

Tehat ehelyett:
  1. MOVFF   VALTOZO, STATUS

Ezt irod:
  1. MOVF     VALTOZO,W
  2.     MOVWF    STATUS

illetoleg:
  1. MOVFF   STATUS, WREG

helyett:
  1. MOVF     VALTOZO,W

Az egyetlen gond csupan az az, hogy a MOVFF-nel nem kell bankolgatni mig a sima MOVF ill MOVWF-nel igen (na de ezt meg ki lehet megintcsak optimalizalni, hogy lehetoleg access ram-ra tesszuk azokat amiket gyakran erunk el, igy sporolunk a BSR hasznalataval)

Idézet:
„Meg aztán "azonnal" a hardveres veremmel sem érünk a célhoz, mert számolni kell a forrás azonosításához szükséges idővel is.”


Ezt nem egeszen ertem?

Idézet:
„Ha valami 6 gépi cikluson múlik, akkor ott már gáz van.”


Mondjuk a MOVFF az 2 gepi ciklus, igy az interrupt belepesekor ha csak a WREG, STATUS ill BSR mentodik el akkor az mar 6, vissza tolteskor ujabb 6 ciklus megy el az mar 12... Es ha a low interruptban vagyunk es jon egymas utan tobb high int is, akkor az mar jelentos veszteseg - mondjuk abban igazad van, hogy lehet akkor a program rosszul van szervezve ha ez gyakran bekovetkezik
(#) potyo válasza MPi-c hozzászólására (») Jan 12, 2009 /
 
A fordító automatikusan nem kezeli, mert a chip revíziójától függ, hogy fennáll-e a probléma vagy nem, a fordító viszont a tipusra készíti a kódot. Mindig az adott revízióhoz tartozó errata-t kell nézni. Pickit2 és ICD2 ki tudják olvasni a reviziót is az aktuális chipből, MPLAB-ban connect-kor ki is írja.

Ha az adott chipnél fennáll a probléma, akkor a magas prioritású megszakítási rutint is #pragma interruptlow-al kell megadni, a címe természetesen marad a magas vektor címe (0x08). Ezzel kényszeríted, hogy mentse el a regisztereket "kézzel" és a rutin végén ne használja a RETFIE FAST-ot.
(#) watt válasza trudnai hozzászólására (») Jan 12, 2009 /
 
Idézet:
„Ahogy irtam akkor van gaz, ha MOVFF-el WREG-et vagy STATUS-t avagy BSR-t cimzel meg - egyebkent minden ok.”

Értem, köszi!

Idézet:
„Az egyetlen gond csupan az az, hogy a MOVFF-nel nem kell bankolgatni mig a sima MOVF ill MOVWF-nel igen (na de ezt meg ki lehet megintcsak optimalizalni, hogy lehetoleg access ram-ra tesszuk azokat amiket gyakran erunk el, igy sporolunk a BSR hasznalataval)”

Igen, erre van egy jó trükköm. Kiválasztom az 1-es bankot, és így bankváltás nélkül 128+256 AM-ot elérek. Nem nagyon szokott több kelleni. Ha még is, az általában puffer, aminél követhető a bankolás és indirekten címződik amúgy is.

Idézet:
„Ezt nem egeszen ertem?”

Úgy értette, hogy a vektoros lekezeléssel szemben(dsPIC, 24F) itt időbe telik, míg kiderítem mi okozta a megszakítást. Abban igazad van, hogy 12 ciklus, én csak az elejét néztem, de ennyi sem számíthat, mert akkor nem jó eszközt választottunk!

Mindenesetre hasznos volt ez a kis eszmecsere!
szerk: Nem különben potyo utóbbi szösszenete a pragmáról!
(#) MPi-c válasza potyo hozzászólására (») Jan 12, 2009 /
 
Kösz! Odafigyelek erre.
(#) trudnai válasza potyo hozzászólására (») Jan 12, 2009 /
 
C18-ban ezt is meg lehet valositani (kiollozva az erratabol):
  1. #pragma code high_vector_section=0x8
  2. void high_vector (void)
  3. {
  4.   _asm
  5.     CALL high_vector_branch, 1
  6.   _endasm
  7. }
  8. void high_vector_branch (void)
  9. {
  10.   _asm
  11.     POP
  12.     GOTO high_isr
  13.   _endasm
  14. }
  15. #pragma interrupt high_isr
  16. void high_isr (void)
  17. {
  18.   ...
  19. }

Aminek ugyanaz a hatasa, mint ASM-ben ez:
  1. ISR @ 0x0008
  2.     CALL Foo, FAST ; store current value of WREG, BSR, STATUS for a second time
  3. Foo:
  4.     POP ; clears return address of Foo call
  5.     : ; insert high priority ISR code here
  6.     :
  7.     RETFIE FAST

De mas C forditoknal nem tudom hogy lehet ugyanezt kieroszakolni, bizotosan foglalkoztak mar sokan ezzel a temaval, csak ra kell keresni a google-on...
(#) MPi-c válasza trudnai hozzászólására (») Jan 12, 2009 /
 
Ezt az "ugrálós" megoldást is megjegyzem. Köszönöm!
(#) Krisz03 hozzászólása Jan 12, 2009 /
 
Hali!

Mint nagyon kezdő PIC-es szeretném a véleményeteket kikérni egy próbapanel ügyében. Ugye van Topinak a "Nulláról a robotokig" című írása, amit majd szeretnék tüzetesen átolvasni, és közben persze tanulni és gyakorlatban is tesztelni, viszont nekem a dugdosós panel nem igazán jön be, inkább szeretnék valami tartósabbat alkotni, amit bármikor felhasználhatok. Szóval gyorsan átfutva a cikkeket, kigyűjtöttem, hogy milyen eszközök, milyen lábakra vannak kötve. Illetve felhasználva az ezen az oldalon található 16F877-es próbapanelt, összeütöttem egy kapcsolási rajzot. Szeretném, ha véleményeznétek, és megmondanátok, hogy ha kell, akkor mivel egészítsem még ki, mit javítsak rajta.

A kapcsolási rajzom itt található.

Illetve még annyit kérdeznék, hogy mivel nemsokára kapok egy kedves fórumtárstól egy PICkit2 klónt, hogy azt égetés után is rajta lehet hagyni majd ezen a próbapanelen, és nem kell mindig lehúzni, mint a jelenlegi égetőmet? Ugyanez a kérdés vonatkozna a fentebbi próbapaneles oldalon található másik, 16F84A-s panelre is. Pontosabban megfogalmazva a kérdést, azzal tisztában vagyok, hogy az égető képes erre a funkcióra, csak a céláramkörben van-e valami szabály, amit be kell tartani az ICSP port bekötésénél (gondolok itt pl arra a diódára az MCLR lábon)?

Előre is köszi a válaszokat!
Krisz
(#) sszasza hozzászólása Jan 12, 2009 /
 
C18as kérdés.
//inic
const rom char SZ1[]= {1,2,3};
const rom char SZ2[]= {4,5,6};
const rom char* SZ[]={SZ1,SZ2};
//kivánt felhasználás
A=SZ[1][1];

Lefordul, de SZ-t nem ám a Prog.mem.ben hozza létre ahogy szeretném, hanem a ramban. Igy persze hülyeség a végeredmény is. Hogy kell ezt?
(#) watt válasza Krisz03 hozzászólására (») Jan 12, 2009 /
 
Az én véleményem az, hogy nem érdemes ilyen "mindent bele" próbapaneleket építeni, mert hamar kinövi az ember és utána nem jó semmire. Én olyan próbapanelt használok, ahol van néhány foglalat és minden láb ki van vezetve tüskecsatlakozókra. A csatlakozóra lehet tervezni modulokat, amiket csak rá kell dugni és azt csinálja amit a modulra terveztünk. Ha túl vagyunk a LED villogtatós időszakon, akkor gyakoraltilag bármilyen modult lehet hozzá tervezni, sőt lógóban is sokmindent rá lehet forrasztani a csatlakozókra(nem közvetlenül a tüskékre természetesen).
Ilyen próbapanelt találsz az oldalamon.

Az ICSP kérdésedre a válaszom, nem kell semmi faxni, elég egy 10k-s felhúzó + egy 10n-s kondi az MCLR lábra. Ha teszel rá reset gombot, akkor azt programozsás közben ne nyomkodd!
(#) Krisz03 válasza watt hozzászólására (») Jan 12, 2009 /
 
Végülis van abban valami, amit mondasz, de ahogy magamat ismerem, elég nehezen megy nekem a programozás tanulása, szóval egy jó ideig ellennék vele. Ha pedig kinövöm, akkor talán hasznos lesz egy másik kezdő PIC-esnek. Azért fontolóra veszem az ügyet.

Szóval akkor felesleges az a sok "csicsa" a port körül, és még túl is van bonyolítva. De azért működőképes így is, csak nem a legpraktikusabb. Értem.

Köszi a segítséget!

Ui: Mivel lehet megnyitni a honlapodon azt az PCB fájlt? ExpressPCB nem viszi.
(#) vizor hozzászólása Jan 12, 2009 /
 
Üdv Mindenki !

Megszakításról szeretnék kérdezni. Adott egy 16F628A ami 8Mhz-es kristállyal van meghajtva. Egy óraprogramot írok (bináris és decimális kijelzés). Melyik timert vagy más dolgot használjak és hogyan osszam le, hogy pontosan 1 másodpercenként legyen egy megszakítás ? Timer0, timer1, elő, utóosztás vagy valami más ? Ha igen, hogy kell beállítani ?

A programban folyamatosan fut egy kb. 40 mikroszekundum hosszú rutin, ami 6 regiszter értékét írja multiplexelve egy kijelzőre. Amikor bekövetkezik a megszakítás akkor futna le egy kb. 50 mikroszekundumos rutin ami módosítja az óra 6 regiszterét. Ezek az idők elhanyagolhatóan rövidek szerintem. Jelenleg a progi működik csak pontos megszakítás nélkül kb. 4 óra telik el rajta másodpercenként

Előre is köszi !
(#) Norberto válasza vizor hozzászólására (») Jan 12, 2009 /
 
Idézet:
„Amikor bekövetkezik a megszakítás akkor futna le egy kb. 50 mikroszekundumos rutin ami módosítja az óra 6 regiszterét. Ezek az idők elhanyagolhatóan rövidek szerintem.”


Ezek nem elhanyagolható idők szerintem; ha nanoszekundum lenne, akkor talán

Azért az a néhány mikroszekundum és a 8 MHz-es kristály rezgéséből adódó periódusidő eléggé összemérhetők egymással.
(#) vizor válasza Norberto hozzászólására (») Jan 12, 2009 /
 
Más dolga sincs mint ezer mikrosec-enként lefusson egy 50-es. Azért ilyen sok, mert egyszerre kezel ledeket (bináris) és 7 szegmenses (decimális) kijelzést. Közben nem csinál semmi mást. Csak mivel nem értek a megszakításokhoz, folyamatosan ezt látom: 88:88:88, a ledek meg mind világítanak, de ez végül is logikus. Hogyan tudok 1 sec-es megszakításokat generálni ?
(#) vizor válasza vizor hozzászólására (») Jan 12, 2009 /
 
Természetesen tudom, hogy lehetne jobb is, de egyenlőre ennyi telik tőlem Örülök, hogy ezt is elértem
(#) vizor válasza vizor hozzászólására (») Jan 12, 2009 /
 
Sőt, rosszul írtam. 1 másodperc 1.000.000 mikrosec, abba csak belefér 50 mikro (az előbb 1000 millisecet akartam írni).

Bocs a három post-ért, már nem engedte módosítani
(#) potyo válasza vizor hozzászólására (») Jan 12, 2009 /
 
Bármelyik timert használhatod, de az előosztót és az utóosztót is egyre állítsd, mert egyéb esetben ha épp nem úgy talál beállni a megszakítás, akkor a timer tartalmának módosításakor az előosztó nullázása miatt az órád késni fog. Célszerű a 16 bites timer1-et használni.

Megszakításkor a timer pillanatnyi értékéhez hozzá kell adni valamennyit, hogy a következő megszakítás adott idő múlva következzen be. 8MHz-es kvarcnál 500ns egy utasítás végrehajtásának ideje, ami a 16 bites timerrel 32,768ms időnként okozna megszakítást. Ami ettől kisebb szám, de az 1000ms-ot elosztva egészet ad, az a 25, vagyis úgy kell a timer értékét módosítani, hogy 25ms időnként okozzon megszakítást. Tehát 32768-25000=7768-at kell hozzáadni a timer pillanatnyi értékéhez. Na mivel a timert az állítás idejére leállítjuk, ezért ettől valamivel többet kell hozzáadni. 7768d=0x1E58

Tehát a kód valami ilyesmi lesz a megszakítási rutinban:
  1. BCF T1CON, TMR1ON
  2. MOVLW 0x51    ; ide nem biztos, hogy 0x5F kell majd, szimulátorral meg kell nézni, hogy pontosan 25ms időnként adjon megszakítást.
  3. ADDWF TMR1L, F
  4. BTFSC STATUS, C
  5. INCF TMR1H, F
  6. MOVLW 0x1E
  7. ADDWF TMR1H
  8. BSF T1CON, TMR1ON


És amikor ez a rutin lefut, akkor egy változó értékét növelgeted. Amikor elért a változó 40-re, akkor telt le az egy másodperc. Ekkor a változódat nullázod, és kezdődik az újabb másodperc.
(#) vizor válasza potyo hozzászólására (») Jan 12, 2009 /
 
Azt hiszem értem. Köszönöm, megyek kipróbálom.
(#) icserny válasza Norberto hozzászólására (») Jan 12, 2009 /
 
Idézet:
„Adott egy 16F628A ami 8Mhz-es kristállyal van meghajtva.”

Az 1 másodperces interrupthoz 32 kHz-es kvarcot kellett volna használni...

Timer2-vel például egy beállítási lehetőség:
Belső órajelbemenet (Fosc/4) => 2 MHz
Prescaler = 1:16 => 125 kHz
PR2 = 250 => 500 Hz
Postscaler = 10 => 50 Hz

Tehát 20 ms periodussal (50 Hz) kapsz timer2 interruptot, s eggyel több számláló kell (amiben mire 50-et leszámláltál, pont 1 másodperc telik el. A többit meg már tudod...

Idézet:
„kb. 4 óra telik el rajta másodpercenként”

Mint a mesében: 3 nap egy esztendő!
(#) vizor válasza icserny hozzászólására (») Jan 12, 2009 /
 
Hát, kristályom csak az van amit bontottam és ez volt az egyetlen ami nem valami extrém tört értékű volt, hanem kerek. Gondolom a 7.776 Mhz vagy 4433.61 Khz-essel még nehezebb lenne
(#) icserny válasza icserny hozzászólására (») Jan 12, 2009 /
 
Idézet:
„icserny válasza Norberto hozzászólására (#348975)”


Összegabalyodott a rendszer? Nem Norberto-nak válaszoltam!
(#) trudnai válasza sszasza hozzászólására (») Jan 12, 2009 /
 
  1. //inic
  2. const rom char SZ1[]= {1,2,3};
  3. const rom char SZ2[]= {4,5,6};
  4. const rom char* rom SZ[]={SZ1,SZ2};


...de amugy attol fuggetlenul, hogy az SZ a RAM-ba kerul meg a pointer jo lesz... Tehat SZ[1][1] rendesen kihozza az 5-ot, le is szimulaltam es nalam jol mukodik!
(#) trudnai válasza Krisz03 hozzászólására (») Jan 12, 2009 /
 
Idézet:
„Ui: Mivel lehet megnyitni a honlapodon azt az PCB fájlt? ExpressPCB nem viszi.”


Eagle-lel probaltad mar?
(#) Noja hozzászólása Jan 12, 2009 /
 
Hali!

Megint én vagyok... (JDM unfan.... )
Naszóval, az lenne a kérdésem, h nem lehet átalakítani a szinteket valamilyen konverterrel úgy, h passzoljon az RS232-es szabvánnyal???
Csakmert 2 napi munkám van ebben a programozóban, és nincs szívem csak úgy félretolni az asztalom sarkára.
Amúgy sztem megveszem a PICKIT2-t úgyhogy a programozással nem lesz gondom, csak akkor legalább ezt fejlesszem tovább, h legalább használható legyen mások számáa is ez a kapcsolás...
(Ha hülyeséget írtam/kérdeztem, akkor bocsi...)

Köszi: Noja
(#) Krisz03 válasza trudnai hozzászólására (») Jan 12, 2009 /
 
Nem, mert ahhoz az "sch" és "brd" fáljok tartoznak (ezt a progit használom én is). Már kiderült, hogy a Circuit Maker fájljáról van szó.
(#) icserny válasza vizor hozzászólására (») Jan 12, 2009 /
 
Idézet:
„Gondolom a 7.776 Mhz vagy 4433.61 Khz-essel még nehezebb lenne”


Nem gond! A 7.776 MHz esetében csak annyi a különbség, hogy 243-at kell írni az előzőekben említett 250 helyett, ugyanis a 7.776 MHz a 8 MHz-nek pont a 243/250-öd része.
(#) sszasza válasza trudnai hozzászólására (») Jan 12, 2009 /
 
Köszönöm!
Kérdeznék még egyet. Hogyan kell ezt:
char A;
FSR0 = &A; //remélem érthető mit is szeretnék
(#) vizor válasza icserny hozzászólására (») Jan 12, 2009 /
 
Látom, nehéz téged megfogni Végül is gondoltam, hogy nem véletlenszerűen vagdossák azokat a kristályokat Megmondom őszintén, az is belejátszott a 8Mhz-be, hogy ha mint kezdőnek lassú a programom, majd a proci izomból kompenzálja. Találtam egy 100Khz-es és egy 3.2768 Mhz-es kristályt is, de ezeknél sokkal jobban kellene optimalizálni.
Következő: »»   386 / 1319
Bejelentkezés

Belépés

Hirdetés
XDT.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem