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!!
I am interested in using FreeRTOS on the c5532, did you end up publishing your changes?
I have been asked recently to make details of this port available - note this is still a work in progress and it would be nice to have some 'beta' testers; if you will; before the port is declared stable.
Note I have this running with the latest tools from TI - CCS 6.1.3...34 or such as of this writing - 6.2.x looks like it will be released on Thursday; or at least TI is announcing something along those lines soon.
The port here is running 6.0.5 - I don't have it updated yet for 9.x. Also, I am running both the stack and sysstack - and have some simple demo tasks running - as shown above; blinky and a few simple tasks. I haven't checked everything yet for all data and pointer types; and it would appear something is going on with DBSTAT; but I should be able to fix the DBSTAT issue soon.
I currently have the project up on AWS Code Commit (Git) - since Amazon is running such a good deal on that. I do not know if anonymous download for that is available or not; but would be nice since it will make managing requests a lot easier. If anonymous download is available; I will post those details.
In order to run the existing port; it would be nice for you to have the eZDSPTMS320C5535 board from TI or Spectrum Digital since the demo code runs on that; and modifying the port to run on another hardware platform will probably entail some work on your end; but of course you are free to try.
Switching back to the '5515 board is possible but you will have to make those mods in the demo code; and there could even be some mods necessary in the port files; but I did start with the '5515 originally.
Using the '5545 is also possible; going to that from the '5535 should be easier than going to the '5515.
On a special request basis only I can make a '5515 demo available.
Here's the photo link:
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.