[En-Nut-Discussion] CVS Commits

[Ralph Mason]

Harald Kipp wrote:

> Hi Ralph,
>
>> 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).

You are correct.  I think I removed a few more volatiles here and there 
also (in the TCP stack from memory).  I will diff from the released 
source and see if I can find them.

> 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?
>
It's a long time since I did that and at the time I was reasonably new 
to nut OS.

A thread can't deallocate itself for obvious reasons.  So we need to 
have the thread in a state where it won't run.  As the idle thread will  
never wait it will always run above the killed thread and so can free it.

It seems the same could be accomplished by just removing the thread from 
the runQueue and saving it a killedThread then calling 
NutThreadSwitch(), probably a better implementation. 

Off hand I can't think why I used the 255 priority or see any benifit in 
it over the above.

> 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.
>
I have not implemented anything because it hasn't really been a problem 
to me.  It also uses extra stack space as the entrypoit of the thread 
will save registers if it's not a naked function.   I guess I found it 
just as easy to call NutThreadExit at the end of the thread function. 
The compiler always warns you if you exit the noreturn function so it's 
easy to spot where you should have NutThreadExit.

> 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.
>
There was some talk in the avr-gcc list a while back about adding the 
ability directly to the compiler.  I think it died a bit of a death.

The possibility of reentrant/nested interrupt handlers is an interesting 
idea, and clearly complicates an interrupt stack. Solutions are not hard 
to imagine but you need to consider (IMHO) that if you are doing 
something that takes that long you should be doing it in user mode 
anyway.  Interrupt handlers should be fast in quick work and out of there.

> 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.

This might be of interest 
http://www.avr1.org/pipermail/avr-gcc-list/2003-January/003385.html, 
avrx supports it appears supports nested interupts on a seperate stack.

I not sure the reward is worth the complication, codesize or cycles.  As 
above, if you need big processing create a thread to do it, and set that 
thread free to run from you interupt handler.  Keep the interupt handler 
small, fast and non reentrant / not nestable. NutOS is a cooprative OS 
(which is what I like about it), it takes 'unlearning' to make use of 
the simplicity and ease of use compaired to unneccesary problems a 
premptive os will provide a programmer. 

In the case of the VS driver, perhaps it could be rewritten as a thread 
(highest priority)

while(playing){
    while ( player needs data ){
          SendByte();
    }
    NutThreadYeild();
}

If some other thread needs to do something that takes a long time it can 
do some thing  like

if ( player needs data )
    Yeild();

Just my thoughts.

Ralph