how to use the interrupt keyword in 8051 C code.

Johnny,

Not to be overly pedantic, since you clearly know your stuff, but the Intel MCS-51 manual always refers to the fixed priority-arrangement among interrupts that are enabled and whose IP registers settings match as a "polling" order.

The "bible" says something to the effect of the interrupt flags being latched on S5P2 of each machine cycle and then "polled" in a fixed order on the next to determine which interrupt is "accepted."

Johnny,

Not to be overly pedantic, since you clearly know your stuff, but the Intel MCS-51 manual always refers to the fixed priority-arrangement among interrupts that are enabled and whose IP registers settings match as a "polling" order.

The "bible" says something to the effect of the interrupt flags being latched on S5P2 of each machine cycle and then "polled" in a fixed order on the next to determine which interrupt is "accepted."

The interrupt flags are not actually polled (as in checked one by one) but sampled by the hardware. It will - in parallell - sample all interrupt flags to make it's decision which interrupt to take.

Thanks to all of you for your answers. But i need a simple answer for: what does that "using 2" does?

http://www.keil.com/support/man/docs/c51/c51_le_funcdecls.htm

http://www.keil.com/support/man/docs/c51/c51_le_regbankspec.htm

Not only is the answer in the manual. The answer is also more or less implied by one of the answer posts you have received.

As Jason Daniel noted, the 80C51 hardware manual refers to the interrupt servicing order inside a given priority set as polling.
The manual description states that the interrupt source is decided upon a 'priority within level', and the vectoring is done in the next S5P2 after the sampling of the interrupt flags.
That really does not seem to be a polling operation, but a priority encoding operation, that essentially is a chained logic evaluation done by combinatorial logic, instead of sequential logic. Actually, both are very similar operations, but the difference is not subtle.

Polling is a term that refers to a synchronous sequential interrogation of devices, like for example of a network master that interrogates all slave devices on the network for data to exchange.
It is described in many instances as a sequential operation applied in software as opposed to a hardware 'parallel' priority encoding. It could also easily be done in hardware, using sequential logic or state machines, but it is actually much more expensive to do polling in hardware with several flipflops than it is to do a simple priority encoding with a few logic gates.

That's why I think that the intra-priority vectoring of the 8051 is actually a combinatorial logic operation, rather than a clocked sequential logic, in which case the use of the term 'polling' by the documentation was an unfortunate choice of term.

But I must declare that I have not seen the actual implementation of the original 80C51 core, so I am only stating my opinion based on common sense.

As Jason Daniel noted, the 80C51 hardware manual refers to the interrupt servicing order inside a given priority set as polling.

I think y'all have confoosed the OP TOTALLY.

He asked about 'using' and have gotten answers about priority.

Now, I am not one to releieve anyone from reading the manuals, and usually wouldd not answer this directly instead of posting Please read the manual, but the above answers compel me to do so.

using direct the compiler to use the specified register stack, if you do not know what a register stack is Please read the manual.

Erik

And the OP did get an answer to that question.

Jonny Doin immediately answered: "Hint: the 8051 has 4 core register banks at the base of data RAM."

Oll Klear, we are abusing of the OP.

As Erik clarified, using directs the the compiler to use a specific register bank for the function, as opposed to use the current default bank.

Use of a specific bank for the interrupt handler may reduce the interrupt latency and code size, under some circunstances. It saves 30 instruction cycles from the entry/leave code of the handler.

You must read about and understand the interactions among NOAREGS/AREGS, USING, ONEREGBANK and REGISTERBANK directives if you are going to use register banking.

If you are compiling with USING, watch out for any functions being called from the function declared with a specific register bank, because the compiler cannot detect bank mismatch, and your program can go haywire because of this.

Thanks a bunch to all you Masters...

My query is now answered. Kindly do not think that anyone is abusing the other. You all have been kind enough to post the answers.

Hats off to you guys.

A short intro of mine.

I am a embedded hardware design engineer for automotive electronics working at Infosys Technologies LTd, India. Working on electronics and circuit design, i wanted to try my hands on the software part of it.So I am trying my hands on Philips P89C51RD2BN uC on a evaluation board. Trying to learn each peripheral one by one. I have written a driver for the UART as of now. AM planning to write all drivers first and then write a mini RTOS for my kit.

If you GURUs can guide me in my voyage to master the art of programming the hardware. I would be realy grateful to you.

Best Regards,
Mrunmoy.

"guide me in my voyage to master the art of programming"

Fundamental to this is a thorough reading of the Manuals for the tools, and the Datasheets for the devices.
You cannot hope to get anywhere by skimping on these.

I have written a driver
I hope this is language confusion. If you are working from a book that talks about 'device drivers' either switch to another processor or throw the book away.

however if what you mean is "I have succesfully done output and input" cudos to you

Erik

"AM planning to write ... a mini RTOS for my kit."

Writing an RTOS is not a project for a novice!

You need to develop your basic firmware skills before you start thinking about RTOS! :-0

"and then write a mini RTOS for my kit."

An RTOS for the 8051 is far from simple.

This is a recurrent theme for developers. It's a worthy one, but you should probably first acquire some background on realtime processing distribution theory.

The design task of distributing the processing units of a given system is not simple, and any architecture has its compromises. You have to put the compromises and limitations of your particular platform in perspective before blindly taking a design path.

Pseudo-multitasking is used in all serious realtime embedded systems, implemented in many forms. Amongst the many architectures, you can pick a cooperative multitasking approach versus a preemptive RTOS, or multithreading RTOS.

A cooperative multitasking system can be very easily produced, and depends only on the architecture of your single C program, not to mention that a well designed coop loop is always faster than any RTOS-based app.

An RTOS, on the other hand, must provide an individual runtime environment for each running thread. This involves a massive retargeting of the CLib routines, possibly a re-implementation of many of them, and a significant amount of context saving/restore for the thread context switch, not to mention that it requires significant amount of RAM only to maintain the state of each thread. A 'real' RTOS, even when based in a nanokernel, will eat a significant share of your available processing bandwidth, depending on the processor platform. IMHO, in the 8051 specifically, this amount is prohibitive. In my experience, I never used or saw a decent RTOS that was clearly superior to a well balanced mixed coop/interrupt approach for a real product.

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

"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.