public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Gary Thomas <gary@mlbassoc.com>
To: Monica Dsz <monica.dsz@googlemail.com>
Cc: ecos discuss <ecos-discuss@ecos.sourceware.org>
Subject: Re: [ECOS] why is it wrong to call cyg_semaphore_post() in ISR???
Date: Thu, 08 Jun 2006 18:06:00 -0000	[thread overview]
Message-ID: <1149789900.15359.183.camel@hermes> (raw)
In-Reply-To: <000501c68b1a$68b523b0$ea14a8c0@taurus>

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

  reply	other threads:[~2006-06-08 18:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-08 17:39 Monica Dsz
2006-06-08 18:06 ` Gary Thomas [this message]
2006-06-09  7:23   ` Monica Dsz
2006-06-09  9:19   ` Monica Dsz
2006-06-09  9:27     ` Andrew Lunn
2006-06-09  9:43       ` Monica Dsz
2006-06-20 12:52 Goldschmidt Simon
2006-06-20 13:12 ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1149789900.15359.183.camel@hermes \
    --to=gary@mlbassoc.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=monica.dsz@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).