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.