Re: [ECOS] On Alarms...

[Jonathan Larmour <jifl at eCosCentric dot com>]

Robert Cragie wrote:
>Jonathan Larmour wrote:
> > Milind Kopikare wrote:
> >
> > > 2> I was trying to toggle between starting a thread
> > > and suspending it using an Alarm.
> > > void alarm_func(){
> > >   if (thread is suspended)
> > >       cyg_thread_resume
> > >   else
> > >       cyg_thread_suspend
> > > }
> > > But if I keep the Alarm resolution too small, say the
> > > Alarm triggers every 2 ticks (2*10ms), the thread does
> > > not resume. It's as if the scheduler is taking more
> > > than 2 ms to start the thread. Any insight into what's
> > > wrong? Ofcourse, if I give the ALARM resolution as
> > > 100ms (10ticks), the thread toggles allright.
> > Just on the off-chance, is the thread doing any diagnostic output,
> > especially via GDB? If so, interrupts will be disabled while the
> > output is
> > performed which could easily be up to 2 ticks. Diagnostic output
> > shouldn't
> > be used for "real" applications - use proper interrupt-driven
> > drivers instead.
>
> Surely you have to apply the rule that no function which can potentially
> block can be called in a DSR callback?  I remember initially having quite a
> few problems using interrupt driven driver calls in alarm callbacks, which
> all went away when I followed the rules for DSR callbacks, as outlined in
> http://sources.redhat.com/ecos/docs-latest/ref/ecos-ref.7.html#33307
That's true, although resuming/suspending a thread from a DSR should work, 
if their alarm_func() above is truly representative.

Jifl
--
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


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