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

Jumping to function after timer interrupt

In my program, I have a periodic timer interrupt written in C.

What I need to achieve is to have the interrupt service routine jump to another function after the interrupt service routine is executed.

However, the catch is that the address of the function (which the program is suppose to jump) is stored as a variable (which is not fixed each time the interrupt occurs).

Im looking for advice on how can this possibly be done. Thank you.

Parents
  • Note that "stack", in the context of overlaid memory, is not just the stack pointer. It's the state of all the overlaid memory as well.

    That is, if you arbitrarily preempt a task at any point in its execution, you can't overlay its memory with that of any other task. Each task will need to be the root of its own call tree.

    Unless you have very few and very simple tasks, the increase in memory consumption will likely mean that you need to use xdata instead of data, and that in and of itself will significantly increase the code side required.

    You'll also need more care to be sure your shared library routines are reentrant, or provide mutual exclusion around them.

    The 8051 architecture, IMO, just isn't well suited to preemption.

Reply
  • Note that "stack", in the context of overlaid memory, is not just the stack pointer. It's the state of all the overlaid memory as well.

    That is, if you arbitrarily preempt a task at any point in its execution, you can't overlay its memory with that of any other task. Each task will need to be the root of its own call tree.

    Unless you have very few and very simple tasks, the increase in memory consumption will likely mean that you need to use xdata instead of data, and that in and of itself will significantly increase the code side required.

    You'll also need more care to be sure your shared library routines are reentrant, or provide mutual exclusion around them.

    The 8051 architecture, IMO, just isn't well suited to preemption.

Children
  • The 8051 architecture, IMO, just isn't well suited to preemption.
    Amen.

    Erik

  • From the Philips forum:

    Wilson Teo

    Post subject: 89C51RD2 and SDCC

    Pardon me for my ignorance as I am very new to 8051 and SDCC. Thank you in advance.

    Wilson: As stated above, multitasking and the '51 do not make a good match, WHY are you trying to do this?

    Erik

  • Hi

    I guess it might not make sense to a lot people why I am doing this.

    Anyway, this is actually part of my academic project where I am suppose to port an existing small footprint RTOS from the x86 to 8051.

    Would appreciate anyone who can explain further why it is unsuitable though it might be achievable?

  • Would appreciate anyone who can explain further why it is unsuitable though it might be achievable?
    Since you are obviously allergic to reading up on the '51 architecture, that would be tough. So let me make it simple read the 3 chapters of "the bible" referred to and concentrate on the references to "memory types" and stack.

    Erik

  • Hi Erik

    I have actually read up on the '51 architecture. Please pardon me for my ignorance if I was not able to understand the whole picture and hope to seek some advice from the more experienced.

    Anyway, I had create a context switching routine for pre-emption of tasks in my application. It is working fine but I would appreciate any more opinions on the idea of implementing pre-emptive multitasking on the '51.

    Thank you.

  • It is working fine but I would appreciate any more opinions on the idea of implementing pre-emptive multitasking on the '51.
    Let me give you "opinions on not implementing PEM (pre-emptive multitasking) on the '51."

    1) The '51 is a microcontroller and microcontrollers are not made for number crunching, but for rapid response to external events. This ability, which is the only one i know for selecting a microcontroller over a microprocessor will be totally lost if PEM is implemented.

    2) If more than one task is to be performed, the correct way to do so with microcontrollers is to make a "uC farm" e.g. one processor handling operator I/O, another handling the actual process and a third communication with the outside world.
    In such a scenario you could use say 3 LPC932 chips at $1 each, so why screw around with killing the performance in order to use a $10 processor instead of 3 $1 processors.

    If you want to implement PEM, do it on a processor suited for it. You take your car, not your riding lawnmower when you go to the grocery store I presume.

    Erik