On 9/13/05, Howard Winter wrote: >=20 > Sean, >=20 > On Tue, 13 Sep 2005 12:50:03 +0200, Sean Schouten wrote: >=20 > >...< > > I think that the problem is down to me doing something absurdly wrong i= n=20 > my > > assembler code >=20 > Indeed - several "somethings" ! :-) Nooooooo! Don't blame the newbie for having to learn the ropes!=20 > although I have no clue to as what it possibly could be. >=20 > Well the flow of your program has so many errors that it's too early to= =20 > debug the Interrupt part. You need to > look at the whole program flow (perhaps draw it out in some sort of=20 > diagram) and get that sorted out first I shall re-submit a "clean-er" version, taking in concideration all the=20 comments made in conjuction with the messy sandwich I submitted earlyer=20 today! > CALLed routines with a GOTO at the end (eg. INITIALIZE) Why is that such a bad thing other than it screwing the mind of whomever is= =20 trying to read through what they think is a "normal" program flow? And the thing that still puzzles me: you seem to be using the Timer 0=20 > special function register (TMR0) as if > it was an ordinary memory location, doing your own count-down timer in a= =20 > loop. This can't be right - either > use the hardware timer, or if you are going to do it yourself, use a=20 > general purpose register to do the > counting-down. You are also saving and reloading TMR0 in your ISR, which= =20 > seems a strange thing to do, since > normally it would be a free-running counter, and what you are doing would= =20 > confuse things terribly if you were > actually using Timer 0. Believe it or not; I copied that 1 on 1 out of a pic-programming book calle= d=20 "PIC in practice", which I might note is regarded quite highly by whomever= =20 write reviews about it on Amazon.com , which would also= =20 explain the reason I bought it in the first place. By the way (about the=20 countdownloop with TMR0); Don't I need to be able to use interrupts if I=20 want to use TMR0 like it is supposed to be used (overflow...)??? In the ISR your save and restore code needs looking with regard to status= =20 > changes resulting from > saving/restoring other registers (clue: look at the way others do it,=20 > using SWAPF) I shall do so!=20 > I first suspected it having something to do with me trying to have a=20 > button > > connected to RA3 trigger an interrupt whilst utilizing other RA-ports t= o > > flash a couple of LEDs. >=20 > (Terminology point: "Port" is a collection of pins associated with a data= =20 > and a control register - you mean > "other RA-pins" above, I think). sorry! I was thinking network 'ports' eg port 80 ... My bad.=20 > I proceeded to only flash LEDs on PORTA in the > > Interrupt Service Routine; but they just never flashed=E0 I don't think= =20 > that > > me pushing the button generated an interrupt! >=20 > You aren't flashing the LED in the ISR in the version you posted. Yeah, I was kind of in the middle of trying something else when I posted=20 this code. I must admit that it's funny to read some of the remarks I get= =20 about this sloppy code of mine. Oh well... it's all in the name of=20 improvement! And if I ever feel down, remind me to post more sloppy code=20 because this is just fantastic! :-D It's not obvious to me what you are doing to get an interrupt triggered - i= t=20 > looks like you're expecting an > "interrupt on change", but you are changing the port yourself by flashing= =20 > the LED - I don't know if this would > work, but it sounds really dodgy! You are also setting one pin to analog= =20 > mode - you don't say why, and I'm > not sure what effect that will have on "interrupt on change" but it looks= =20 > an odd thing to do. Ah, that is because there is a potmeter connected to that port and I was=20 planning to work with that and the A/D converter after I manage to get=20 interrupts going.The Pic is on my PicKit1. Oh, I wasn't too sure about=20 changing the port by flashing the led with the "interrupt on change" thingy= .=20 But I figured that there is a way around that... I suspect IOCA? Incidentally, your "BANK 0:" definition was appended to the comment line=20 > before it, but that may have happened > in transit - but check it anyway! >=20 > Your commenting shows all the hallmarks of someone who is new to=20 > programming:=20 Your reading me like a book. Oh, that 302 error was bugging the hell out of= =20 me; I only felt satisfied after I called it inferrior. Your comments sometimes don't match what the code is doing (which should be= =20 > a hanging offence :-) for example: > ; Make RC0 & RC 3 inputs. > MOVLW 0x09 > MOVWF TRISA >=20 > A no-comment example later on, your delay routine: >=20 > DELAY1S > CLRF TMR0 > LOOPY > MOVF TMR0, W > SUBLW 0x0F > BTFSS STATUS, Z > GOTO LOOPY > RETURN >=20 > I had to work out what repeatedly subtracting 0x0F starting from zero=20 > would do - it turns out it gives 3840 > loops before giving a zero result - you should explain that (because=20 > nobody else knows that and you won't > remember it in future either). BUT! You aren't actually doing that at all= =20 > - you are reloading the same value > on each loop, so 0x00 - 0x0F will give the same result every time which= =20 > will never be zero... you're stuck > there! >=20 Okay, commenting either needs some working on. I think that I changed that= =20 value in the first example without 'updating' the commenting. Again real=20 sloppy.=20 The second example (delay) does not get stuck in the loop because of me=20 reloading the same value into the timer over and over again. I am guessing= =20 that the propper way would be to write a value to TMR0 and wait for it to= =20 overflow? How would I go about sensing the overflow without using=20 interrupts? Thanks, Sean. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist