I have noticed that the Kiel compiler doesn't produce the correct interrupt vector if 8051 interrupt numbers are used. For example for external interrupt 0 (IE0), the interrupt number has to be 0, instead of 1 to produce a jump at location 1. Example:
void edge1 (void) interrupt 0{ /*produces correct code
while
void edge1 (void) interrupt 1{ /*produces wrong code
This is the case with all the interrupts I have used. My questions is what do you have to do to produce a reset vector? Reset is interrupt number 0 in 8051 numbering. Using -1 or 255 both produce a compile error.
True, it looks like 6 of one or half a dozen of another at first glance. To create a different startup file now you have to modify STARTUP.A51 or create a similar startup program. When your program is compiled a long jump to the entry point of STARTUP is placed at address 0. What I propose would still require writing an assembly language startup function. But the extern could also be an address in the processor's monitor space. While you can still do that with 2 long jumps by placing the extern in STARTUP.A51, that is not even crufty. The other reason for having RESET in the name space of the C program is to allow a soft restart of the program (without using the watchdog). Others have stated this is impossible, illegal or illogical because of stack issues but that isn't true. STARTUP initializes the stack pointer, etc then jumps to MAIN. C has traditionally been a language that lets the programmer do whatever he/she wants. Although not everyone agrees with that.
The problem with jumping for soft-start isn't just the stack. The problem is that the processor hasn't been reset so all peripherials can still be initialized and running.
STARTUP may initialize the stack but your first interrupt may happen before the stack has been initialized. Before jumping to the startup code, the application must - at least - disable interrupts. And the startup code (and everything from main() and forward) may also assume that it is a "normal" startup, where all peripherials have their boot-state defaults. Enabling interrupts globally without initializing the UART device may directly trig an interrupt for handling characters received since before the reboot.
It is normally better to have a processor with a watchdog and let the watchdog reset the processor. A check for reboot reason and memory state could then let the startup code decide if all memory should be cleared/initialized, or if it was an intentional watchdog reset with the intention to keep some state.
"The problem is that the processor hasn't been reset so all peripherials can still be initialized and running."
And, if the jump came from an ISR, the interrupt would never get cleared...
And, if the jump came from an ISR Why would anyone do that?? You can't make software tools bozo-proof.
"The NOINTVECTOR directive inhibits interrupt vector generation. This flexibility allows the user to provide interrupt vectors with other programming tools."
http://www.keil.com/support/man/docs/c51/c51_nointvector.htm
Surely that can be just as easily achieved with the existing arrangement?
I do not know, but the question "how to not return, but go to specific location after interrupt" comes up on a fairly regular basis. (according to you: from a bozo)
Erik
True, it looks like 6 of one or half a dozen of another at first glance.
Having read your last couple of posts all I can really say is that you seem to be trying to solve a problem that doesn't exist. Everything you want to achieve is already easily and cleanly achievable using the facilities provided by Keil except for one thing - you want to use existing C syntax to place a jump or call instruction at location zero in the code address space.
Either you're still a bit confused about the behaviour of some aspects of the toolchain or you've got way too much time in your hands.
That's the way it looks to me, too.
And me (but I thought that from the outset).
I believe software should use the same terminology that the chip manufacturers use. The 8051 is about the simplest micro I have used recently (others were DSPs, coldfire, and other 32 bit processors) but I find Keil's manuals and on-line documentation mostly don't supply the information I'm looking for. I have also gotten unreliable information from Keil tech support recently - I think the guy was guessing when he answered my question. So I tend to rely on the chip manufacturer's manuals. Keil's docs are good at explaining simple things but there is also a lot of ambiguous information.
I believe software should use the same terminology that the chip manufacturers use.
But whose terminology, among the dozens of 8051 manufacturers, would that be? And let's assume that they picked a different one than you're using --- how would that help you in any way?
But it has already been established that there is no standard terminology for this used throughout all manufacturers!
It has also been established that Keil followed Intel's lead on this - and Intel was the inventor and original manufacturer of the 8051. You can't get much closer to "the horse's mouth" than that! So, if anyone's got their terminology "wrong", it's those new, upstart "derivative" manufacturers...
"I find Keil's manuals and on-line documentation mostly don't supply the information I'm looking for"
That's because you're starting from a false assumption, and then trying to find stuff to back it up!
Keil very clearly and unambiguously define what they mean by "interrupt numbers" in the context of their proprietary 'interrupt' keyword.
As already noted, SDCC follows the same meaning; but it's open-source - so you could create your own version, if you wanted, that would work the way you like it...
"I think the guy was guessing when he answered my question"
Probably trying to guess what on earth you were on...
;-)
I don't know whether you get paid by Keil to be their shill or just have a lot of time on your hands but in any case there is no need for insults. If you didn't presume so much and were not always trying to come up with snot-nosed insults, you might learn a few things.
OK, sorry - that was a cheap joke.
Oh, for goodness sake, grow a thicker skin and grow up.
You've posted a ridiculous load of nonsense in this thread yet several people have made quite an effort find out what you're trying to do so they can offer you some useful advice. The conclusion is that the facilities to achieve what you want already exist, yet you are still adamant that things ought to be organised a little bit differently to suit you.
What a complete and utter waste of time.