12F629 :( Jbg, posao je posao

[InTheStillOfTheNight]

Baš imam nekakvo osobno gađenje prema PIC mikrokontrolerima, i baš mi ubodu projekt koji žele sa 12F629 jer ga očito imaju na lageru ohoho. I naravno samo sam prelistao datasheet i malo se zgrozio koliko je to zapravo "slab" MCU. Mislio sam da je trik u tome što košta par kuna, ali vraga, i AVR tiny košta isto par kuna, a neusporedivo je moćnije računalo, ako sam dobro shvatio.

Uglavnom i pišemo po ovom forumu da razmjenimo mišljenja, iskustva, po mogućnosti nešto naučimo, a ponekad i iz čiste dosade. Dakle, nisam čitao datasheet jer mi se stvarno neda proći tih 100 stranica u potrazi za informacijama koje me interesiraju, a predpostavljam da ih ekipa kao @pedja, @trax, @buco i ekipa PIC kuhara znau već napamet. Uglavnom ispravite me ako sam negdje nešto krivo shvatio iz 5 minutnog listanja datasheeta.

Dakle, to računalo ima HW stack dubine 8, i ne postoje asm instrukcije PUSH i POP nego na HW stack isključivo utječu asm instrukcije poziva funkcija, vraćanja iz funkcija i naravno pospremanje SP-a prilikom poziva interrupta. To mi se malo zgadilo jer je kod AVR-a stack čitav RAM, i kada govorimo o dubini onda govorimo o trenutku kada bi prepisali statičke variable u RAM-u. No ajde, mogu se nositi s time.

Onda sam pogledao TIMERE, zaključio da ih ima samo 2 što je OK. Jedan 8 bitni, i jedan 16 bitni. No kada sam malo bolje pogledao kako rade TIMER-i opet užas. Ako sam dobro shvatio, moguće je pozvati ISR samo na overflow. Odmah mi nedostaju moji dragi OCR registri AVR-a, no što ćeš moram se i s time nositi.

E sad što trebam napraviti:
Prvenstveno moram generirati PWM nosilac 38500 Hz, to bi na AVR-u napravio samim hardwareom TIMER-a, ali ako sam dobro shvatio PIC ne može hardverski promjeniti stanje nekog porta. Ispravite me ako sam u krivu. Moram biti na internom oscilatoru, a na oko sam negdje pročitao 4 Mhz. Onda sam malo računao da je to 1/4Mhz=250ns a overflow 8 bitnog TIMER-a će biti nakon 250ns*256=64us.

Dakle ako je overflow na 64us moram u ISR-u upisati početnu vrijednost TIMER-a kako bi mi radio overflow svakih 13.2us. Računao sam si dakle da svakih 13.2 us promijenim u ISR-u stanje PWM pina, što bi značilo da bi jedan period izbacio kroz 2 ISR-a po 13.2 i dobio zapravo PWM oko 38500 HZ.

Ovo je zapravo prvi dio posla koji moram napraviti da bih mogao nešto raditi dalje. E sad ono što me zanima:

Idem li uopće u dobrom smijeru sa idejom?

Isključuje li PIC nekakve globalne prekide kada dođe na vektor ili u ISR da se ne može dogoditi niti jedan drugi prekid?

Koje flagove ISR-a moram čistiti u ISR Timera?

Ima li kakvih BUG trikova i zaheba koje bih mogao napraviti iz HPL-a. Ovi hoće da im to pišem u C-u.

Imam instaliran MPLAB u njemu sam radio neke projekte za PIC, ali postoji li nešto što je bolje ili što se najčešće koristi?

Prvenstveno mi je najbitnije ovaj dio oko poziva ISR-a i vraćanja nazad jer me zanima kako je to odrađeno u HW-u PIC-a i što u SW-u ISR-a moram osigurati?

[trax]

Da, sve sto si naveo je tacno (nisam obracao paznju na izracunata vremena prekida...).

Ako budes pisao program u ASM-u onda moras rucno iskljucivati GIE prilikom ulaska u ISR (addr vektora 0x04) i onda interrupt-flag bit (TMR0IF, TMR1IF, ... zavisi koji brojac koristis) od tog svog timera. Na kraju prije RETURN omoguci ponovo GIE ili koristi RETFIE koji ce to uraditi za tebe.
Inace, kada se desi prekid, ti ucitas timer sa svojim offsetom da ti se ponovo generise interrupt za krace vrijeme od onog maksimalnog kod 8-bitnog, ili 16-bitnog timera (zavisi koji odaberes). Znaci da, pristup ti je dobar

Ja sam pisao u HI-TECH C jeziku koristeci MPLAB editor. Kod HI-TECH-a (ako ga budes koristio) u ISR rutini se sam iskljucuje GIE tako da o njemu ne moras voditi racuna, ali kada unutra obradis prekida tog svog timera, moras mu ocistiti flag-bit da ti uC ponovo ne uskoci u ISR rutinu kada se na kraju omoguci GIE.

Ne znam kako je rijeseno u HI-TECH C kompajleru uzastopno pisanje po GPIO registru (IO pinovi) ali kod PIC16F629 i 675 ima jedna caka (ili problem) a to je da ne mozes uzastopno dva puta upisati nesto na GPIO registar. Naprimjer ne mozes uraditi ovo:

bsf GPIO, 0
bsf GPIO, 1

...da bi upalio oba pin-a. U ovom slucaju, ako sam napravio dobar primjer, ce se odraditi samo prvi "bsf GPIO, 0" a drugi se nece izvrsiti ispravno. Trebas uraditi ovo:

bsf TEMP, 0
bsf TEMP, 1
movfw TEMP
movwf GPIO ; u jednoj instrukciji odradi vise stvari sa GPIO portom

...gdje je TEMP neki registar u RAM-u.

I da, ne zaboravi da se takt kod PIC-eva dijeli sa 4, tako da ako je oscilator 4MHz njegove instrukcije se obavljaju na 1MHz

[InTheStillOfTheNight]

Neću pisati u asm, ovi hoće c-source. Uf, baš si me usrećio sa ovim takt/4

Uopće nemam osjećaj hoću li stići sve odraditi što još trebam jer bi iz tog ISR-a nosilca trebao računati i realno vrijeme pošto će mi 16 bitni timer trebati za nešto drugo. No o tome ću kasnije razmišljati.

Dakle ako sam dobro shvatio, kada dođem u rutinu prvo ubijem globalne prekide, a nevažno je kada ću očistiti FLAG koji je pozvao ISR, bitno samo da je prije uključivanja globalnih i prije povratka iz ISR rutine. Uglavom, moram ga čistiti u SW-u ISR-a.

No sad mi jedna stvar baš nije najjasnija. Kada AVR skoči na vektor HW već isključi globalne prekide, i onda u trenutku skoka sa vektora na rutinu sigurno se ne može dogoditi nikakav drugi prekid jer su globalni isključeni od strane HW-a.

No što će se dogoditi sa PIC-om ako mu se podigne neki drugi ISR flag u trenutku kada se PC nalazi na vektoru ili kada tek treba izvršiti isključivanje globalnih prekida u ISR rutini? Što ako se podigne neki drugi FLAG prije nego li SW isključi globalne prekide?

Jel PIC ima samo jedan vektor za sve izvore prekida ili za svaki izvor po jedan vektor? To nisam isto uočio listajući brzinski datasheet?

[trax]

Dakle ako sam dobro shvatio, kada dođem u rutinu prvo ubijem globalne prekide

Pa ako budes koristio hi tech c kompajler, onda ce ti on sam iskljuciti globalne prekide, a ako ti tvoj kompajler ne bude to sam radio onda ces morati ti.

a nevažno je kada ću očistiti FLAG koji je pozvao ISR, bitno samo da je prije uključivanja globalnih i prije povratka iz ISR rutine. Uglavom, moram ga čistiti u SW-u ISR-a.

Da.

No što će se dogoditi sa PIC-om ako mu se podigne neki drugi ISR flag u trenutku kada se PC nalazi na vektoru ili kada tek treba izvršiti isključivanje globalnih prekida u ISR rutini? Što ako se podigne neki drugi FLAG prije nego li SW isključi globalne prekide.

Nisam potpuno siguran ali ce vjerovatno opet skociti na isr vektor pa ce tek onda iskljuciti globalne prekide. To su extremne situacije ali siguran sam da ti se taj problem nece javljati ili biti bitan. Zato prva instrukcija na adresi 0x04 treba da bude gasenje globalnih prekida pa onda ostalo.

Jel PIC ima samo jedan vektor za sve izvore prekida ili za svaki izvor po jedan vektor? To nisam isto uočio listajući brzinski datasheet?

Samo jedan, na adresi 0x04. Zato u isr-u moras da provjeravas koji je isr flag setovan da znas koji isr da obradjujes

Kucam ovo na telefonu pa se ispatih

[InTheStillOfTheNight]

Jbg @trax sorry što toliko detaljiziram, ali nisam navikao pisati software koji imaju potencijalni bug, zato si sve najprije detaljiziram u glavi pa onda pišem... I sad me svaki tvoj odgovor ponovno izbaci iz takta...

Kod AVR-a svaki izvor ima svoj vektor i vektori su poslagani od adrese 0, RESET_VECTOR, prema višim adresama. Tamo je situacija sasvim jasna, sa bilo kojeg vektora prvom instrukcijom skačeš na ISR rutinu jer ako na samom vektoru izvršiš neku instrukciju koja nije skok zapravo si već programski zagazio na neki drugi vektor.

Sad mi opet nije jasno kako je to kod PIC-a napravljeno jer ako je 0x04 adresa na koju će svi izvori uputiti PC kako onda na samom vektoru prvo isključuješ globalne? Zar ne bi trebao sa te adrese skočiti na ISR rutinu, ili sama ISR rutina počinje na adresi 0x04?

S koje adrese onda uopće starta PIC? Kako je to u FLASU složeno da adresa vektora bude 0x04, a ti na samom vektoru prvo gasiš globalne? Po tome mi ispada da bi se ISR rutina već razvukla i na naredne adrese iza 0x04 sve do kuda? Nije mi sad jasno gdje je glava i rep ISR-a? Sad sam tek totalno zbunjen...

Taj dio mi tek sada nije jasan...

[trax]

Neka te to ne brine jer ces pisati u C-u, a sutra cu sve odgovoriti kad sjednem za PC, satra me ovaj telefon

[InTheStillOfTheNight]

Moze, svaka pomoc je dobro dosla... Ne mogu si baš priuštiti da izbacim 100 ili više uređaja sa nekim divljim bugom koji se dogodi jednom u "nekada"... Malo je gadno kad pišem za veće serije, a kad bi se to moralo vraćati nazad doslovno mogu sahraniti projekt sa totalnom neprofitabilnosti...

[trax]

Kod AVR-a svaki izvor ima svoj vektor i vektori su poslagani od adrese 0, RESET_VECTOR, prema višim adresama. Tamo je situacija sasvim jasna, sa bilo kojeg vektora prvom instrukcijom skačeš na ISR rutinu jer ako na samom vektoru izvršiš neku instrukciju koja nije skok zapravo si već programski zagazio na neki drugi vektor.

Kod microchipa, barem ovog malenog, imas samo 2 vektora. Prvi je 0 (reset vektor) a drugi je 4 (ISR vektor). Kada on starta, imas 4 dostupne lokacije da napises GOTO MainProgram gdje pocinje tvoj program. Na adresi 4 mozes staviti GOTO Isr ili tu poceti pisati ISR program. Ja bas tu pocnem pisati ISR program i prva instrukcija mi je iskljucivanje GIE bita. Sve ovo znaci da mi se MainProgram nalazi na vecoj adresi od ISR vektora. To ti je sva mudrost oko toga.

Sad mi opet nije jasno kako je to kod PIC-a napravljeno jer ako je 0x04 adresa na koju će svi izvori uputiti PC kako onda na samom vektoru prvo isključuješ globalne? Zar ne bi trebao sa te adrese skočiti na ISR rutinu, ili sama ISR rutina počinje na adresi 0x04?

Pa eto, ISR program zapocnes na samoj toj adresi, a glavni program kad zavrsis ISR rutinu. Tako se nista ne gazi.

S koje adrese onda uopće starta PIC? Kako je to u FLASU složeno da adresa vektora bude 0x04, a ti na samom vektoru prvo gasiš globalne? Po tome mi ispada da bi se ISR rutina već razvukla i na naredne adrese iza 0x04 sve do kuda? Nije mi sad jasno gdje je glava i rep ISR-a? Sad sam tek totalno zbunjen...

Tako je, ISR rutina se razvuce dokle je potrebno, a tek nakon nje ide glavni program.

Nekako izgleda ovako kao u attachmentu:

pic_flash.jpg

(27.99 KiB) Downloaded 10 times

Osim ove varijante, na adresi 0x04 mozes staviti i GOTO ISR pa napisati ISR negdje na kraju FLASH-a, ali tada prva instrukcija nije gasenje GIE-a pa je veca sansa za onom ekstremnom situacijom da se desi naredni interrupt prije nego sto je ovaj GOTO zavsrio pa uC opet skoci na 0x04 i nastavi skakati sve dok ne prestanu se desavati ti dodatni interrupti koji ga non stop vracaju na 0x04.

[trax]

Moze, svaka pomoc je dobro dosla... Ne mogu si baš priuštiti da izbacim 100 ili više uređaja sa nekim divljim bugom koji se dogodi jednom u "nekada"... Malo je gadno kad pišem za veće serije, a kad bi se to moralo vraćati nazad doslovno mogu sahraniti projekt sa totalnom neprofitabilnosti...

Ako govoris o onom bugu sa GPIO portom, to se ne desava "nekada" nego uvijek, i to ces odma primjetiti ako bude problema sa tim. Ovaj maleni PIC jednostavno tako radi sa GPIO portom. Zasto - ne znam.
Uredjaj kada istestiras ti ces odma znati sve bugove, jer nece se desavati nista sto ne napises u program

[trax]

Evo jedan primjer, osakaćeni:

Code: Select all

;***** Struktura programske memorije *****

		ORG			0x00	; Reset vektor
  		nop
  		nop
  		nop
  		GOTO		Init	; 

;***** Interupt rutina *****
		ORG			0x04	; Interapt vektor
ISR		bcf		INTCON, GIE	; onemoguci sve interupte za sad
		; sacuvaj registre
		movwf	temp_w		; sacuvaj W reg
		movfw	STATUS		; W=STATUS reg
		movwf	temp_status	; sacuvaj ga
		BANK0				; bank 0 za svaki slucaj. Dole ce se vratiti STATUS registar cijeli pa je ovo OK
		; da vidimo koji se to interrupt desio

		; RB0/INT ?
ISR_INT	btfss	INTCON, INTF; sensor activated?
		GOTO	ISR_TMR		; no, skip this
		bcf		INTCON, INTF; clear!

		; ovdje se obracuje INTF interrupt...
		; nop bla bla

		GOTO	ISR_TMR		; don't do anything, check another interrupt type

ISR_TMR	btfss	INTCON, T0IF; tmr0 overflow?
		GOTO	ISR_Exit	; no, skip this
		bcf		INTCON, T0IF; clear!

		; ovdje se obradjuje TMR0 Overflow interrupt...
		; nop bla bla

		; nema se vise nijedan provjeriti, pusti da izadje:
		;GOTO	ISR_NEKI_TRECI		; don't do anything, check another interrupt type

ISR_Exit					; vrati varijable i vrati se sa retfie
		movfw	temp_status	; w=temp status
		movwf	STATUS		; STATUS=W
		movfw	temp_w		; i konacno W
		RETFIE				; vracamo se...

;***** Inicijalizacija uc-a *****

Init	clrf	INTCON		; svi prekidi onemoguceni
		BANK1				; bank 1 zbog option i tris
		movlw	b'00000101'	; 
		movwf	OPTION_REG	; pullups on, TMR0 presc: 1:64, interrupt on FALLING edge of RB0/INT pin (NO type)
		movlw	b'11111011'	; TRISB
		movwf	TRISB		; [________]
		movlw	b'00010010'	; TRISA
		movwf	TRISA		; [xxx_____]
		BANK0				; bank 0

Idle		nop ; ovaj PIC ne radi nista...
		GOTO	Idle
		
		
		END

Ako se ikad budes pitao zasto su na adresi 0x00 rezervisane 4 lokacije radi onog GOTO MainProgram:

Code: Select all

	ORG		0x0000		; reset vektor
		bcf		PCLATH,	3	; 0x0000 --__ ( selektujmo    )
		bcf		PCLATH,	4	; 0x0001 --   ( PAGE0 Flash-a )
		nop					; 0x0002 'nako...
		GOTO	Init		; 0x0003 inicijalizacija uC-a

to je zato sto veci PIC-evi imaju PAGE-ove i na pocetku se moze vrsiti selekcija PAGE-a programa. PAGE-ovi su zlo, ali o njima ne brini jer radis sa 1kb PIC-em, a pogotovo jer ces raditi u C-u.

[InTheStillOfTheNight]

Hvala trax na uloženom vremenu, sada mi je gotovo sve jasno osim onih sitnih detalja oko podizanja nekog drugog ISR flag-a kada je PC na 0x04 i interrupti su još omogućeni. Nadam se da je na HW-u to sređeno jer nije bitno hoću li ponovno završiti na ISR vektoru kad i tako moram provjeriti tko je tocno pozvao prekid, nego mi je važno da HW ne zajebe stack sa guranjem PC-a, tj da PC pogura 2 puta na stack, a vrati ga samo jednom izlazom iz ISR-a.

Ako se dogodi ISR recimo TIMER0 overflow, a prošao sam provjeru flag-a za taj overflow greška se neće dogoditi jer nitko neće počistiti TIMER-ov flag, pa će ISR biti ponovno pozvan kada izađem iz njega i srediti dio oko rutine TIMER-a te obrisati flag timerovog prekida.

Mislim da sam dovoljno dobro skužio kako to funkcionira, a ovu sitnicu koja mi nije jasna probati ću pronaći u datasheetu, bitno da si mi objasio osnovne principe, a lako se ja kasnije snađem...

Ako bude kakvih novih pitanja ili odgovora oko ovoga svakako se javim...

Hvala i pozdrav

[_heX]

Ne znam otkud informacija da GIE bit treba brisati ulaskom u isr, on se brise automatski u hardweru (hi-tech picc kompajler ga niti ne pokusava brisati - vidi screenshot). GIE bit je obrisan prije no što se adresa povrata stavi na stack i prije no sto se program preusmjeri na 0x04.
Sto se tice dva sljedna upisa u port gdje se u biti izvrsi samo jedan upis jeste sigurni da se ne radi mozda o r-m-w "fenomenu".
@nocni
Obrati pozornost ako koristis interni oscilator. PIC12F629 tvornicki dolazi s kalibriranom vrijednosti koju treba upisati u OSCCON registar, ta vrijednost nalazi se na lokaciji 0x3FF kao retlw <value> (povratak iz funkcije s vrijednošću u WREG). Instrukcija call 0x3FF (vidi screenshot) poziva tu "funkciju" i umetnuta je automatski od kompajlera. Brisanje PIC-a briše i tu vrijednost, pa budi oprezan.
Vise o gore recenom mozete naci u datasheet-u (Special features of the cpu, 9.2 i 9.4)

[trax]

Ma da, RMW problem... http://www.mikroe.com/download/eng/docu ... lp/rmw.htm
Samo da obrati paznju na to
To mi se manifestovalo jedino kod 12F629 i 675, sto je mozda cudno ali je tako...

Sto se tice GIE-a, ja sam citav zivot bio uvjeren da se on ne cisti hardverski. Sad citam i vidim da ga svi smatraju ugasenim pri dolasku na 0x4 adresu

On interrupt, the processor clears the GIE bit thus inhibiting any further interrupts. The bit is again set on execution of the return from interrupts (RETFIE).

Wow...

[_heX]

To mi se manifestovalo jedino kod 12F629 i 675, sto je mozda cudno ali je tako...

Mozda je port kod tih kontrolera drugcije izveden pa je na pinovima visa kapacitivnost. Mada po datasheetu sve je kao i kod drugih - 50pF max.

[trax]

Vrlo moguce da je zbog toga.
Bitno je da obrati paznju u radu sa GPIO portom (iz mog iskustva pogotovo kod ovih malih PIC-eva) da ga ne boli glava.

[grunf]

ma moram se ukljuciti u diskusiju, ali samo da kazem da je ogromna steta sto Vi niste barem asistenti na fakultetu, jer samo ovakava prakticna znanja mogu pomoci studentima poslije....nadam se da me razumijete...

[InTheStillOfTheNight]

Meni je isto potpuno logično da HW ubije globalne prekide prije nego li u PC upuca 0x04. Uzmimo dakle ovu stvar zdravo za gotovo... Sve jasno

Sad još samo moram smisliti čaroliju kako na 1Mhz FLASH instrukcija izvesti sve u ISR-u što trebam i tamo dolaziti svakih 13.2 us, a da ne zakoljem MCU... Ispada da imam samo nekoliko asm instrukcija na raspolaganju jer mi se čini da je ova solucija na internom oscilatoru gotovo vremenski neizvediva

Ma grunf ne bi nas shvacali ovi na fakultetu, nije to za njih.... Oni su procitali sve porno magazine, ali nisu jebali...

[trax]

Ma grunf ne bi nas shvacali ovi na fakultetu, nije to za njih.... Oni su procitali sve porno magazine, ali nisu jebali...

[InTheStillOfTheNight]

I naravno, podesim MPLAB, HI-TECH compiler, sve osposobim, napišem kostur programa i uzmem ICD3 i nikako ne mogu instalirati drivere za WIN7 64bit...

I prekopao čitav google ideja od kojih brdo ljudi ima isti problem ali niti jedno rješenje mi ne radi... Jel tko dizao drivere za ICD3 na WIN7 64 Bit?

[trax]

Nazalost sa ovim ti ne mogu pomoci. Valjda jos neko cita pa neka se ukljuci...