[ECOS] context for creating interrupts on edb7312

[ECOS] context for creating interrupts on edb7312

[Aaron Case]

Hello,

My question pertains to the context for which an interrupt would be created
and attached.

The Massa text shows an example where an interrupt is created, attached, and
unmasked in cyg_user_start(), see code listing 3.2. Yet 3 pages later, see
Item list 3.7, it gives thread(and not init as in the code listing) as the
only viable context for creating a interrupt(via cyg_interrupt_create).
This seems to be in conflict.

Intuitively, creation of interrupts would be in cyg_user_start, init
context, like the code listing example BUT, I was never able to get this to
work. I have however been able to get work in the thread context, which
agrees with the item list but seems counter intuitive.

The eCos reference manual confirms my intuition by stating the following in
the valid context section of the ref manual...

"In a typical configuration interrupt handlers are created and attached
during system initialization, and never detached or deleted. However it is
possible to perform these operations at thread level, if desired..."

I, however, have not be able to get interrupts to work in the init context,
only in the thread context.

------Is creating interrupts within the init context possible?-------

I am using the EDB7312 processor with the arm720t core.

I would prefer to locate all interrupt creation and configuration in
cyg_user_start, the init context, but have had little success in doing so.

I would also like to add, Im not criticizing the online docs, they appear
correct, just a bit generic(so as to apply to all platforms, I assume).

Aaron Case
Firmware Engineer
Dynazign, Inc.
Charlotte, NC


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

Re: [ECOS] context for creating interrupts on edb7312

[Gary Thomas]

On Wed, 2003-11-19 at 09:34, Aaron Case wrote:
> Hello,
> 
> My question pertains to the context for which an interrupt would be created
> and attached.
> 
> The Massa text shows an example where an interrupt is created, attached, and
> unmasked in cyg_user_start(), see code listing 3.2. Yet 3 pages later, see
> Item list 3.7, it gives thread(and not init as in the code listing) as the
> only viable context for creating a interrupt(via cyg_interrupt_create).
> This seems to be in conflict.
> 
> Intuitively, creation of interrupts would be in cyg_user_start, init
> context, like the code listing example BUT, I was never able to get this to
> work. I have however been able to get work in the thread context, which
> agrees with the item list but seems counter intuitive.
> 
> The eCos reference manual confirms my intuition by stating the following in
> the valid context section of the ref manual...
> 
> "In a typical configuration interrupt handlers are created and attached
> during system initialization, and never detached or deleted. However it is
> possible to perform these operations at thread level, if desired..."
> 
> I, however, have not be able to get interrupts to work in the init context,
> only in the thread context.
> 
> ------Is creating interrupts within the init context possible?-------
> 

What do you mean "creating" interrupts?  Do you mean actually fielding 
them (when they occur)?  In that case, no, since interrupts are not
turned on (enabled) until you call the scheduler.

> I am using the EDB7312 processor with the arm720t core.
> 
> I would prefer to locate all interrupt creation and configuration in
> cyg_user_start, the init context, but have had little success in doing so.
> 

Can you explain what you mean by this?

> I would also like to add, Im not criticizing the online docs, they appear
> correct, just a bit generic(so as to apply to all platforms, I assume).

As is should be (IMO) since the notions of interrupts and handlers are
platform independent (while what causes the interrupts, which ones are
hooked to which devices, etc, are target specific)

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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

RE: [ECOS] context for creating interrupts on edb7312

[Aaron Case]

>
> ------Is creating interrupts within the init context possible?-------
>

What do you mean "creating" interrupts?  Do you mean actually fielding
them (when they occur)?  In that case, no, since interrupts are not
turned on (enabled) until you call the scheduler.

a call(s) to cyg_interrupt_create()

> I am using the EDB7312 processor with the arm720t core.
>
> I would prefer to locate all interrupt creation and configuration in
> cyg_user_start, the init context, but have had little success in doing so.
>

Can you explain what you mean by this?

Calls to cyg_interrupt_create(), cyg_intterrupt_attach(), and
cyg_interrupt_unmask() that create and configure the interrupt structure of
the system.



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

RE: [ECOS] context for creating interrupts on edb7312

[Gary Thomas]

On Wed, 2003-11-19 at 13:22, Aaron Case wrote:
> >
> > ------Is creating interrupts within the init context possible?-------
> >
> 
> What do you mean "creating" interrupts?  Do you mean actually fielding
> them (when they occur)?  In that case, no, since interrupts are not
> turned on (enabled) until you call the scheduler.
> 
> a call(s) to cyg_interrupt_create()
> 
> > I am using the EDB7312 processor with the arm720t core.
> >
> > I would prefer to locate all interrupt creation and configuration in
> > cyg_user_start, the init context, but have had little success in doing so.
> >
> 
> Can you explain what you mean by this?
> 
> Calls to cyg_interrupt_create(), cyg_intterrupt_attach(), and
> cyg_interrupt_unmask() that create and configure the interrupt structure of
> the system.

Look at the timer test I just committed: 
  hal/powerpc/mpc8xxx/current/tests/mpc8xxx_timer.c
It creates, attaches, etc, an interrupt during cyg_user_start()
and then tests that it works.  It does work fine, BTW.

How is this example different from what you are trying to do?

n.b. Please be more careful when replying to emails - it was difficult 
to determine what you quoted from my message and what you typed (in 
fact, had I not typed it myself, I would not have been able to tell)

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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

RE: [ECOS] context for creating interrupts on edb7312

[Aaron Case]

> Look at the timer test I just committed:
>   hal/powerpc/mpc8xxx/current/tests/mpc8xxx_timer.c
> It creates, attaches, etc, an interrupt during cyg_user_start()
> and then tests that it works.  It does work fine, BTW.
>
> How is this example different from what you are trying to do?
>

The only real difference is the main_thread.

What mechanisms start the scheduler in the default eCos package? I cant seem
to get interrupts to work without a explicit call to start the scheduler,
but I know when I include the main thread(by calling cyg_thread_create and
cyg_thread_resume) the scheduler starts.

So in an effort to better understand eCos(not to try to run a rtos without a
scheduler) what could indirectly start the scheduler(other than your call to
cyg_scheduler_start)?  It seems to start on its own with thread
initialization on my system.

Thanks,
Aaron Case


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

RE: [ECOS] context for creating interrupts on edb7312

[Gary Thomas]

On Thu, 2003-11-20 at 07:25, Aaron Case wrote:
> > Look at the timer test I just committed:
> >   hal/powerpc/mpc8xxx/current/tests/mpc8xxx_timer.c
> > It creates, attaches, etc, an interrupt during cyg_user_start()
> > and then tests that it works.  It does work fine, BTW.
> >
> > How is this example different from what you are trying to do?
> >
> 
> The only real difference is the main_thread.
> 
> What mechanisms start the scheduler in the default eCos package? I cant seem
> to get interrupts to work without a explicit call to start the scheduler,
> but I know when I include the main thread(by calling cyg_thread_create and
> cyg_thread_resume) the scheduler starts.
> 
> So in an effort to better understand eCos(not to try to run a rtos without a
> scheduler) what could indirectly start the scheduler(other than your call to
> cyg_scheduler_start)?  It seems to start on its own with thread
> initialization on my system.

It happens automatically in "cyg_start()", so my test runs just as well
even if I make this change:

Index: hal/powerpc/mpc8xxx/current/tests/mpc8xxx_timer.c
===================================================================
RCS file:
/home/gthomas/my_cvs/develop/ecos/packages/hal/powerpc/mpc8xxx/current/tests/mpc8xxx_timer.c,v
retrieving revision 1.1
diff -u -5 -p -r1.1 mpc8xxx_timer.c
--- hal/powerpc/mpc8xxx/current/tests/mpc8xxx_timer.c   20 Nov 2003
14:21:54 -0000      1.1
+++ hal/powerpc/mpc8xxx/current/tests/mpc8xxx_timer.c   20 Nov 2003
14:29:39 -0000
@@ -149,12 +149,12 @@ cyg_user_start( void )
     IMM->cpm_timers_trr1 = 0x2000;  // Reference value 
     IMM->cpm_timers_tcn1 = 0;
     IMM->cpm_timers_ter[0] = 0xFF;
     IMM->cpm_timers_tgcr1 = _TC_TGCR_RST1;  // Reset & enable timer1
 
-    cyg_scheduler_start();
-    CYG_TEST_PASS("mpc8xxx_timer");
+//    cyg_scheduler_start();
+//    CYG_TEST_PASS("mpc8xxx_timer");
 }
 
 //
-------------------------------------------------------------------------
 
 #else  // ! CYGPKG_KERNEL

Are you overriding "cyg_start()"?  That's the place that the scheduler
is normally started (although many of our tests do it explicitly)

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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

RE: [ECOS] context for creating interrupts on edb7312

[Aaron Case]

> It happens automatically in "cyg_start()", so my test runs just as well
> even if I make this change:
>
> Index: hal/powerpc/mpc8xxx/current/tests/mpc8xxx_timer.c
> ===================================================================
> RCS file:
> /home/gthomas/my_cvs/develop/ecos/packages/hal/powerpc/mpc8xxx/cur
> rent/tests/mpc8xxx_timer.c,v
> retrieving revision 1.1
> diff -u -5 -p -r1.1 mpc8xxx_timer.c
> --- hal/powerpc/mpc8xxx/current/tests/mpc8xxx_timer.c   20 Nov 2003
> 14:21:54 -0000      1.1
> +++ hal/powerpc/mpc8xxx/current/tests/mpc8xxx_timer.c   20 Nov 2003
> 14:29:39 -0000
> @@ -149,12 +149,12 @@ cyg_user_start( void )
>      IMM->cpm_timers_trr1 = 0x2000;  // Reference value
>      IMM->cpm_timers_tcn1 = 0;
>      IMM->cpm_timers_ter[0] = 0xFF;
>      IMM->cpm_timers_tgcr1 = _TC_TGCR_RST1;  // Reset & enable timer1
>
> -    cyg_scheduler_start();
> -    CYG_TEST_PASS("mpc8xxx_timer");
> +//    cyg_scheduler_start();
> +//    CYG_TEST_PASS("mpc8xxx_timer");
>  }
>
>  //
> -------------------------------------------------------------------------
>
>  #else  // ! CYGPKG_KERNEL
>
> Are you overriding "cyg_start()"?  That's the place that the scheduler
> is normally started (although many of our tests do it explicitly)
>
> --
> Gary Thomas <gary@mlbassoc.com>
> MLB Associates
>
>

Thanks for the clarification. I believe this may be my last question on the
matter.

Is it possible to enable interrupts with cyg_interrupt_enable(), before the
task scheduler starts, supposing I were foolish enough to do such a thing?

It appears that cyg_interrupt_enable() acts directly on the CPSR in
ARM(after viewing the ASM), but my MAJIC debugger tells me that the CPSR
doesn't change unless the scheduler is started. So what in eCos blocks
access to the interrupt bits in the CPSR when the scheduler is not running?


Thanks,
Aaron Case



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

RE: [ECOS] context for creating interrupts on edb7312

[Gary Thomas]

On Thu, 2003-11-20 at 08:01, Aaron Case wrote:
> > It happens automatically in "cyg_start()", so my test runs just as well
> > even if I make this change:
> >
> > Index: hal/powerpc/mpc8xxx/current/tests/mpc8xxx_timer.c
> > ===================================================================
> > RCS file:
> > /home/gthomas/my_cvs/develop/ecos/packages/hal/powerpc/mpc8xxx/cur
> > rent/tests/mpc8xxx_timer.c,v
> > retrieving revision 1.1
> > diff -u -5 -p -r1.1 mpc8xxx_timer.c
> > --- hal/powerpc/mpc8xxx/current/tests/mpc8xxx_timer.c   20 Nov 2003
> > 14:21:54 -0000      1.1
> > +++ hal/powerpc/mpc8xxx/current/tests/mpc8xxx_timer.c   20 Nov 2003
> > 14:29:39 -0000
> > @@ -149,12 +149,12 @@ cyg_user_start( void )
> >      IMM->cpm_timers_trr1 = 0x2000;  // Reference value
> >      IMM->cpm_timers_tcn1 = 0;
> >      IMM->cpm_timers_ter[0] = 0xFF;
> >      IMM->cpm_timers_tgcr1 = _TC_TGCR_RST1;  // Reset & enable timer1
> >
> > -    cyg_scheduler_start();
> > -    CYG_TEST_PASS("mpc8xxx_timer");
> > +//    cyg_scheduler_start();
> > +//    CYG_TEST_PASS("mpc8xxx_timer");
> >  }
> >
> >  //
> > -------------------------------------------------------------------------
> >
> >  #else  // ! CYGPKG_KERNEL
> >
> > Are you overriding "cyg_start()"?  That's the place that the scheduler
> > is normally started (although many of our tests do it explicitly)
> >
> > --
> > Gary Thomas <gary@mlbassoc.com>
> > MLB Associates
> >
> >
> 
> Thanks for the clarification. I believe this may be my last question on the
> matter.
> 
> Is it possible to enable interrupts with cyg_interrupt_enable(), before the
> task scheduler starts, supposing I were foolish enough to do such a thing?
> 
> It appears that cyg_interrupt_enable() acts directly on the CPSR in
> ARM(after viewing the ASM), but my MAJIC debugger tells me that the CPSR
> doesn't change unless the scheduler is started. So what in eCos blocks
> access to the interrupt bits in the CPSR when the scheduler is not running?

Nothing - remember eCos is pretty light weight; you can do most anything
you want at any time.  That said, it's not a good idea to be messing 
around with the interrupts and you should never blindly just enable them
(unless you want a broken system!)

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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

RE: [ECOS] context for creating interrupts on edb7312

[Aaron Case]

> > It appears that cyg_interrupt_enable() acts directly on the CPSR in
> > ARM(after viewing the ASM), but my MAJIC debugger tells me that the CPSR
> > doesn't change unless the scheduler is started. So what in eCos blocks
> > access to the interrupt bits in the CPSR when the scheduler is
> not running?
>
> Nothing - remember eCos is pretty light weight; you can do most anything
> you want at any time.  That said, it's not a good idea to be messing
> around with the interrupts and you should never blindly just enable them
> (unless you want a broken system!)
>
> --
> Gary Thomas <gary@mlbassoc.com>
> MLB Associates
>
>

Ok, I see now that cyg_interrupt_enable runs checks before enabling
interrupts to prevent you from hosing the hole system.

So that I can hose my system fully, I have one last question.

(Last question) Where is the attachment between the generic call
cyg_interrupt_enable()  and the hardware specific hal_interrupts_enable
macro in vectors.S?

Im looking for something along the lines of #define hal_interrupts_enable
cyg_interrupt_enable().

Thanks,
Aaron Case








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

RE: [ECOS] context for creating interrupts on edb7312

[Gary Thomas]

On Fri, 2003-11-21 at 08:06, Aaron Case wrote:
> > > It appears that cyg_interrupt_enable() acts directly on the CPSR in
> > > ARM(after viewing the ASM), but my MAJIC debugger tells me that the CPSR
> > > doesn't change unless the scheduler is started. So what in eCos blocks
> > > access to the interrupt bits in the CPSR when the scheduler is
> > not running?
> >
> > Nothing - remember eCos is pretty light weight; you can do most anything
> > you want at any time.  That said, it's not a good idea to be messing
> > around with the interrupts and you should never blindly just enable them
> > (unless you want a broken system!)
> >
> > --
> > Gary Thomas <gary@mlbassoc.com>
> > MLB Associates
> >
> >
> 
> Ok, I see now that cyg_interrupt_enable runs checks before enabling
> interrupts to prevent you from hosing the hole system.
> 
> So that I can hose my system fully, I have one last question.
> 
> (Last question) Where is the attachment between the generic call
> cyg_interrupt_enable()  and the hardware specific hal_interrupts_enable
> macro in vectors.S?
> 
> Im looking for something along the lines of #define hal_interrupts_enable
> cyg_interrupt_enable().

Actually, there is no explicit call like this (anymore).  Interrupts 
will get enabled when the scheduler "starts" the first thread (minimally
the 'idle' thread).  Thread contexts are initialized with interrupts 
enabled and this just sort of falls out with the washing :-)

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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

RE: [ECOS] context for creating interrupts on edb7312

[Aaron Case]

> >
> > Im looking for something along the lines of #define
> hal_interrupts_enable
> > cyg_interrupt_enable().
>
> Actually, there is no explicit call like this (anymore).  Interrupts
> will get enabled when the scheduler "starts" the first thread (minimally
> the 'idle' thread).  Thread contexts are initialized with interrupts
> enabled and this just sort of falls out with the washing :-)
>
> --
> Gary Thomas <gary@mlbassoc.com>
> MLB Associates
>
>

Gary,

Thanks for the prompt answer. I was speaking more in the context of linking
and compiling the image.

I see that a call to enable interrupts is not necessary when threads are
initialized.

I also see the cyg_interrupt_enable in the map file, which jumps to the
hal_interrupts_enable( from vector.S but not in the map file) code in the
application.

Thanks and Regards,
Aaron Case


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

RE: [ECOS] context for creating interrupts on edb7312

[Gary Thomas]

On Fri, 2003-11-21 at 09:32, Aaron Case wrote:
> > >
> > > Im looking for something along the lines of #define
> > hal_interrupts_enable
> > > cyg_interrupt_enable().
> >
> > Actually, there is no explicit call like this (anymore).  Interrupts
> > will get enabled when the scheduler "starts" the first thread (minimally
> > the 'idle' thread).  Thread contexts are initialized with interrupts
> > enabled and this just sort of falls out with the washing :-)
> >
> > --
> > Gary Thomas <gary@mlbassoc.com>
> > MLB Associates
> >
> >
> 
> Gary,
> 
> Thanks for the prompt answer. I was speaking more in the context of linking
> and compiling the image.
> 
> I see that a call to enable interrupts is not necessary when threads are
> initialized.
> 
> I also see the cyg_interrupt_enable in the map file, which jumps to the
> hal_interrupts_enable( from vector.S but not in the map file) code in the
> application.

I'm not sure I understand what you mean by this (in the map file?), but 
if a function isn't used (cyg_interrupt_enable() is not used by the 
kernel except for a single test), then even if that function is defined
it doesn't end up in the resulting application.

IMO there is absolutely no need to ever call cyg_interrupt_enable(), 
except for the kernel test which tests it.

If you need to manipulate the interrupt state (and there are very few
cases even for this), this is a better approach:

   cyg_uint32 state;
   HAL_DISABLE_INTERRUPTS(state);   // Disables interrupts
     ...
   HAL_RESTORE_INTERRUPTS(state);   // Restore interrupts 

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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

RE: [ECOS] context for creating interrupts on edb7312

[Gary Thomas]

On Fri, 2003-11-21 at 10:22, Gary Thomas wrote:
> On Fri, 2003-11-21 at 09:32, Aaron Case wrote:
> > > >
> > > > Im looking for something along the lines of #define
> > > hal_interrupts_enable
> > > > cyg_interrupt_enable().
> > >
> > > Actually, there is no explicit call like this (anymore).  Interrupts
> > > will get enabled when the scheduler "starts" the first thread (minimally
> > > the 'idle' thread).  Thread contexts are initialized with interrupts
> > > enabled and this just sort of falls out with the washing :-)
> > >
> > > --
> > > Gary Thomas <gary@mlbassoc.com>
> > > MLB Associates
> > >
> > >
> > 
> > Gary,
> > 
> > Thanks for the prompt answer. I was speaking more in the context of linking
> > and compiling the image.
> > 
> > I see that a call to enable interrupts is not necessary when threads are
> > initialized.
> > 
> > I also see the cyg_interrupt_enable in the map file, which jumps to the
> > hal_interrupts_enable( from vector.S but not in the map file) code in the
> > application.
> 
> I'm not sure I understand what you mean by this (in the map file?), but 
> if a function isn't used (cyg_interrupt_enable() is not used by the 
> kernel except for a single test), then even if that function is defined
> it doesn't end up in the resulting application.
> 
> IMO there is absolutely no need to ever call cyg_interrupt_enable(), 
> except for the kernel test which tests it.
> 
> If you need to manipulate the interrupt state (and there are very few
> cases even for this), this is a better approach:
> 
>    cyg_uint32 state;
>    HAL_DISABLE_INTERRUPTS(state);   // Disables interrupts
>      ...
>    HAL_RESTORE_INTERRUPTS(state);   // Restore interrupts 

Or, even better when writing device drivers:

   cyg_drv_isr_lock();
     ...
   cyg_drv_isr_unlock();

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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

RE: [ECOS] context for creating interrupts on edb7312

[Aaron Case]

Aaron Case<aaron.case@dynazign.com>
Firmware Engineer
Dynazign, Inc.
Charlotte, USA

> -----Original Message-----
> From: Gary Thomas [mailto:gary@mlbassoc.com]
> Sent: Friday, November 21, 2003 12:28 PM
> To: Aaron Case
> Cc: Ecos-Discuss
> Subject: RE: [ECOS] context for creating interrupts on edb7312
>
>
> On Fri, 2003-11-21 at 10:22, Gary Thomas wrote:
> > On Fri, 2003-11-21 at 09:32, Aaron Case wrote:
> > > > >
> > > > > Im looking for something along the lines of #define
> > > > hal_interrupts_enable
> > > > > cyg_interrupt_enable().
> > > >
> > > > Actually, there is no explicit call like this (anymore).  Interrupts
> > > > will get enabled when the scheduler "starts" the first
> thread (minimally
> > > > the 'idle' thread).  Thread contexts are initialized with interrupts
> > > > enabled and this just sort of falls out with the washing :-)
> > > >
> > > > --
> > > > Gary Thomas <gary@mlbassoc.com>
> > > > MLB Associates
> > > >
> > > >
> > >
> > > Gary,
> > >
> > > Thanks for the prompt answer. I was speaking more in the
> context of linking
> > > and compiling the image.
> > >
> > > I see that a call to enable interrupts is not necessary when
> threads are
> > > initialized.
> > >
> > > I also see the cyg_interrupt_enable in the map file, which
> jumps to the
> > > hal_interrupts_enable( from vector.S but not in the map file)
> code in the
> > > application.
> >
> > I'm not sure I understand what you mean by this (in the map file?), but
> > if a function isn't used (cyg_interrupt_enable() is not used by the
> > kernel except for a single test), then even if that function is defined
> > it doesn't end up in the resulting application.
> >
> > IMO there is absolutely no need to ever call cyg_interrupt_enable(),
> > except for the kernel test which tests it.
> >
> > If you need to manipulate the interrupt state (and there are very few
> > cases even for this), this is a better approach:
> >
> >    cyg_uint32 state;
> >    HAL_DISABLE_INTERRUPTS(state);   // Disables interrupts
> >      ...
> >    HAL_RESTORE_INTERRUPTS(state);   // Restore interrupts
>
> Or, even better when writing device drivers:
>
>    cyg_drv_isr_lock();
>      ...
>    cyg_drv_isr_unlock();
>
> --
> Gary Thomas <gary@mlbassoc.com>
> MLB Associates
>
>

Ok, Ive got it worked out now.

Thanks,
Aaron Case


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

[ECOS] context for creating interrupts on edb7312

[amassa]

Hi Aaron,

You are right about the interrupt create context.  It should be Init/Thread
That's an error in the text.  Thanks for catching it.  I'll make a note of
it.

Regards,
Anthony

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .



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