[ECOS] why is it wrong to call cyg_semaphore_post() in ISR???

[ECOS] why is it wrong to call cyg_semaphore_post() in ISR???

[Monica Dsz]

Hallo all,

I am new to eCos(and also to embedded). The eCos documentation says that ISR 
should not involve any kernel calls.But I want to know why 
cyg_semaphore_post() is not allowed in ISR(Interrupt service routine). It 
doesnt block. and i tried to use it though documentation says we shouldnt. 
It worked for me with the following code.

cyg_uint32 timer_isr(cyg_vector_t vector,cyg_addrword_t data)
{
  led_toggle();                    //Toggle the LED

  isr_counter++;                //32 bit ISR counter

  cyg_interrupt_acknowledge( vector ); //acknowledge the Interrupt to the 
processor

  cyg_semaphore_post( &intr_occured );   //give the semaphore,so that task 
waiting for it wakes up

  return( CYG_ISR_HANDLED  );          // Inform the kernel that ISR is 
handled
}

I wonder why in eCos,a semaphore cannot be posted in ISR. In VxWorks we can 
give a semaphore in ISR. Can anybody give me a pointer to documentation or 
an explanation for this.

Thank you in advance

monica


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] why is it wrong to call cyg_semaphore_post() in ISR???

[Gary Thomas]

On Thu, 2006-06-08 at 18:41 +0200, Monica Dsz wrote:
> Hallo all,
> 
> I am new to eCos(and also to embedded). The eCos documentation says that ISR 
> should not involve any kernel calls.But I want to know why 
> cyg_semaphore_post() is not allowed in ISR(Interrupt service routine). It 
> doesnt block. and i tried to use it though documentation says we shouldnt. 
> It worked for me with the following code.
> 
> cyg_uint32 timer_isr(cyg_vector_t vector,cyg_addrword_t data)
> {
>   led_toggle();                    //Toggle the LED
> 
>   isr_counter++;                //32 bit ISR counter
> 
>   cyg_interrupt_acknowledge( vector ); //acknowledge the Interrupt to the 
> processor
> 
>   cyg_semaphore_post( &intr_occured );   //give the semaphore,so that task 
> waiting for it wakes up
> 
>   return( CYG_ISR_HANDLED  );          // Inform the kernel that ISR is 
> handled
> }
> 
> I wonder why in eCos,a semaphore cannot be posted in ISR. In VxWorks we can 
> give a semaphore in ISR. Can anybody give me a pointer to documentation or 
> an explanation for this.

ISR functions can be called at any time, so it's possible that you could
be executing code within the scheduler or even semaphore handling when
the ISR runs.  In this case, the various state [variables] in the system
may not be in a consistent state and allowing the ISR to change them 
would be catastrophic.

It's a trade off - do you prevent interrupts (hence ISR routines) from
running during all data critical sections or do you simply not allow
those [ISR] functions to execute code that might perturb critical data?
eCos chooses the latter method which allows for lower interrupt latency
by putting off things until the DSR can be safely run.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] why is it wrong to call cyg_semaphore_post() in ISR???

[Monica Dsz]

> It's a trade off - do you prevent interrupts (hence ISR routines) from
> running during all data critical sections or do you simply not allow
> those [ISR] functions to execute code that might perturb critical data?
> eCos chooses the latter method which allows for lower interrupt latency
> by putting off things until the DSR can be safely run.

Thanks alot. this is exactly what I am searching for. I searched a lot to 
find it and I read  alot but in vain I did not get it. Now I understood it. 
Once again thanks for your explanation.

monica





-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] why is it wrong to call cyg_semaphore_post() in ISR???

[Monica Dsz]

> It's a trade off - do you prevent interrupts (hence ISR routines) from
> running during all data critical sections or do you simply not allow
> those [ISR] functions to execute code that might perturb critical data?
> eCos chooses the latter method which allows for lower interrupt latency
> by putting off things until the DSR can be safely run.
>

just to confirm my understanding, does this mean that we never have to 
disable and re-enable the interrupts during critical sections? or are there 
any cases still we have to disable the interrupts in eCos.

The more I try to understand eCos, the more I am liking it. I wonder why our 
company wasnt using this cool RTOS, anyway!!! I hope I will be able to 
convince my supervisor to use eCos instead of expensive VxWorks.

Thanks again for the information.

monica

 


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] why is it wrong to call cyg_semaphore_post() in ISR???

[Andrew Lunn]

On Fri, Jun 09, 2006 at 11:18:14AM +0200, Monica Dsz wrote:
> 
> >It's a trade off - do you prevent interrupts (hence ISR routines) from
> >running during all data critical sections or do you simply not allow
> >those [ISR] functions to execute code that might perturb critical data?
> >eCos chooses the latter method which allows for lower interrupt latency
> >by putting off things until the DSR can be safely run.
> >
> 
> just to confirm my understanding, does this mean that we never have to 
> disable and re-enable the interrupts during critical sections? or are there 
> any cases still we have to disable the interrupts in eCos.

Normally, you try not to disable interrupts in RTOS's. You should
protect your critical regions with mutex's, semaphores etc.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] why is it wrong to call cyg_semaphore_post() in ISR???

[Monica Dsz]

> Normally, you try not to disable interrupts in RTOS's. You should
> protect your critical regions with mutex's, semaphores etc.
>

I remember well that I(we in our company) have used intLock () in VxWorks to 
make sure that interrupt doesnt during some critical sections. Ofcourse we 
did use semaphores and mutexes to guard against other threads but as far as 
I remember i never used semaphores/mutexes to guard against interrupts.

    lockKey = intLock ();

     ... (work with interrupts locked out)

    intUnlock (lockKey);
Seems in eCos we dont need to disable interrupts because interrupts doesnt 
perform any kernal calls and we can use DSR to give semaphores and etcthank 
you 


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] why is it wrong to call cyg_semaphore_post() in ISR???

[Andrew Lunn]

> Any idea what the performance loss is by using ISR+DSR instead of
> ISR only?  We are using NIOS-II processor and any context switch
> avoided makes our system a lot faster!

It is impossible to measure since you cannot run a system with just
ISRs and no DSRs.

Also, you would expect 99% of your DSR's to run straight after the ISR
in the ISR context. So normally a DSR does not cause an additional
context switch, it is just piggybacked onto the ISR context switch.

Even if the DSR is deferred becasue the schedular is locked, when the
DSR is run it will run in the context of the thread unlocking the
schedular so again there is no context switch. The only time there
could be an "additional" context switch is when this deferred DSR
causes a higher priority thread to become runnable so forcing a
context switch. In this case the current context has to be saved and
the new threads context loaded. 

If the DSR was run in ISR context, the interrupted threads context has
already been saved and the context will be restored when the interrupt
exists. Hence a change in the running thread during an ISR+DSR does
not cause an additional context switch.

      Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] why is it wrong to call cyg_semaphore_post() in ISR???

[Goldschmidt Simon]

Hi,

>> Normally, you try not to disable interrupts in RTOS's. You should 
>> protect your critical regions with mutex's, semaphores etc.
>>

That might be true if minimal interrupt latency is your main goal. But if you have to get the best performance out of your hardware, disabling interrupts seems faster to me than using mutexes...

>
>I remember well that I(we in our company) have used intLock () in 
>VxWorks to make sure that interrupt doesnt during some critical 
>sections. Ofcourse we did use semaphores and mutexes to guard against 
>other threads but as far as I remember i never used semaphores/mutexes to guard against interrupts.
>
>    lockKey = intLock ();
>
>     ... (work with interrupts locked out)
>
>    intUnlock (lockKey);

That's how we do it with µC/OS.

>Seems in eCos we dont need to disable interrupts because interrupts 
>doesnt perform any kernal calls and we can use DSR to give semaphores 
>and etcthank you

Any idea what the performance loss is by using ISR+DSR instead of ISR only?
We are using NIOS-II processor and any context switch avoided makes our system a lot faster!

Thanks,
Simon.

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss