* [ECOS] Re: Waiting I/O operation @ 2007-07-19 8:47 cetoni GmbH - Uwe Kindler 2007-07-19 9:53 ` Alexey Shusharin 0 siblings, 1 reply; 16+ messages in thread From: cetoni GmbH - Uwe Kindler @ 2007-07-19 8:47 UTC (permalink / raw) To: ecos-discuss; +Cc: Alexey Shusharin 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ECOS] Re: Waiting I/O operation 2007-07-19 8:47 [ECOS] Re: Waiting I/O operation cetoni GmbH - Uwe Kindler @ 2007-07-19 9:53 ` Alexey Shusharin 2007-07-19 10:39 ` cetoni GmbH - Uwe Kindler ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Alexey Shusharin @ 2007-07-19 9:53 UTC (permalink / raw) To: cetoni GmbH - Uwe Kindler, ecos-discuss 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ECOS] Re: Waiting I/O operation 2007-07-19 9:53 ` Alexey Shusharin @ 2007-07-19 10:39 ` cetoni GmbH - Uwe Kindler 2007-07-19 10:56 ` Alexey Shusharin 2007-07-19 10:41 ` Alexey Shusharin 2007-07-19 10:47 ` Sergei Gavrikov 2 siblings, 1 reply; 16+ messages in thread From: cetoni GmbH - Uwe Kindler @ 2007-07-19 10:39 UTC (permalink / raw) To: Alexey Shusharin; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Waiting I/O operation 2007-07-19 10:39 ` cetoni GmbH - Uwe Kindler @ 2007-07-19 10:56 ` Alexey Shusharin 0 siblings, 0 replies; 16+ messages in thread From: Alexey Shusharin @ 2007-07-19 10:56 UTC (permalink / raw) To: cetoni GmbH - Uwe Kindler, ecos-discuss 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ECOS] Re: Waiting I/O operation 2007-07-19 9:53 ` Alexey Shusharin 2007-07-19 10:39 ` cetoni GmbH - Uwe Kindler @ 2007-07-19 10:41 ` Alexey Shusharin 2007-07-19 10:47 ` Sergei Gavrikov 2 siblings, 0 replies; 16+ messages in thread From: Alexey Shusharin @ 2007-07-19 10:41 UTC (permalink / raw) To: cetoni GmbH - Uwe Kindler, ecos-discuss 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Waiting I/O operation 2007-07-19 9:53 ` Alexey Shusharin 2007-07-19 10:39 ` cetoni GmbH - Uwe Kindler 2007-07-19 10:41 ` Alexey Shusharin @ 2007-07-19 10:47 ` Sergei Gavrikov 2007-07-20 19:35 ` Andrew Lunn 2 siblings, 1 reply; 16+ messages in thread From: Sergei Gavrikov @ 2007-07-19 10:47 UTC (permalink / raw) To: Alexey Shusharin; +Cc: cetoni GmbH - Uwe Kindler, ecos-discuss 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Waiting I/O operation 2007-07-19 10:47 ` Sergei Gavrikov @ 2007-07-20 19:35 ` Andrew Lunn 2007-07-21 11:22 ` Sergei Gavrikov 2007-07-21 13:21 ` Uwe Kindler 0 siblings, 2 replies; 16+ messages in thread From: Andrew Lunn @ 2007-07-20 19:35 UTC (permalink / raw) To: Sergei Gavrikov; +Cc: Alexey Shusharin, cetoni GmbH - Uwe Kindler, ecos-discuss > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Waiting I/O operation 2007-07-20 19:35 ` Andrew Lunn @ 2007-07-21 11:22 ` Sergei Gavrikov 2007-07-21 13:21 ` Uwe Kindler 1 sibling, 0 replies; 16+ messages in thread From: Sergei Gavrikov @ 2007-07-21 11:22 UTC (permalink / raw) To: Andrew Lunn; +Cc: ecos-discuss, Alexey Shusharin, Uwe Kindler 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Waiting I/O operation 2007-07-20 19:35 ` Andrew Lunn 2007-07-21 11:22 ` Sergei Gavrikov @ 2007-07-21 13:21 ` Uwe Kindler 2007-07-21 15:11 ` Sergei Gavrikov 1 sibling, 1 reply; 16+ messages in thread From: Uwe Kindler @ 2007-07-21 13:21 UTC (permalink / raw) To: Sergei Gavrikov, Alexey Shusharin, cetoni GmbH - Uwe Kindler, ecos-discuss 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Waiting I/O operation 2007-07-21 13:21 ` Uwe Kindler @ 2007-07-21 15:11 ` Sergei Gavrikov 2007-07-21 15:25 ` Sergei Gavrikov 2007-07-23 4:10 ` Alexey Shusharin 0 siblings, 2 replies; 16+ messages in thread From: Sergei Gavrikov @ 2007-07-21 15:11 UTC (permalink / raw) To: Uwe Kindler; +Cc: Alexey Shusharin, cetoni GmbH - Uwe Kindler, ecos-discuss 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Waiting I/O operation 2007-07-21 15:11 ` Sergei Gavrikov @ 2007-07-21 15:25 ` Sergei Gavrikov 2007-07-23 4:10 ` Alexey Shusharin 1 sibling, 0 replies; 16+ messages in thread From: Sergei Gavrikov @ 2007-07-21 15:25 UTC (permalink / raw) To: Uwe Kindler; +Cc: Alexey Shusharin, cetoni GmbH - Uwe Kindler, ecos-discuss 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Waiting I/O operation 2007-07-21 15:11 ` Sergei Gavrikov 2007-07-21 15:25 ` Sergei Gavrikov @ 2007-07-23 4:10 ` Alexey Shusharin 2007-07-23 5:53 ` Uwe Kindler 2007-07-23 9:12 ` Sergei Gavrikov 1 sibling, 2 replies; 16+ messages in thread From: Alexey Shusharin @ 2007-07-23 4:10 UTC (permalink / raw) To: Sergei Gavrikov; +Cc: cetoni GmbH - Uwe Kindler, ecos-discuss 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Waiting I/O operation 2007-07-23 4:10 ` Alexey Shusharin @ 2007-07-23 5:53 ` Uwe Kindler 2007-07-23 9:12 ` Sergei Gavrikov 1 sibling, 0 replies; 16+ messages in thread From: Uwe Kindler @ 2007-07-23 5:53 UTC (permalink / raw) To: Alexey Shusharin; +Cc: Sergei Gavrikov, cetoni GmbH - Uwe Kindler, ecos-discuss 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Waiting I/O operation 2007-07-23 4:10 ` Alexey Shusharin 2007-07-23 5:53 ` Uwe Kindler @ 2007-07-23 9:12 ` Sergei Gavrikov 2007-07-23 10:15 ` Alexey Shusharin 1 sibling, 1 reply; 16+ messages in thread From: Sergei Gavrikov @ 2007-07-23 9:12 UTC (permalink / raw) To: Alexey Shusharin; +Cc: cetoni GmbH - Uwe Kindler, ecos-discuss Ð Ðнд, 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Waiting I/O operation 2007-07-23 9:12 ` Sergei Gavrikov @ 2007-07-23 10:15 ` Alexey Shusharin 2007-07-23 18:49 ` Sergei Gavrikov 0 siblings, 1 reply; 16+ messages in thread From: Alexey Shusharin @ 2007-07-23 10:15 UTC (permalink / raw) To: Sergei Gavrikov; +Cc: cetoni GmbH - Uwe Kindler, ecos-discuss 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Waiting I/O operation 2007-07-23 10:15 ` Alexey Shusharin @ 2007-07-23 18:49 ` Sergei Gavrikov 0 siblings, 0 replies; 16+ messages in thread From: Sergei Gavrikov @ 2007-07-23 18:49 UTC (permalink / raw) To: Alexey Shusharin; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2007-07-23 18:49 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-07-19 8:47 [ECOS] Re: Waiting I/O operation cetoni GmbH - Uwe Kindler 2007-07-19 9:53 ` Alexey Shusharin 2007-07-19 10:39 ` cetoni GmbH - Uwe Kindler 2007-07-19 10:56 ` Alexey Shusharin 2007-07-19 10:41 ` Alexey Shusharin 2007-07-19 10:47 ` Sergei Gavrikov 2007-07-20 19:35 ` Andrew Lunn 2007-07-21 11:22 ` Sergei Gavrikov 2007-07-21 13:21 ` Uwe Kindler 2007-07-21 15:11 ` Sergei Gavrikov 2007-07-21 15:25 ` Sergei Gavrikov 2007-07-23 4:10 ` Alexey Shusharin 2007-07-23 5:53 ` Uwe Kindler 2007-07-23 9:12 ` Sergei Gavrikov 2007-07-23 10:15 ` Alexey Shusharin 2007-07-23 18:49 ` Sergei Gavrikov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).