How to implement simple stack switching in PIC12/16 cores?

Question

I am trying to understand how real time operating systems work. I have looked at the source codes of some RTOSes. I want to learn by creating my simple RTOS, something like FLIRT.

I am using PIC16 series and XC8 C compiler with MPLABX. I also want to implement this very simple RTOS to PIC12 series.

So, I decided that I should start by learning how to manipulate stack (like supercat did in this answer) and I started searching and came across AN818 which is titled "Manipulating the Stack of the PIC18 Microcontroller". Cited from the application note:

Traditionally, the microcontroller stack has only been used as a storage space for return addresses of subroutines or interrupt routines, where all ‘push’ and ‘pop’ operations were hidden.

For the most part, users had no direct access to the information on the stack. The PIC18 microcontroller diverges from this tradition slightly. With the new PIC18 core, users now have access to the stack and can modify the stack pointer and stack data directly.

I am confused. How come there are RTOSes made for PIC microcontrollers that work with PIC16 cores? For example, OSA RTOS is available for PIC12/16 with mikroC compiler.

Can you direct me to some resources, or if possible give examples, so that I can learn about stack switching?

Answer 1

Every RTOS for a PIC which does not have a software-addressable stack generally requires that all but one of the tasks must have its work divided into uninterruptable pieces which begin and end at the top stack level; the "task-yield" operation does not use a function call, but rather a sequence like

// This code is part of task C (assume for this example, there are tasks
// called A, B, C
  movlw JumpC4 & 255
  goto TASK_SWITCH_FROM_C
TargetC4:

Elsewhere in the code would be some code like:

TASK_SWITCH_FROM_A:
  movwf nextJumpA  // Save state of task C
  // Now dispatch next instruction for task A
  movlw TaskB_Table >> 8
  movwf PCLATH
  movf  nextJumpB,w
  movwf PCL
TASK_SWITCH_FROM_B:
  movwf nextJumpB  // Save state of task C
  // Now dispatch next instruction for task A
  movlw TaskC_Table >> 8
  movwf PCLATH
  movf  nextJumpC,w
  movwf PCL
TASK_SWITCH_FROM_C:
  movwf nextJumpC  // Save state of task C
  // Now dispatch next instruction for task A
  movlw TaskA_Table >> 8
  movwf PCLATH
  movf  nextJumpA,w
  movwf PCL

At the end of the code, for each task, there would be a jump table; each table would have to fit within a 256-word page (and could thus have a maximum of 256 jumps)

TaskC_Table:
JumpC0 : goto TargetC0
JumpC1 : goto TargetC1
JumpC2 : goto TargetC2
JumpC3 : goto TargetC3
JumpC4 : goto TargetC4
...etc.

Effectively, the movlw at the start of the task-switch sequence loads the W register with the LSB of the address of the instruction at JumpC4. The code at TASK_SWITCH_FROM_C would stash that value someplace, and then dispatch the code for task A. Later, after TASK_SWITCH_FROM_B is executed, the stored JumpC4 address would be reloaded into W and the system would jump to the instruction pointed to thereby. That instruction would be a goto TargetC4, which would in turn resume execution at the instruction following the task-switch sequence. Note that task switching doesn't use the stack at all.

If one wanted to do a task switch within a called function, it might be possible to do so if that function's call and return were handled in a manner similar to the above (one would probably have to wrap the function call in a special macro to force the proper code to be generated). Note that the compiler itself wouldn't be capable of generating code like the above. Instead, macros in the source code would generate directives in the assembly-language file. A program supplied by the RTOS vendor would read the assembly-language file, look for those directives, and generate the appropriate vectoring code.

Answer 2

The traditional 14 bit core PICs (mostly PIC 16 and a few PIC 12) don't have a way for the program to access the call stack. This therefore makes a true multi tasking system impossible.

However, you can still have what I call pseudo tasks. This is a routine that is called periodically from the main event loop. It maintains a restart address internally. When the main even loop calls it, it jumps to the restart address of the pseudo task private to that module. After some processing, the task code invokes a YIELD macro that sets the restart address to immediately after the macro, then returns from the original call. Since the call stack can't be unwound, YIELD can only be invoked from the top task level. Still this is a useful abstraction.

You can see a example of such a pseudo task being used to process a command stream from a host computer in my QQQ_CMD.ASPIC template module. In this case the return to the caller is hidden in the GETBYTE macro, which appears to go and get the next input byte from the task's point of view. Install my PIC Development Tools release from the software downloads page. QQQ_CMD.ASPIC will be in the SOURCE > PIC directory within the software installation directory.

To see how real multi-tasking can be done when you have access to the call stack, take a look at TASK.INS.ASPIC in the same directory. That is my generic multi-tasking system for the PIC 18. You can see the same thing for the dsPIC architecture by looking at TASK.INS.DSPIC in the SOURCE > DSPIC directory.

Answer 3

The PIC16 series "14 bit core" chips have a "hardware stack RAM" that is completely separate and independent of the "data RAM". (It even has a different size and width than the data RAM). The "core block diagram" for any of those chips clearly shows that the "hardware stack" is connected only to the program counter -- the only instruction that writes to that hardware stack is (the various types of) CALL, and the only instruction that reads from that hardware stack is (the various types of) RETURN.

"stack switching" is impossible for the "hardware stack" in these "14 bit core" chips.

This makes most traditional OS task-switching methods impossible on this series of chips.

There are a few RTOSes that do run on this series of chips, so therefore there must be a few task-switching methods that are possible on this chip ( "PIC Microcontroller specific Multitasking Methods" ).

In practice, all the RTOSes I've seen have some sort of cooperative task-switcher that "yields" from one task to the next only in the top-level code of each task. Because the yield is never from inside a subroutine, there are no return addresses on the hardware stack.

In principle, it's possible to program these chips to build a software stack in RAM and use that to simulate a return stack. (Using a "user defined stack" in data RAM, rather than the hardware stack). Then you could use all the traditional OS task-switching stuff, such as giving each task a separate block of RAM for its local stack, etc. I don't know if the extra complexity and non-standard call sequences would be worth it.