[En-Nut-Discussion] CVS Commits

[Harald Kipp]

Hi Ralph,

fortunately Sourceforge's anonymous CVS access is updated
more regularly now.


>On that subject, I don't think runningThread  should be declared as
>volatile.  It is  and should never changed by an interrupt so the volatile 
>appears unneccessary.
>
>Removing it should save a few cycles and bytes here and there.

I agree, defining it non-volatile shouldn't hurt. I guess,
there are a few more, like killedThread (named killed in your
contrib).

I'd like to discuss a few more points. There's no hurry,
so take the time you need to answer.

You use priority 255 for killing a thread. Is this really
required? Is there any other idea behind it? Isn't
NutThreadKill() sufficient?

You recently talked about terminating a thread when it
returns from it's main routine. Did you try any available
code? Shouldn't be too difficult to implement, but I may
overlook something.

Finally, some time ago you suggested to use a separate
interrupt stack. I like this idea, because as more advanced
device drivers get implemented it becomes more difficult
to determine stack usage. Some complex interrupt routines
may re-enable CPU interrupts to reduce global interrupt
latency. The VS1001 driver is an example.

I found some rare examples from other operating systems,
but as far as I understand the infos provided, they support
CPUs, which switch the stack pointer on interrupts.
I'd prefer not to re-invent the wheel or at least check
some existing ideas.

Regards,

Harald