[ECOS] cyg_thread_delay() trace!!

[ECOS] cyg_thread_delay() trace!!

[Satish Kumar]

Hi,
    i have programmed a timer for HAL_CLOCK_XXX routines..and when a 
cyg_thread_delay(x) is called in the twothreads.c program, therez no
response. my program hangs..!!
           can some body list out the trace how the HAL_CLOCK_XXXX
macros are called when i invoke a cyg_thread_delay(x) function. i m not
able to trace out clearly after it enters the sched.cxx file...

thanks
satish

-- 
Satish Kumar <satish@bvt.sc.sanyo.co.jp>


-- 
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] cyg_thread_delay() trace!!

[Gary Thomas]

On Thu, 2003-09-11 at 21:02, Satish Kumar wrote:
> Hi,
>     i have programmed a timer for HAL_CLOCK_XXX routines..and when a 
> cyg_thread_delay(x) is called in the twothreads.c program, therez no
> response. my program hangs..!!
>            can some body list out the trace how the HAL_CLOCK_XXXX
> macros are called when i invoke a cyg_thread_delay(x) function. i m not
> able to trace out clearly after it enters the sched.cxx file...

The call to 'cyg_thread_delay()' really has nothing to do with calls
to HAL_CLOCK_XXX.  What happens is your thread will be suspended (unable
to execute) pending the occurrence some number of clock ticks.  If there
are no other threads which can run at this point, then the idle thread
will be run.  In any case, when a clock interrupt occurs, 
HAL_CLOCK_RESET() will be called as part of the processing and a tick
will have taken place.  When enough ticks have gone by, your original 
thread will be allowed to resume, thus returning from the 
'cyg_thread_delay()' call.  Pretty standard, interrupt driven 
multi-threaded operations.

-- 
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] cyg_thread_delay() trace!!

[Satish Kumar]

well, that is fine..but my cyg_thread_delay(x) call  does not return
back..i have used 2 periodic timer supported by the target board.timer1
for HAL_CLOCK_XXX macros and timer2 for hal_delay_us() function.

     plz give me some hints to trace this cyg_thread_delay problem and
how to solve this..?

thanks,
satish

On 11 Sep 2003 21:08:39 -0600
Gary Thomas <gary@mlbassoc.com> wrote:

> On Thu, 2003-09-11 at 21:02, Satish Kumar wrote:
> > Hi,
> >     i have programmed a timer for HAL_CLOCK_XXX routines..and when a 
> > cyg_thread_delay(x) is called in the twothreads.c program, therez no
> > response. my program hangs..!!
> >            can some body list out the trace how the HAL_CLOCK_XXXX
> > macros are called when i invoke a cyg_thread_delay(x) function. i m not
> > able to trace out clearly after it enters the sched.cxx file...
> 
> The call to 'cyg_thread_delay()' really has nothing to do with calls
> to HAL_CLOCK_XXX.  What happens is your thread will be suspended (unable
> to execute) pending the occurrence some number of clock ticks.  If there
> are no other threads which can run at this point, then the idle thread
> will be run.  In any case, when a clock interrupt occurs, 
> HAL_CLOCK_RESET() will be called as part of the processing and a tick
> will have taken place.  When enough ticks have gone by, your original 
> thread will be allowed to resume, thus returning from the 
> 'cyg_thread_delay()' call.  Pretty standard, interrupt driven 
> multi-threaded operations.
> 
> -- 
> Gary Thomas <gary@mlbassoc.com>
> MLB Associates

-- 
Satish Kumar <satish@bvt.sc.sanyo.co.jp>


-- 
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] cyg_thread_delay() trace!!

[Gary Thomas]

On Thu, 2003-09-11 at 21:27, Satish Kumar wrote:
> well, that is fine..but my cyg_thread_delay(x) call  does not return
> back..i have used 2 periodic timer supported by the target board.timer1
> for HAL_CLOCK_XXX macros and timer2 for hal_delay_us() function.
> 
>      plz give me some hints to trace this cyg_thread_delay problem and
> how to solve this..?
> 

Start off by making sure that the clock interrupts are happening.
You should be able to set a breakpoint at Cyg_RealTimeClock::isr

Once that's working, you should be fine.

> thanks,
> satish
> 
> On 11 Sep 2003 21:08:39 -0600
> Gary Thomas <gary@mlbassoc.com> wrote:
> 
> > On Thu, 2003-09-11 at 21:02, Satish Kumar wrote:
> > > Hi,
> > >     i have programmed a timer for HAL_CLOCK_XXX routines..and when a 
> > > cyg_thread_delay(x) is called in the twothreads.c program, therez no
> > > response. my program hangs..!!
> > >            can some body list out the trace how the HAL_CLOCK_XXXX
> > > macros are called when i invoke a cyg_thread_delay(x) function. i m not
> > > able to trace out clearly after it enters the sched.cxx file...
> > 
> > The call to 'cyg_thread_delay()' really has nothing to do with calls
> > to HAL_CLOCK_XXX.  What happens is your thread will be suspended (unable
> > to execute) pending the occurrence some number of clock ticks.  If there
> > are no other threads which can run at this point, then the idle thread
> > will be run.  In any case, when a clock interrupt occurs, 
> > HAL_CLOCK_RESET() will be called as part of the processing and a tick
> > will have taken place.  When enough ticks have gone by, your original 
> > thread will be allowed to resume, thus returning from the 
> > 'cyg_thread_delay()' call.  Pretty standard, interrupt driven 
> > multi-threaded operations.
> > 
> > -- 
> > Gary Thomas <gary@mlbassoc.com>
> > MLB Associates
-- 
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] cyg_thread_delay() trace!!

[Satish Kumar]

Hi,

     Cyg_RealTimeClock::isr routine gets invoked when a
cyg_thread_delay(x) is called, but my program hangs after displaying
Entering twothreads’ cyg_user_start()
Beginning execution; thread data is 0
Beginning execution; thread data is 1

  what could be the problem..?
plz some one suggest some idea to over this problem.

thanks
satish

On 11 Sep 2003 21:31:26 -0600
Gary Thomas <gary@mlbassoc.com> wrote:

> On Thu, 2003-09-11 at 21:27, Satish Kumar wrote:
> > well, that is fine..but my cyg_thread_delay(x) call  does not return
> > back..i have used 2 periodic timer supported by the target board.timer1
> > for HAL_CLOCK_XXX macros and timer2 for hal_delay_us() function.
> > 
> >      plz give me some hints to trace this cyg_thread_delay problem and
> > how to solve this..?
> > 
> 
> Start off by making sure that the clock interrupts are happening.
> You should be able to set a breakpoint at Cyg_RealTimeClock::isr
> 
> Once that's working, you should be fine.
> 
> > thanks,
> > satish
> > 
> > On 11 Sep 2003 21:08:39 -0600
> > Gary Thomas <gary@mlbassoc.com> wrote:
> > 
> > > On Thu, 2003-09-11 at 21:02, Satish Kumar wrote:
> > > > Hi,
> > > >     i have programmed a timer for HAL_CLOCK_XXX routines..and when a 
> > > > cyg_thread_delay(x) is called in the twothreads.c program, therez no
> > > > response. my program hangs..!!
> > > >            can some body list out the trace how the HAL_CLOCK_XXXX
> > > > macros are called when i invoke a cyg_thread_delay(x) function. i m not
> > > > able to trace out clearly after it enters the sched.cxx file...
> > > 
> > > The call to 'cyg_thread_delay()' really has nothing to do with calls
> > > to HAL_CLOCK_XXX.  What happens is your thread will be suspended (unable
> > > to execute) pending the occurrence some number of clock ticks.  If there
> > > are no other threads which can run at this point, then the idle thread
> > > will be run.  In any case, when a clock interrupt occurs, 
> > > HAL_CLOCK_RESET() will be called as part of the processing and a tick
> > > will have taken place.  When enough ticks have gone by, your original 
> > > thread will be allowed to resume, thus returning from the 
> > > 'cyg_thread_delay()' call.  Pretty standard, interrupt driven 
> > > multi-threaded operations.
> > > 
> > > -- 
> > > Gary Thomas <gary@mlbassoc.com>
> > > MLB Associates
> -- 
> Gary Thomas <gary@mlbassoc.com>
> MLB Associates

-- 
Satish Kumar <satish@bvt.sc.sanyo.co.jp>


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