[ECOS] CYG_ISR_CALL_DSR vs CYG_ISR_HANDLED

[ECOS] CYG_ISR_CALL_DSR vs CYG_ISR_HANDLED

[osv]

Hello,

In the eCos reference manual one can read:

  The return value of an ISR is normally one of CYG_ISR_CALL_DSR or
  CYG_ISR_HANDLED. The former indicates that further processing is
  required at DSR level, and the interrupt handler’s DSR will be run as
  soon as possible. The latter indicates that the interrupt has been
  fully handled and no further effort is required.

However, the eCos internal clock isr (Cyg_RealTimeClock::isr()) returns
as follows:

    return Cyg_Interrupt::CALL_DSR|Cyg_Interrupt::HANDLED;

that seems to contradict with the description above. What is the truth
about isr handler return codes?

-- 
Sergei.

--
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] CYG_ISR_CALL_DSR vs CYG_ISR_HANDLED

[Gary Thomas]

On Fri, 2005-11-18 at 16:59 +0300, osv wrote:
> Hello,
> 
> In the eCos reference manual one can read:
> 
>   The return value of an ISR is normally one of CYG_ISR_CALL_DSR or
>   CYG_ISR_HANDLED. The former indicates that further processing is
>   required at DSR level, and the interrupt handlerĆæs DSR will be run as
>   soon as possible. The latter indicates that the interrupt has been
>   fully handled and no further effort is required.

This is poorly worded I think.

> 
> However, the eCos internal clock isr (Cyg_RealTimeClock::isr()) returns
> as follows:
> 
>     return Cyg_Interrupt::CALL_DSR|Cyg_Interrupt::HANDLED;
> 
> that seems to contradict with the description above. What is the truth
> about isr handler return codes?

CYG_ISR_HANDLED says that the ISR actually did something about the
interrupt.  It's used by chained interrupts to determine if another
ISR (which shares the same interrupt) should be run.

CYG_ISR_CALL_DSR indicates that the DSR which corresponds to this ISR
should be run.

These are bit values which can be successfully or'ed together to achieve
the desired result.

-- 
------------------------------------------------------------
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] [PATCH] CYG_ISR_CALL_DSR vs CYG_ISR_HANDLED.

[osv]

Gary Thomas <gary@mlbassoc.com> writes:
> On Fri, 2005-11-18 at 16:59 +0300, osv wrote:
>> Hello,
>> 
>> In the eCos reference manual one can read:
>> 
>>   The return value of an ISR is normally one of CYG_ISR_CALL_DSR or
>>   CYG_ISR_HANDLED. The former indicates that further processing is
>>   required at DSR level, and the interrupt handler’s DSR will be run as
>>   soon as possible. The latter indicates that the interrupt has been
>>   fully handled and no further effort is required.
>
> This is poorly worded I think.

Well, so here is a patch to fix this in the kernel documentation (IO
documentation seems to be OK):

Index: packages/kernel/current/ChangeLog
===================================================================
RCS file: /cvs/ecos/ecos/packages/kernel/current/ChangeLog,v
retrieving revision 1.127
diff -u -r1.127 ChangeLog
--- packages/kernel/current/ChangeLog	23 Oct 2005 14:53:38 -0000	1.127
+++ packages/kernel/current/ChangeLog	23 Nov 2005 19:03:36 -0000
@@ -1,3 +1,8 @@
+2005-11-23  Sergei Organov  <osv@javad.com>
+
+	* doc/kernel.sgml: Fix description of CYG_ISR_CALL_DSR and
+	CYG_ISR_HANDLED. Fix example isr_function() accordingly.
+
 2005-10-23  Andrew Lunn  <andrew.lunn@ascom.ch>
 
 	* include/flag.hxx: We need thread.inl for the empty() function
Index: packages/kernel/current/doc/kernel.sgml
===================================================================
RCS file: /cvs/ecos/ecos/packages/kernel/current/doc/kernel.sgml,v
retrieving revision 1.11
diff -u -r1.11 kernel.sgml
--- packages/kernel/current/doc/kernel.sgml	14 Apr 2004 09:32:05 -0000	1.11
+++ packages/kernel/current/doc/kernel.sgml	23 Nov 2005 18:58:44 -0000
@@ -4380,7 +4380,9 @@
 
     &hellip;
 
-    return dsr_required ? CYG_ISR_CALL_DSR : CYG_ISR_HANDLED;
+    return dsr_required ?
+        (CYG_ISR_CALL_DSR | CYG_ISR_HANDLED) :
+        CYG_ISR_HANDLED;
 }
           </programlisting>
           <para>
@@ -4409,12 +4411,15 @@
 are especially important, so their ISRs will be as short as possible.
           </para>
           <para>
-The return value of an ISR is normally one of
+The return value of an ISR is normally a bit mask containing one or
+both of the following bits:
 <literal>CYG_ISR_CALL_DSR</literal> or
 <literal>CYG_ISR_HANDLED</literal>. The former indicates that further
 processing is required at DSR level, and the interrupt handler's DSR
 will be run as soon as possible. The latter indicates that the
-interrupt has been fully handled and no further effort is required.
+interrupt was handled by this ISR and is used by chained interrupts to
+determine if another ISR (which shares the same interrupt) should be
+run.
           </para>
           <para>
 An ISR is allowed to make very few kernel calls. It can manipulate the
@@ -4429,8 +4434,8 @@
           <term>cyg_DSR_t <parameter>dsr</parameter></term>
           <listitem><para>
 If an interrupt has occurred and the ISR has returned a value
-<literal>CYG_ISR_CALL_DSR</literal>, the system will call the
-deferred service routine or DSR associated with this interrupt
+with <literal>CYG_ISR_CALL_DSR</literal> bit being set, the system
+will call the DSR associated with this interrupt
 handler. If the scheduler is not currently locked then the DSR will
 run immediately. However if the interrupted thread was in the middle
 of a kernel call and had locked the scheduler, then the DSR will be

--
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] Informal eCos gathering at the San Jose Embedded Systems Conference this Wednesday!

[Andrew Greenberg]

Calling all eCos users at ESC 2006 this week:

Bill Gatliff is hosting a brown bag lunch on Wednesday from 1:00pm to
2:00pm called "Experiences in Embedded Linux". He'd like it to be an
open source free-for-all, so I'd like to invite all eCos users here at
the conference to come. I'll gather us all up after the conference to
meet and talk eCos... and if there's enough interest, maybe we can meet
for dinner after hours on Wednesday.

See everyone then!

Andrew

PS. And if you can't make the lunch, but would like to attend a dinner
event, then just email me.

-- 
-------------------------------------------------------
Andrew Greenberg

Portland State Aerospace Society (http://psas.pdx.edu/)
andrew@psas.pdx.edu  P: 503.788.1343  C: 503.708.7711
-------------------------------------------------------
	


-- 
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] Informal eCos gathering at the San Jose Embedded Systems Conference this Wednesday!

[Andrew Greenberg]

Calling all eCos users at ESC 2006 this week:

Bill Gatliff is hosting a brown bag lunch on Wednesday from 1:00pm to
2:00pm called "Experiences in Embedded Linux". He'd like it to be an
open source free-for-all, so I'd like to invite all eCos users here at
the conference to come. I'll gather us all up after the conference to
meet and talk eCos... and if there's enough interest, maybe we can meet
for dinner after hours on Wednesday.

See everyone then!

Andrew

PS. And if you can't make the lunch, but would like to attend a dinner
event, then just email me.

-- 
-------------------------------------------------------
Andrew Greenberg

Portland State Aerospace Society (http://psas.pdx.edu/)
andrew@psas.pdx.edu  P: 503.788.1343  C: 503.708.7711
-------------------------------------------------------
	

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