Hi, can someone help point me in the right direction. I have a simple program that takes push button inputs and then sends them by IR led link to a receiver. It uses the printf function to drive the LED and the KBI on P0 for the p/button inputs.
The program compiles ok and the printf works if I do a printf("rtrt") just before entering the main loop where the program is supposed to sit until a KBI is detected. Problem is I cannot trigger the interrupt. Additionally, I get an L16 'unused code, ignored for . . . etc' message for the interrupt service routine. So, I think that the compiler or linker is not seeing the isr. I don't think its a hardware issue. I've checked wiring and voltage level changes on the P0 pins.
Any thoughts on this?
thanks
Jason
E.G. ince the KBD int can kick the uC out of sleep it is a LEVEL interrupt. Thus you must set the match to whatever the keys read when entring the ISR or you get an eternal interrupt.
You need to read the KBD ISR description in the datasheet 47 times or so to get it.
Erik
good point - because one of the things I want to do is put the micro into power down mode
I think I've picked up enough tips here to re-structure the program.
Thanks
A question relating to PCON. If I put the micro into total power down, I assume this is the same as executing some type of 'halt' instruction - so the stack pointer, instruction fetch etc are all preserved. I then generate a KBI by pushing a button, and the micro exectutes the isr and after reti goes to the next statement after the total power down mode statement. The User Manual is not clear on what happens after wake-up (unless I missed it).
Long time since I worked with the 8051, but yes - the common way for processors to implement power save is that they sleep until a wakeup event. Then they perform the interrupt and then continue with the next instruction.
To continue to sleep, you would have to do something like:
for (;;) { sleep(); // sleep until interrupt or reset if (should_wake_up_permanently) break; if (have_a_command) { handle_command(); } }
Note that depending on processor architecture and debugging interface, JTAG dongles etc may not support sleep mode, so in some situations, you may have to conditionally remove the sleep command in debug builds, unless you just debug in the simulator.
Note that this has nothing to do with Keil - it is purely a hardware feature of the specific chip.
"If I put the micro into total power down, I assume this is the same as executing some type of 'halt' instruction"
Never assume - always check in the Datasheet.
The datasheet will document precisely what is and is not preserved in the various "low power" modes available on the specific chip.
IIRC, "total power down" does exactly as the name suggests; so nothing is preserved - getting out of "total power down" is equivalent to a Reset. If you want anything preserved, you will have to use one of the other "low power" modes - the less-than-total powerdown ones! Again, check this in the Datasheet.
I think there's an NXP app note that illustrates this?
I have made the changes to the code suggested by everyone above
1. Prinf command is moved to a function which is called in main() 2. isr prototype declaration is removed 3. The isr is short and only inserts a small delay and then saves PO to an extern variable called 'command'
The problem I've got is when I compile I get the following error during the linker process:-
L16 -uncalled segment segment keypad_isr
So, the compiler is not recognizing my isr, and thats the reason I cannot generate an interrupt I believe. I cannot move onto the next stage of debugging until I resolove this. I wrote another small program about 1 year ago using the KBI, and that works perfectly, so I hav e got this right before.
Has anyone got any ideas on this?
I have overcome the error message above. In the Options for Target window on the C51 tab, I have had to tick the 'Interrupt Vectors at Adrress '0x0000'. There is no erro message when I compile now. But, the processor is still not responding the keypad.
Why does the ISR contain a delay??
Delays in ISRs are seldom a good idea...
Its part of the debounce. I've used it on a previous program with no ill effects.
But I don't think this is reason th e micro is not servicing the interrupt. I'll take another look at the hardware larter today.
nice to c some revent information on following web pages. microcontroller51.blogspot.com/ and see also http://picinf.blogspot.com/