On 9/14/05, Olin Lathrop wrote: >=20 > Sean Schouten wrote: > > TEMP_W EQU H'0020' ;Place to dump W-Register in case of > interrupt. > > TEMP_STATUS EQU H'0021' ;Place to dump STATUS-Register data in case > of interrupt. >=20 > Bad idea to put variables at hard coded addresses. This will get you into > trouble when moving code from PIC to PIC. There is another way; other than hard-coded memory addressing? You would=20 make me happy by pointing me to an example.=20 Also if TEMP_W is supposed to be > where W gets saved on interrupt, this will not work on PICs that have mor= e > than one bank. Ah, why is that?=20 > ORG 0x00 >=20 > Absolute mode is for bacwards compatibility with old crufty code. It=20 > should > not be used for new code. Now is the right time to learn to use the linke= r > and relocatable code, before you accumulate an existing code base. >=20 > And no, I don't want to hear how you want to do just this one example in > absolute mode, then you'll switch. What will happen is there will be a > minor tweak on this one, then a little more, then a new project you want= =20 > to > get into and not spend the time, etc, etc. It's like drugs. When it comes > to absolute mode, JUST SAY NO! How do I not use 'absolute-mode' in this case? I am more than willing to sa= y=20 no... My code might not be the best of code, but if every one keeps on=20 commenting like this, it will one day be supperb code! :*-) Oh, I should=20 mention that I got that out of my PIC book too! (PIC in Practice) > GOTO START ;Standard Operation >=20 > This may work on your particular PIC, but will fail on a PIC with more=20 > than > one code page where START ended up not on page 0. Get in the habit of > thinking about PCLATH now. I shall look into PCLATH!=20 > ORG 0x04 > > GOTO ISR ;The Interrupt Service Routine (Called in > case of an Interrupt) >=20 > First, this won't work on PICs with more than one code page. Second, it's > silly to put the ISR elsewhere anyway. Something will end up here, and it > might as well be the interrupt service routine. Consider it done!=20 > INITIALIZE > > BSF STATUS, RP0 ;Go to BANK 1 >=20 > Only on PICs with two banks. Otherwise this goes to bank 1 or bank 3. >=20 > Manual bank setting is a bad idea, especially when the state of some bank > bits is assumed. You insert new code above here and something below=20 > breaks. > Beginners can use BANKSEL. Once you're comfortable with that, I can show > you more sophisticated ways of setting the bank. BANKSEL it is. I will get back to you on that more sophisticated way though= ! > ; Set OSC to 31kHz > > MOVLW 0x03 > > MOVWF OSCCON >=20 > Doesn't this do more than just select the oscillator frequency? No.=20 > ; Set prescaler to devide clock by 256 > > MOVLW 0x07 > > MOVWF OPTION_REG >=20 > Same here. I'm pretty sure the option register controls more than just a > prescaler. Well, that's all I needed it to do. Are you implying that I must change the= =20 way I comment it? > BSF INTCON, GIE ;Set the General Interrupt Enable bit to 1. > > BCF INTCON, RAIF ;Clear the PORTA interrupt flag. >=20 > This is out of order. Turning on GIE is the last thing you should do in= =20 > the > interrupt setup. I thought that GIE had to be turned on in order to enable interrupts in=20 general. If that is not the case, then the datasheet doesn't make too much= =20 sense to me. "PIC in Practice" also enables the GIE in their example,=20 although they do not state anything about IOCA. /Me is confused. > ISR > > ; First things first (I have my reason) >=20 > That is a totally useless and unprofessional comment. I know and my excuse is that I wanted to explicitly store everything in=20 bank1 because all the "hard-coded" memory locations where thought up withth= e=20 idea of them all being in bank1 in the back of my head. > BCF STATUS, RP0 ;Go to BANK 0 >=20 > Very bad. You just trashed the bank setting on the foreground code. >=20 > > ; Backup the STATUS-Register >=20 > But you already trashed it above. I figured that!=20 > ;### Begin ISR code: ### > > ; Turn LED on and keep it in that state for 5 whole seconds. > > BSF PORTA, 1 ;Turn LED on. > > CALL DELAY1S ;Delay for 1 second. > > CALL DELAY1S ;Delay for 1 second. > > CALL DELAY1S ;Delay for 1 second. > > CALL DELAY1S ;Delay for 1 second. > > CALL DELAY1S ;Delay for 1 second. >=20 > This will take the processor completely out to lunch for the whole 5 > seconds. It's a bad idea to put delays, especially long ones, in the > interrupt routine. There may be some specialized structures where this > makes sense, but that is something you should only do after being=20 > completely > familiar with the machine and the reasons for doing so. >=20 > Also, you don't turn off the LED after waiting the 5 seconds. I know I do take the CPU out of the whole 5 seconds, and I also know that I= =20 have to find another way so the CPU stays kind of available. I just dont=20 quite know how to go about it yet other than my suspicion of it involving= =20 interrupts? There's undoubtedly more below, but I've had enough for now. Thanks anyway, I shall see what I can do about getting it all fixed before= =20 we continue this dialog. Sean. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist