Sean Schouten wrote: >> 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 > make me happy by pointing me to an example. Read up on the RES directive. >> Also if TEMP_W is supposed to be >> where W gets saved on interrupt, this will not work on PICs that have >> more than one bank. > > Ah, why is that? Because the bank is unknown on entry to the interrupt. You either have to reserve the same offset in each bank or put TEMP_W in the global area mapped to all banks on some PICs. > How do I not use 'absolute-mode' in this case? You use the linker. Other will have to tell you how to set up a relocatable project. I use external build scripts. My PIC development environment is at http://www.embedinc.com/pic, although that will be a bit overwhelming to you at this stage. > Oh, I should mention that I got that out of my PIC book too! (PIC in > Practice) So screw the book and stick to common sense and the data sheet. >> ; Set prescaler to devide clock by 256 >>> MOVLW 0x07 >>> MOVWF OPTION_REG >> >> 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 way I comment it? Yes. >> This is out of order. Turning on GIE is the last thing you should do in >> the interrupt setup. > > I thought that GIE had to be turned on in order to enable interrupts in > general. If that is not the case, then the datasheet doesn't make too > much sense to me. "PIC in Practice" also enables the GIE in their > example, although they do not state anything about IOCA. /Me is > confused. I didn't say not to enable GIE, only to do it last. You cleared some interrupt conditions after enabling GIE. If those interrupt coditions were previously set, you would have gotten an interrupt right there. That's why its best to make sure the whole interrupt system is set exactly the way you want it and all interrupt conditions initialized to off, THEN set GIE. >> That is a totally useless and unprofessional comment. > > I know and my excuse is There is no exuse. > I know I do take the CPU out of the whole 5 seconds, and I also know > that I have to find another way so the CPU stays kind of available. I > just dont quite know how to go about it yet other than my suspicion of > it involving interrupts? Why not a simple polling loop with not interrupts at all? That should be less to chew off initially too while you get familiar with PICs. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist