Hi,

I thought I had a working GCC/ATMega2560 port(Atman WinAVR),
since the demo worked fine. However while having problems to
get some parts of my own application run, I ended up in
returning to the demo and it turns out that it doesn't work
using no optimizations(!) and it seems that crSEND_QUEUE is
the troublesome part. Building with -Os creates a working
demo, but not when using -O0.

I can'r figure out if this is a bug in my port or my
tool chain, and if someone could verify the demo is working
also with no optimizations i'd be glad. (or sad)

Any hint is much appreciated, and if someone with a working
patch for the Mega2560 would like to share it, it would make
my weekend.

Thanks,

Johan

Take a look at point 4 in http://www.freertos.org/History.txt. Relates to receiving rather than sending - but if you are sending I suppose you must be receiving also ;-) Could this be related to your problem?

Hmm, don't think so.
I used the SVN version so that was already fixed.

I just saw an old Barry post saying "all the co-routines have to execute in within the same task" (which my does). I can't find that in the docs. Are there more undocumented restrictions on coroutines;

Is it possible to post on a queue from a coroutine with crQUEUE_SEND(Handle, Q,...) and receive the message in the task with xQueueReceive(The_Q,...) ?

If so, can coroutines of task A post on a queue aimed for receiveing by task B?

Is it possible to create some tasks, and let one of them subsequently create some coroutines or do the coroutines have to be created before scheduling starts?

But anyhow, I can't figure out why the no-optimize flag creates non working (coroutine?) applications.

/Johan

This optimisation thing is becoming a puzzle. It has been mentioned before for ARM targets, but not in relation to co-routines. I suspect it is the same problem it is just that you are seeing it in a different place in the code.

I changed the demo application to use flash.c rather than crflash.c (and increased the heap)...
Same error without coroutines.

Increasing the staack allocated to the task is the thing to do, rather than increasing the heap. Can you work out which task is causing the problem, and allocated it some more ram?

The (flash) tasks requires more ram than the coroutines so the heap had to be increased.

Stack increase of the only task performing any actions makes no difference, nor do
moving creation of the coroutines to main rather than in one of the tasks.

My conclution so far is, until someone can verify the opposite, is that either
my port is not good enough or coroutines are not allowed to post on the same queue
that a task is blocking on.

Before starting to debug the OS it would be nice to know that.

J.

I don't know for sure, but the use of differnet API calls and block lists would make it seem like not a good idea.

Could be.

I played some more with the opt flags and it turns out that the (Minimal/)comtest TX task uses more stack than configMINIMAL_STACK_SIZE of 85 as shipped. It seems that it eats 98 bytes when using -Os and 108 with -O0.
Using comSTACK_SIZE 110 seems reasonable, and the demo then runs even not optimized. :)

I have not investigated _why_ it still runs in the former case.

J.