[ECOS] Re: def_alm problem in uitron v3.0

[Jonathan Larmour <jifl at eCosCentric dot com>]

Lokesh Babu K. wrote:
> Hi Larmour
>
> Thanks for your inputs, I was able to install ecos2.0 successfully.
Good. In future, for general help requests like this, can you e-mail the 
ecos-discuss list first. I read that and can reply. In particular for the 
below, I'm not a uItron expert, but others on the list are. For example 
they may have the specs, and I don't! So they may help when I cannot.

> I have a doubt in Timer Management functions. Right now iam using
> uITRONv3.0.
> 1.In my application during timerinit i try to define alarm system call using
> def_alm and then during timershutdown i try to finish the invoked alarm
> handler using ret_tmr.
> After shutdown also alarm handler is getting invoked.
> Is there a way to stop it. In uITRONv4.0 we have del_alm to make alarm
> handler to move to non operational state. Is there any similar function in
> uITRONv3.0.
Not defined in the specification certainly.

Unofficially, you could add your own extension to do this. Look at the 
definition of the def_alm and ref_alm functions in 
compat/uitron/current/include/uit_func.inl. You need to do something 
similar. I would suggest adding something like:


CYG_UIT_FUNC_INLINE
ER
lokesh_del_alm ( HNO almno )
{
    Cyg_Timer *p;

    CYG_UITRON_CHECK_AND_GETHDLR( ALARMS, almno, p );
    CYG_UIT_PARAMCHECK( p->is_initialized(), E_NOEXS);

    Cyg_Scheduler::lock();
    p->activate( Cyg_Timer::DISABLE );
    Cyg_Scheduler::unlock();
    return E_OK;
}

That's just written off the top of my head though. But for all I know this 
would be the correct definition of uItron 4.0 del_alm :-). I don't have 
the uItron 4.0 spec. I don't have _any_ uItron spec :-).

> 2.In my timershutdown ret_tmr returns some value and the control comes out.
> what is the return value for it to be success?
I don't have a uItron spec, but I can tell you that in eCos when you 
return from a timer handler by calling ret_tmr(); there are no return values.

If you know the uItron spec indicates it should be something different, 
you'll have to quote me it.

Jifl

> -----Original Message-----
> From: Jonathan Larmour [mailto:jifl@jifvik.org]
> Sent: Wednesday, July 31,2002 8:40 AM
> To: lokeshbk@future.futsoft.com
> Subject: Re: MALLOC failure in ecos-1.3.1
>
>
> Lokesh Babu K. wrote:
>
> > /opt/ecos/ecos-1.3.1/packages/hal/synth/arch/current/src/synth_diag.c:119:
> > `CYG_HAL_SYS_EINTR' undeclared (first use in this function)
> > /opt/ecos/ecos-1.3.1/packages/hal/synth/arch/current/src/synth_diag.c:119:
> > `CYG_HAL_SYS_EAGAIN' undeclared (first use in this function)
>
> These are defined in hal/synth/arch/current/include/hal_io.h. Firstly are
> you using a clean empty build tree to start with? Secondly, can you check
> install/include/hal_io.h inside your build tree after the make fails and
> see if it includes CYG_HAL_SYS_EINTR and CYG_HAL_SYS_EAGAIN.
>
> Lastly, if that fails, then cd into hal/synth/arch/current in your build
> tree. If you type "make" there, you will see the gcc build line and the
> same error as before. Cut and paste the gcc build line, but add -v
> --save-temps, and send me the .ii file created and the screen output.
> Note, do this last since I'm not interested until you can tell me about
> the hal_io.h in the previous paragraph.
>
> Jifl

--
--[ "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