We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi, I encountered the following phenomena during my work: I dont know if its supposed to be this way but I'm sure it made me a lot of trouble. I had a working program and I built a bootloader for it.The interrupts were inside the bootloader (never mind the details..) but what's important is that it was made out of one C file. The interrupt handlers were written before the interrupt function themselves since there was no prototype function. What happened is that everything went crazy and the interrupts didn't work right...THE PROBLEM was that the compiler didn't add the save\restore PSW assembly code in the interrupt function for some reason. Any explanations or a is it a bug?
Without knowing what your code looks like: How would the compiler know which functions represented interrupt handlers?
Hmmm.
Never seen this as a bug. I have seen it as a bug in the program that was compiled.
Jon
but what's important is that it was made out of one C file. That's almost certainly not important.
The interrupt handlers were written before the interrupt function themselves since there was no prototype function.
No idea what you mean by interrupt "handler" versus interrupt "function", but I suspect you got this backwards. And that's before we start to consider that this an 8051, so there should not usually be any such distinction. Keep interrupt service routines short. Typically they should not have a need to call any other functions.
That set aside, you should never go without prototypes. You won't have to worry about function ordering in the source file, nor about a lot of other nasty things.
What happened is that everything went crazy and the interrupts didn't work right Sorry, but you'll have to do better at describing the problem. What exactly happened? And what exactly did that source code look like?
since this therad is about ISRs That set aside, you should never go without prototypes. You won't have to worry about function ordering in the source file, nor about a lot of other nasty things. I have never prototyped an ISR, is there something I'm missing?
Erik
I bet you have not had both "interrupt handlers" and "interrupt function" in your code.
The sentence "The interrupt handlers were written before the interrupt function themselves [...]" indicates that there are things going on that we don't know about - and will not, unless actual code is posted.
did you use the option interrupt setting in the function deficlarations?
We are still waiting for the answer to my question "How would the compiler know which functions represented interrupt handlers?"
"How would the compiler know which functions represented interrupt handlers?"
Ok, there is no simple sample - the simpliest one is your project - just look into generated HEX files. I don't understand what is so unclear in text.
Espessially if you are using banked from 0x8000 to 0xFFFF (which implies that the common area is from 0x0000 to 0x4FFF).. Each HEX file will also have the code bank code from 0x8000 to 0xFFF."
and If you use separate EPROMs for the common and bank areas, first pick one of the HEX files (it doesn't matter which one) and program the COMMON EPROM using the data from 0x0000 to the end of the common area. with the ISR in the COMMON or the banked?"
looked at the map and i hope it will be clear?
sorry.
i replied with the wrong forum!
It's not an option; it is essential - otherwise the tools will not generate the necessary code for an interrupt handler...
"is there something I'm missing?"
No.
C51 prohibits calling interrupt functions directly - so there would be no point in having a prototype...
See: http://www.keil.com/support/man/docs/c51/c51_le_interruptfuncs.htm (3rd bullet point at the bottom of the page)