This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

how to use the interrupt keyword in 8051 C code.

Hi,

There is an application note on using the interrupt vectors in C51 c programming for 8051. It goes like this-

unsigned int int_count;
unsigned char second;

void timer0 (void) interrupt 1 using 2
{ if (++int_count == 4000) { /* count to 4000 */ second++; /* second counter */ int_count = 0; /* clear interrupt counter */ }
}

Can anyone explain what does that "using 2" at the end of the function denote?

I understand that interrupt 1 specifies that this is the ISR for interrupt number for timer0 overflow at adress 000Bh. Does the last keyword "using 2" denote the polling priority of the interrupt?

TIA,
Mrunmoy

Parents
  • An RTOS for the 8051 is far from simple. and the architecture of the '51 makes the overhead horrendous. The '51 probably is the single most awful choice for a multitasking OS.

    you say you are a novice, did you get a book by some PCidiot "you must have device drivers, you must have an OS, you must screw up your system"?

    DO NOT confuse small embedded with "PC programming"

    Pseudo-multitasking a.k.a. the workloop, I hope.

    Erik

Reply
  • An RTOS for the 8051 is far from simple. and the architecture of the '51 makes the overhead horrendous. The '51 probably is the single most awful choice for a multitasking OS.

    you say you are a novice, did you get a book by some PCidiot "you must have device drivers, you must have an OS, you must screw up your system"?

    DO NOT confuse small embedded with "PC programming"

    Pseudo-multitasking a.k.a. the workloop, I hope.

    Erik

Children
  • "the architecture of the '51 makes the overhead horrendous. The '51 probably is the single most awful choice for a multitasking OS."

    Agreed totally. Interestingly, the 'banked' core registers are described in the Intel original datasheets as to be designed for easy context switching for a multitasking system. Of course, it takes much more than a cpu context switch to do multitasking. One of the reasons why all '51 RTOSes suck is that the full context switch is sluggish when compared to the same '51 core running a light event-driven loop (or workloop, as Erik mentioned). And the memory overhead taken by the true-reentrant code needed by thread-safe library is absolutely prohibitive when compared to the heavily overlaid memory of a single thread system.