Interrupt numbering

But it doesn't really give any true advantage, compared to writing a "normal" startup file in assembler. The end result is still a need to either have the end user write startup code in assembler, or have the end user accept a standard startup file.

ARM did think outside the box, when they designed the Cortext to allow everything to be written in C. The vector table contans the address of the startup function (in C), and the startup address and size of the stack. And there is no need for any special keyword for interrupt handlers, since the core handles the entry/exit magic and calls a standard C function.

But it doesn't really give any true advantage, compared to writing a "normal" startup file in assembler. The end result is still a need to either have the end user write startup code in assembler, or have the end user accept a standard startup file.

ARM did think outside the box, when they designed the Cortext to allow everything to be written in C. The vector table contans the address of the startup function (in C), and the startup address and size of the stack. And there is no need for any special keyword for interrupt handlers, since the core handles the entry/exit magic and calls a standard C function.

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?

And, if the jump came from an ISR
Why would anyone do that?? You can't make software tools bozo-proof.

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.