I guess the following is a no-no in tasks.c (note this is v6.0.5):
typedef struct tskTaskControlBlock
volatile portSTACK_TYPE *pxTopOfStack; /*< Points to the location of the last item placed on the tasks stack. THIS MUST BE THE FIRST MEMBER OF THE STRUCT. */
#if ( portUSING_SYSSTACK == 1 )
volatile portSTACK_TYPE *pxTopOfSysStack;
So, what would be the 'correct' way of adding this?
Of course, if I do end up modifying tasks.c to make this port work - I will post my changes to tasks.c and of course the port too.
You can modify tasks.c if you don't mind maintaining your own copy, but it can't be put into the main line.
What is is you are trying to do?
Good Morning Richard,
Of course I don't mind maintaining my own copy - and I don't think it should be added to trunk - I am working on a port for TI's Ultra-Low Power DSP's - C5000 - specifically the 'C5515 and 'C5535 - they have two stacks (unfortunately) - 'stack' and 'sysStack' - I am working on how to handle this.
I have it running the demo LED task (mostly) - but I need to handle sysStack properly.
You might want to look at the AVR IAR port which, if I recall (it was some time ago), that maintains separate call and data stacks.
I would however suggest keeping aware from the core code and just implementing this in the port layer. You have complete control over the stack frame used to save and restore a task context, so can just save the additional stack pointer on the stack.
If you have two stacks, StackA and StackB, and StackA is where the registers are stored, then just add a few extra assembly instructions to save the SackB pointer onto StackA either before or after the registers have been stored as appropriate. It might best to store it after the registers have been stored if the act of saving StackB onto StackA itself causes a register to change, because the registers must be saved before they are modified.
Yes - I've been thinking of ways to get this done - here's a snapshot out of the CPU's UG describing the context-switching for calls and IRQ's:
I think what I will do is add the
to tasks.c plus the associated code to allocate the memory until I get the programming for this 'settled' out a bit. I am seeing behavior that doesn't exactly follow the docs. Also, TI is supposed to release CCS 5.3 soon (already released last Monday but they have pulled it back) - and I am waiting to see if anything in the compiler changes.
I have developed the tasks.c file that uses a 'dual stack' - just an FYI - and I think I will get this to work - I will post when I have completed it.
I know you hate the 8051 - but I am thinking that this approach can also be used with the 3 stacks that are necessary for that - just wanted to mention that.
Just wanted to mention that I have a version of the dual-stack tasks.c file and have the core of FreeRTOS running on this port now. Note this is a minimal implementation at this point and I need to do some further debug before I release the *full* demo but the core is running; I have two tasks running; it looks OK.
Here's a pic of TI's eZDSP5535 board running FreeRTOS (currently version 6.0.5 - but I will get that current soon):
The idle task and the LED Tasks are running - the LED on the XF pin is blinking and the 4 'main' LEDs' are being cycled on/off. I know it's a little hard to tell from a pic - but, there it is.
I want to clean up a few things before I post the demo - but if someone really wants to look at this - shoot me an e-mail.
Your project looks great.
I'm using DSP/BIOS on C5515 EVM (eZDSP5515) and I fill that TI's DSP/BIOS is hiding to many things from the programmer.
So, Can I use it? Can you PLEASE post a link for download?
Thanks in advanced,
Sure, I will post it then put the details here. Please give me a few days if that is OK.
Hi John W.
Thanks you very much!!