Only one thread supported?

[Rush]

I think with initializing the single TIMER your code will not scale to more threads. I think the TIMER belongs to a different "abstraction" layer and instead there should be two mechanisms:

• Round trip scheduling triggered by SysTick
• Voluntary (or by TIMER) scheduling triggered by Timer and PendV.

I am gonna try your code modified for Energy Micro micro controller, cool little project.

[slugonamission]

Hey,

Thanks for your comments. As a preface to this reply though, this was really written as a "I wonder how to do this", and was only really meant for a simple case.

Replacing the TIMER in this example with a SYSTICK would work, yes, and would arguably be a better way to do it, however, I disagree with your assertion that using a TIMER instead means it can't scale past one thread. What is your argument for this?

Of course, co-operative multi-threading is a possibility, but the code for doing so is pretty simple (well, trap to the scheduler). Again though, this was more of a test of multi-tasking on the M3, I wasn't really designing with the criteria of "good scheduler" too :P

[Rush]

Sorry, I have jumped to conclusions a bit prematurely that your TIMER is a per-thread timer. I have not really the need to have threads but I have always wondered how to do it as well, hence I enjoyed such simple example. Unfortunately I cannot get it to work and I am getting some hard fault in the scheduling routine. Is it possible that you use something specific to your CM3 vendor (excluding the TIMER setup routines) ? May I ask whether you were basing yourself on reference manual only or perhaps some insightful application notes?

[Rush]

Ok, seems to be working somehow with SysTick ... crashes after some time but at least there is something ;)

[slugonamission]

Can you post the code you're using somewhere? It's based off the standard M3 reference manual, but NXP could well have added a couple more bits that I took for granted. (I'm using an LPC1768)

[Rush]

Sure, I am gonna make a few more improvements and I will post the code.

2013/9/27 Jamie notifications@github.com

Can you post the code you're using somewhere? It's based off the standard
M3 reference manual, but NXP could well have added a couple more bits that
I took for granted. (I'm using an LPC1768)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-25233392
.

[Rush]

https://gist.github.com/RushPL/6209c26a783f86863edb
I was fighting for a couple of hours to get this to work according to my understanding but I have the following issue:

 __asm__("BX lr;");
 __asm__("NOP;");

Above code should return depending on the LR register either to MSP or PSP. We set LR to THREAD_RETURN and also you have set the default in the CONTROL register (but I disable this default).

Now the problem .. is the above code is present, the MSP register will grow with each SysTick until out of valid range.
The funny thing is when I remove this BX lr; nop; then running threads works well. It is not what I would expect.

My goal was to allow the main thread to run as well, hence the need to get the THREAD_RETURN and MAIN_RETURN right but I feel there is some minor issue with this code preventing the correct behavior.

Let me know if you have any ideas.