[ECOS] On Alarms...

[Jonathan Larmour]

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