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
  • So, I should take 8051 and understand its software architecture in C first.

    I believe its not a big deal to work on any microcontroller based designs. Because, if you do one design from starting to end. Its just the same in all others. The only things that we should keep in mind are the design checklists. I mean, personally I think that given a concept, I can prototype it with the right choice of micro and it depends a lot on the requirements of the customer.

    The datasheets and application notes give it all that is required to design. And the best part are the people like you who are ready to provide help on concepts online.

    Thanks, thanks a lot for all your concepts and discussions in this thread that i posted. I wish I could meet such seasoned technical people like you and get some good tips for design. That would give me more confidence on myself.

Reply
  • So, I should take 8051 and understand its software architecture in C first.

    I believe its not a big deal to work on any microcontroller based designs. Because, if you do one design from starting to end. Its just the same in all others. The only things that we should keep in mind are the design checklists. I mean, personally I think that given a concept, I can prototype it with the right choice of micro and it depends a lot on the requirements of the customer.

    The datasheets and application notes give it all that is required to design. And the best part are the people like you who are ready to provide help on concepts online.

    Thanks, thanks a lot for all your concepts and discussions in this thread that i posted. I wish I could meet such seasoned technical people like you and get some good tips for design. That would give me more confidence on myself.

Children
  • Dear All,

    If you do not mind then I would like to have your contact details, so that i can post my questions to you directly.

    Jonny Doin
    Jason Daniel
    Per Westermark
    Andy Neil
    Erik Malund

    Kindly provide me your details.

    Best Regards,
    Mrunmoy.

  • I believe its not a big deal to work on any microcontroller based designs. Because, if you do one design from starting to end. Its just the same in all others
    what a load of CRAP.

    If you are one of the best at the PIC and get thrown into a '51 design, your firts attempt will, at best, be mediocre.
    That said, there is nothing hindering that you can, eventually, become proficient in both.

    Erik

  • If you do not mind then I would like to have your contact details, so that i can post my questions to you directly.

    and deprive all other members of the information?

    discussing through a forum has many purposes, let me mention two
    1) others may pick up valueable information. I have learned much by seing information posted I was not aware of and did not even think of asking about. e.g. I have picked up a technique or two where I had no idea that a more efficient way than mine (and many others) "tried and true" method existed.
    2) if someone makes a wrong reply it is (almost) immediately corrected.

    So, please do not suggest taking this discussion off the forum

    Erik

  • Mrunmoy,

    Given the nature of your job situation, I can understand that you might want to ask some questions privately. You can email me at jdaniel@NOSPAM.ieee.org. (Remove the NOSPAM. to get my real address). That being said, please take the advice of others about the forum: If you're going to ask a technical question, do it here so that others who have similar concerns will be able to find it and learn from it.

    -Jay Daniel

  • Thanks Daniel.

    But as Erik said. Everyone should get benefited by the technical discussions in this forum. I will post all technical questions in here.

  • I agree 100% to you Erik, that I should post all the technical questions here. Because even i got benefited by the answers that all of you have posted.

    But, what i said was not crap. At least a seasoned person like you shouldn't be saying that. Pls. don't take it otherwise, i am not blaming anyone here.

    If you can do one design well, even if it is a small one, you'd definitely do the big design well. I mean a microcontroller will always be a microcontroller no matter how many extra features it has. It all depends upon how well one has understood and comprehended that first design. We make mistakes but, these mistakes teach us good lessons.

    After all, everything starts small and grows big. Don't you agree with that Erik?

  • Jay,

    Sorry for referring you with your last name.

  • "I should post all the technical questions here."

    Actually, this forum should only be used for discussions specifically about Keil products - see: http://www.keil.com/forum/

    For general discussions about the 8051/2 family, you could try: http://www.8052.com/forum

    See also: http://www.keil.com/forum/otherforums.asp

  • If you can do one design well, even if it is a small one, you'd definitely do the big design well.
    and the moon is made of green cheese. That you get 'blinky' to work, by no means make you qualified for a big job.

    I mean a microcontroller will always be a microcontroller no matter how many extra features it has.
    there is NO SUCH THING AS "A" microcontroller
    e.g. a PIC and a '51 are as different as ... no, a hundered times more different than an apple and an orange.

    We make mistakes but, these mistakes teach us good lessons.
    correct

    After all, everything starts small and grows big.
    usually.

    Erik

  • Actually, this forum should only be used for discussions specifically about Keil products...

    But a higher number of high-quality technical discussions that are handled on _this_ forum, will result in a correspondingly fewer number of people who will visit other forums where they may accidentaly get recommendations to look at products by IA<beep> or similar.

    Strictly speaking, it would be advantageous for Keil to allow general-purpose embedded discussions, possibly allowing people to filter away these threads if not interested. The cust of running a forum is not proportional to volume of posts.

  • After all, everything starts small and grows big.

    Like the list of open bugz in Bugzilla? :)

  • Jay Daniel said: "what separates truly great embedded systems designers from mediocre ones is their ability to think about hardware and software seamlessly."

    That is quite true. Quite many control operations can be expressed as analog circuitry, digital circuitry, mixed electronics, pure software and mixed hardware/software. Knowing where to draw the interface line is a good design asset. Example: In a recent project a synthesized chopped stepper motor drive waveform started the design in pure software and eventually part of the chopping processing was moved to analog hardware to free up mcu core processing bandwidth and increase motor current ripple stability.

    "Your hardware design background will be invaluable to you in your understanding of embedded software design."

    I agree. I have found that it is harder for people that come from high-level software development to become proficient in embedded systems design than it is for hardware design engineers to become good at systems design. Nonetheless, you must not overlook a good base of software engineering, data structures, failsafe design, event-driven modeling, and control theory, just to name a few 'software' skills you need to master.

  • A few recommendations:

    - Although embedded design can look like 'see one see all', mcu cores are widely different, and require quite different design approaches. Have this always in mind. Never try to port raw code, but port algorithms and knowledge instead. You cannot blindly apply specific techniques of one chip to another, but you can apply your systematic learning approach to every new technology.

    - Always read ALL the chip datasheets, from start to end. The datasheet is your best friend, keep it at ARM's length;

    - Get the silicon Errata for ALL the chips on your design. Every mcu chip has at least one Errata sheet. If you can't find it, be suspicious;

    - Get to know your mcu core at an intimate level. Learn its assembly language. Learn how data is organized in its memory, the memory layout, special areas and rules. It *IS* important to know the chip at low-level, even if you will only program in C. Get to know, for example, how parameters are passed in functions, and write functions that make the best usage of the procedure call standard;

    - Get to know the gory details of the interrupt processing of your chip and of your compiler, special function registers and peripheral setup and capabilities. At systems-level design, you must know what to expect from them.

    - Get a deeper understanding of how your toolchain works. Study small sequences of compiled code at several optimization levels to get a grasp of what is the best style of C to generate the best machine code. Good developers write efficient C code because they know which style translates to lean machine code for the compiler/cpu at hand.

    - Pay attention to your system architecture at the design stage. This is a hardware/software constraint. Try to secure good boundary conditions for your problem, and then take into account the combined hardware/software behavior, latencies and data path. A well-planned architecture will save you a life of maintenance and reimplementation in the future, not to say your job position.