[ECOS] Re: Waiting I/O operation

[ECOS] Re: Waiting I/O operation

[cetoni GmbH - Uwe Kindler]

Hello Alexey,

In my opinion you should go with the second thread solution. If you use 
callbacks, then this callback will be called from the CAN I/O driver in 
DSR context. If your thread waits for multiple events then you need to 
use flags to signal the received CAN event.

I don't know if it is allowed to use flags from within DSRs but I 
believe you can not use them and then also a callback solution would not 
solve your problem. Your callback would need to wakup a "service thread" 
that would signal the flag to the waiting thread - but then you would 
also need two threads.

Or what would you do in this callback to wake up the thead - maybe I 
missed something?

Regards, Uwe





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

[ECOS] Re: Waiting I/O operation

[Alexey Shusharin]

cetoni GmbH - Uwe Kindler wrote:
> In my opinion you should go with the second thread solution.

Maybe. But in this variant I have a delay in receiving messages and 
useless processor working. :-( It seems that it will be better if I 
donate a memory for the second thread.

> I don't know if it is allowed to use flags from within DSRs but I 
> believe you can not use them and then also a callback solution would not 
> solve your problem. Your callback would need to wakup a "service thread" 
> that would signal the flag to the waiting thread - but then you would 
> also need two threads.

Why I can't use flags in DSR?
I think, I can't wait in DSR but I'm able to use cyg_flag_setbits() for 
wake-up thread. And my thread will call cyg_flag_wait() for waiting this 
and some other flags.

Regards,
Alexey

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

[ECOS] Re: Waiting I/O operation

[cetoni GmbH - Uwe Kindler]

Hello Alexey,

if it is allowed to set flags from DSR (is there a documentation about 
this somewhere?!?) I would agree with the callback solution.

You could implement support for registering callback functions at 
runtime by calling cyg_io_set_config. The callback function should be 
called by CAN I/O layer after the received event is stored into the 
event queue. Support for callback functions should be configurable via CDL.

In the callback function you could call cyg_flag_setbits() to signal the 
thread that a new event was received.

Regards, Uwe


Dipl. Inf. (FH)
Uwe Kindler
Software Engineering

--

cetoni GmbH
Am Wiesenring 6
D-07554 Korbussen

Tel.: +49 (0) 36602 338 28
Fax:  +49 (0) 36602 338 11
uwe.kindler@cetoni.de
www.cetoni.de

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

Re: [ECOS] Re: Waiting I/O operation

[Alexey Shusharin]

cetoni GmbH - Uwe Kindler wrote:
> if it is allowed to set flags from DSR (is there a documentation about 
> this somewhere?!?) I would agree with the callback solution.

http://ecos.sourceware.org/docs-latest/ref/kernel-flags.html :-)

> You could implement support for registering callback functions at 
> runtime by calling cyg_io_set_config. The callback function should be 
> called by CAN I/O layer after the received event is stored into the 
> event queue. Support for callback functions should be configurable via CDL.

Great, it seems good solution. I'm going to use CDL option for this 
changes and setup callbacks through cyg_io_set_config() too.

Regards
Alexey

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

[ECOS] Re: Waiting I/O operation

[Alexey Shusharin]

Alexey Shusharin wrote:
> cetoni GmbH - Uwe Kindler wrote:
>> In my opinion you should go with the second thread solution.
> 
> Maybe. But in this variant I have a delay in receiving messages and 
> useless processor working. :-( It seems that it will be better if I 
> donate a memory for the second thread.

Sorry Uwe, I've missed the word "thread". You offer the same variant.
:-)

Regards
Alexey

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

Re: [ECOS] Re: Waiting I/O operation

[Sergei Gavrikov]

Alexey Shusharin writes:
> cetoni GmbH - Uwe Kindler wrote:
> > In my opinion you should go with the second thread solution.
> 
> Maybe. But in this variant I have a delay in receiving messages and 
> useless processor working. :-( It seems that it will be better if I 
> donate a memory for the second thread.
> 
> > I don't know if it is allowed to use flags from within DSRs but I 
> > believe you can not use them and then also a callback solution would not 
> > solve your problem. Your callback would need to wakup a "service thread" 
> > that would signal the flag to the waiting thread - but then you would 
> > also need two threads.
> 
> Why I can't use flags in DSR?
> I think, I can't wait in DSR but I'm able to use cyg_flag_setbits() for 
> wake-up thread. And my thread will call cyg_flag_wait() for waiting this 
> and some other flags.
> Regards,
> Alexey

According the eCos reference manual (Synchronization Levels), they do
tell us that the synchro things are suitable for the DSRs are the
cyg_drv_cond_signal() and cyg_drv_cond_broadcast() only. The thread's
deal is to wait a condition using cyg_drv_cond_wait().

But, one my today DSR uses the cyg_flag_setbits() notifier and that
works as I could expect. I found that is more simple, because that
doesn't need itself in a mutex. I wonder about the right hacking from
the eCos experts.

Sergei




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

Re: [ECOS] Re: Waiting I/O operation

[Andrew Lunn]

> But, one my today DSR uses the cyg_flag_setbits() notifier and that
> works as I could expect. I found that is more simple, because that
> doesn't need itself in a mutex. I wonder about the right hacking from
> the eCos experts.

You are not allowed to block in a DSR. So look through the
cyg_flag_setbits() code and see if it calls any functions to block
itself. 

        Andrew

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

Re: [ECOS] Re: Waiting I/O operation

[Sergei Gavrikov]

On Fri, Jul 20, 2007 at 09:35:16PM +0200, Andrew Lunn wrote:
> > But, one my today DSR uses the cyg_flag_setbits() notifier and that
> > works as I could expect. I found that is more simple, because that
> > doesn't need itself in a mutex. I wonder about the right hacking from
> > the eCos experts.
> 
> You are not allowed to block in a DSR. So look through the
> cyg_flag_setbits() code and see if it calls any functions to block
> itself. 
> 
>         Andrew


Andrew, I looked the implementation and I see this now. I'll review
my code. 

Sincerely speaking, I did think that setbits implementation is something
simple thing like the flag maskbits operation :-) More that, grepped
through the eCos io/ and devs/ I did meet no cyg_flag operations at all,
but, there are enough the cyg_cond_*() synchronization calls there.

Thanks!

	Sergei

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

Re: [ECOS] Re: Waiting I/O operation

[Uwe Kindler]

This is what the documentation says about flags and DSRs:

http://ecos.sourceware.org/docs-latest/ref/kernel-flags.html

So it seems to be possible to use cyg_flag_setbits() from DSRs.

Andrew Lunn schrieb:
>> But, one my today DSR uses the cyg_flag_setbits() notifier and that
>> works as I could expect. I found that is more simple, because that
>> doesn't need itself in a mutex. I wonder about the right hacking from
>> the eCos experts.
> 
> You are not allowed to block in a DSR. So look through the
> cyg_flag_setbits() code and see if it calls any functions to block
> itself. 
> 
>         Andrew

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

Re: [ECOS] Re: Waiting I/O operation

[Sergei Gavrikov]

On Sat, Jul 21, 2007 at 03:19:55PM +0200, Uwe Kindler wrote:
> This is what the documentation says about flags and DSRs:
> 
> http://ecos.sourceware.org/docs-latest/ref/kernel-flags.html
> 
> So it seems to be possible to use cyg_flag_setbits() from DSRs.

> Andrew Lunn schrieb:
> >>But, one my today DSR uses the cyg_flag_setbits() notifier and that
> >>works as I could expect. I found that is more simple, because that
> >>doesn't need itself in a mutex. I wonder about the right hacking from
> >>the eCos experts.
> >
> >You are not allowed to block in a DSR. So look through the
> >cyg_flag_setbits() code and see if it calls any functions to block
> >itself. 
> >
> >        Andrew

Hello,

As I could understand Andrew's main concern, that is, We aren't allowed
to block in a DSR (cyg_flag_setbits() do it), and I am agree with him. I
looked at the common hal's drv_api.c against the kernel's flag.cxx.  As
I could see the cyg_drv_cond_*() calls are almost the atomic funcs. I
wouldn't say same thing about the kernel's Cyg_Flag::setbits().

More that, I liked cyg_drv_cond_wait(), because that is just it

while (cond->wait == 1) { call_dsrs (); }

So, my application can be a kernel-less application too. I think the
table from Chapter 13 is a good guide-line: a what allowed us to run
from DSR:

http://ecos.sourceware.org/docs-latest/ref/devapi-synchronization-levels.html

So, I did believe in that two crosses more after Andrew's suggest to
U.T.S.L :-) I did believe in those crosses even more after a comparation

  find $ECOS_REPOSITORY/{io,devs} | xargs grep cyg_drv_cond_

    against

  find $ECOS_REPOSITORY/{io,devs} | xargs grep cyg_flag_

We all did talk about the DSR's possibilities, didn't all? IMHO, that is
in the most an eCos driver related thing.

        Sergei


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

Re: [ECOS] Re: Waiting I/O operation

[Sergei Gavrikov]

On Sat, Jul 21, 2007 at 06:10:40PM +0300, Sergei Gavrikov wrote:
> On Sat, Jul 21, 2007 at 03:19:55PM +0200, Uwe Kindler wrote:
> > This is what the documentation says about flags and DSRs:
> > 
> > http://ecos.sourceware.org/docs-latest/ref/kernel-flags.html
> > 
> > So it seems to be possible to use cyg_flag_setbits() from DSRs.
> 
> > Andrew Lunn schrieb:
> > >>But, one my today DSR uses the cyg_flag_setbits() notifier and that
> > >>works as I could expect. I found that is more simple, because that
> > >>doesn't need itself in a mutex. I wonder about the right hacking from
> > >>the eCos experts.
> > >
> > >You are not allowed to block in a DSR. So look through the
> > >cyg_flag_setbits() code and see if it calls any functions to block
> > >itself. 
> > >
> > >        Andrew
> 
> Hello,
> 
> As I could understand Andrew's main concern, that is, We aren't allowed
> to block in a DSR (cyg_flag_setbits() do it), and I am agree with him. I
> looked at the common hal's drv_api.c against the kernel's flag.cxx.  As
> I could see the cyg_drv_cond_*() calls are almost the atomic funcs. I
> wouldn't say same thing about the kernel's Cyg_Flag::setbits().
> 
> More that, I liked cyg_drv_cond_wait(), because that is just it
> 
> while (cond->wait == 1) { call_dsrs (); }
> 
> So, my application can be a kernel-less application too. I think the
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Ups, I did schrieb that in a figth. This is no thruth :-) But, I hope
what the other points are the arguments.

        Sergei


> table from Chapter 13 is a good guide-line: a what allowed us to run
> from DSR:
> 
> http://ecos.sourceware.org/docs-latest/ref/devapi-synchronization-levels.html
> 
> So, I did believe in that two crosses more after Andrew's suggest to
> U.T.S.L :-) I did believe in those crosses even more after a comparation
> 
>   find $ECOS_REPOSITORY/{io,devs} | xargs grep cyg_drv_cond_
> 
>     against
> 
>   find $ECOS_REPOSITORY/{io,devs} | xargs grep cyg_flag_
> 
> We all did talk about the DSR's possibilities, didn't all? IMHO, that is
> in the most an eCos driver related thing.
> 
>         Sergei
> 
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

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

Re: [ECOS] Re: Waiting I/O operation

[Alexey Shusharin]

Sergei Gavrikov wrote:
> Hello,
Hello all,
I'm not eCos kernel expert but I think we can use cyg_flag_setbits() in 
DSR level.

> As I could understand Andrew's main concern, that is, We aren't allowed
> to block in a DSR (cyg_flag_setbits() do it), and I am agree with him.

Yes, we can't block in a DSR and IMHO cyg_flag_setbits() doesn't do it.
If we compare Cyg_Flag::setbits() (in flag.cxx) and 
Cyg_Condition_Variable::sygnal() (in mutex.cxx) we will see that there 
are no fundamental differences. So, if we can call sygnal() in a DSR we 
are able to call setbits() too.

> I looked at the common hal's drv_api.c against the kernel's flag.cxx. As
> I could see the cyg_drv_cond_*() calls are almost the atomic funcs. I
> wouldn't say same thing about the kernel's Cyg_Flag::setbits().

drv_api.c is the implementation of driver API in configuration without 
kernel. If we use a kernel, directives in dri_api.h select kapi.c 
implementation (kernel C API). And we use code from mutex.cxx and other 
kernel code eventually.

> More that, I liked cyg_drv_cond_wait(), because that is just it
> 
> while (cond->wait == 1) { call_dsrs (); }
> 
> So, my application can be a kernel-less application too. I think the
> table from Chapter 13 is a good guide-line: a what allowed us to run
> from DSR:
> 
> http://ecos.sourceware.org/docs-latest/ref/devapi-synchronization-levels.html

Yes, if you use functions from drv_api.h only, your application can be a 
kernel-less. And this is the reason why you didn't find using of flags 
in drivers. It's not recommended because the flag is not included in 
driver API.

But I would like to use flags in the application, and I know that kernel 
exist. So IMHO I can call cyg_flag_setbits() in a function which is 
called from a DSR.

Best regards
Alexey Shusharin

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

Re: [ECOS] Re: Waiting I/O operation

[Uwe Kindler]

Hello,

I agree with Alexey. Normally a driver should work without kernel. But 
if some functions in the driver require kernel, you can force this 
configuration in driver CDL. I.e. the CAN I/O driver timed wait 
operations already require a kernel. So I think it is O.K. to provide 
callback functions if they are configurable via CDL.

It is up to the application engineer to use an allowed synchronization 
in the callback function provided by the application. If the kernel is 
present, then cyg_flag_setbits() should work. And if someone does not 
like this, then he can disable callback (should be the default 
configuration in CDL) and use 2 threads instead.

Regards, Uwe

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

Re: [ECOS] Re: Waiting I/O operation

[Sergei Gavrikov]

В Пнд, 23/07/2007 в 11:05 +0700, Alexey Shusharin пишет:
> Sergei Gavrikov wrote:
> > Hello,
> Hello all,
> I'm not eCos kernel expert but I think we can use cyg_flag_setbits() in 
> DSR level.
> 
> > As I could understand Andrew's main concern, that is, We aren't allowed
> > to block in a DSR (cyg_flag_setbits() do it), and I am agree with him.
> 
> Yes, we can't block in a DSR and IMHO cyg_flag_setbits() doesn't do it.
> If we compare Cyg_Flag::setbits() (in flag.cxx) and 
> Cyg_Condition_Variable::sygnal() (in mutex.cxx) we will see that there 
> are no fundamental differences. So, if we can call sygnal() in a DSR we 
> are able to call setbits() too.
> 
> > I looked at the common hal's drv_api.c against the kernel's flag.cxx. As
> > I could see the cyg_drv_cond_*() calls are almost the atomic funcs. I
> > wouldn't say same thing about the kernel's Cyg_Flag::setbits().
> 
> drv_api.c is the implementation of driver API in configuration without 
> kernel. If we use a kernel, directives in dri_api.h select kapi.c 
> implementation (kernel C API). And we use code from mutex.cxx and other 
> kernel code eventually.
> 
> > More that, I liked cyg_drv_cond_wait(), because that is just it
> > 
> > while (cond->wait == 1) { call_dsrs (); }
> > 
> > So, my application can be a kernel-less application too. I think the
> > table from Chapter 13 is a good guide-line: a what allowed us to run
> > from DSR:
> > 
> > http://ecos.sourceware.org/docs-latest/ref/devapi-synchronization-levels.html
> 
> Yes, if you use functions from drv_api.h only, your application can be a 
> kernel-less. And this is the reason why you didn't find using of flags 
> in drivers. It's not recommended because the flag is not included in 
> driver API.

Hello,

The DSR is a kernel driven stuff. As I understood before... The eCos
scheduler manages the deffered service routings. So, it was no sence to
mention the DSRs in kernel-less environment at all. I did it, but I did
correct myself at once :-)

	Sergei

> But I would like to use flags in the application, and I know that kernel 
> exist. So IMHO I can call cyg_flag_setbits() in a function which is 
> called from a DSR.
> 
> Best regards
> Alexey Shusharin
> 


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

Re: [ECOS] Re: Waiting I/O operation

[Alexey Shusharin]

Sergei Gavrikov wrote:
> В Пнд, 23/07/2007 в 11:05 +0700, Alexey Shusharin пишет:
>> Sergei Gavrikov wrote:
>>> Hello,
>> Hello all,
>> I'm not eCos kernel expert but I think we can use cyg_flag_setbits() in 
>> DSR level.
>>
>>> As I could understand Andrew's main concern, that is, We aren't allowed
>>> to block in a DSR (cyg_flag_setbits() do it), and I am agree with him.
>> Yes, we can't block in a DSR and IMHO cyg_flag_setbits() doesn't do it.
>> If we compare Cyg_Flag::setbits() (in flag.cxx) and 
>> Cyg_Condition_Variable::sygnal() (in mutex.cxx) we will see that there 
>> are no fundamental differences. So, if we can call sygnal() in a DSR we 
>> are able to call setbits() too.
>>
>>> I looked at the common hal's drv_api.c against the kernel's flag.cxx. As
>>> I could see the cyg_drv_cond_*() calls are almost the atomic funcs. I
>>> wouldn't say same thing about the kernel's Cyg_Flag::setbits().
>> drv_api.c is the implementation of driver API in configuration without 
>> kernel. If we use a kernel, directives in dri_api.h select kapi.c 
>> implementation (kernel C API). And we use code from mutex.cxx and other 
>> kernel code eventually.
>>
>>> More that, I liked cyg_drv_cond_wait(), because that is just it
>>>
>>> while (cond->wait == 1) { call_dsrs (); }
>>>
>>> So, my application can be a kernel-less application too. I think the
>>> table from Chapter 13 is a good guide-line: a what allowed us to run
>>> from DSR:
>>>
>>> http://ecos.sourceware.org/docs-latest/ref/devapi-synchronization-levels.html
>> Yes, if you use functions from drv_api.h only, your application can be a 
>> kernel-less. And this is the reason why you didn't find using of flags 
>> in drivers. It's not recommended because the flag is not included in 
>> driver API.
> 
> Hello,
> 
> The DSR is a kernel driven stuff. As I understood before... The eCos
> scheduler manages the deffered service routings.

Yes, if kernel is enabled. But if not, DSRs are calling from 
call_dsrs(), which is calling from cyg_drv_cond_wait() (in drv_api.c) 
and maybe from other kernel-less configuration functions.

I think you was right in first time. ;-)

Regards
Alexey

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

Re: [ECOS] Re: Waiting I/O operation

[Sergei Gavrikov]

On Mon, Jul 23, 2007 at 05:09:39PM +0700, Alexey Shusharin writes:
> Sergei Gavrikov wrote:
> >The DSR is a kernel driven stuff. As I understood before... The eCos
> >scheduler manages the deffered service routings.
> 
> Yes, if kernel is enabled. But if not, DSRs are calling from 
> call_dsrs(), which is calling from cyg_drv_cond_wait() (in drv_api.c) 
> and maybe from other kernel-less configuration functions.
> 
> I think you was right in first time. ;-)
> 

Alexey, you're right! That was :-) Looking at the call_dsrs() in that
time, I suddenly did think, Hm, the call_dsrs() is declared as static,
it would be called from cyg_interrupt_call_pending_DSRs(), but I haven't
such an implementation... So, I was thinking, That call is the kernel's
deal...

I just missed what HAL interrupt_end() does it for any kernel-less
configuration, and the hal/common/current/tests/intr.c is a pretty much
advocacy. I ought remember what the eCos `intr' test quite works without
a kernel package. Thanks, for a brainwashing!

Regards,

	Sergei


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