cyg_flag_timed_wait doesn't seem to work as expected

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

cyg_flag_timed_wait doesn't seem to work as expected

Michael W. Ellis
I'm running an old version of eCos (2.0.98) from eCosCentric and I'm attempting to use cyg_flag_timed_wait to periodically update a display (see code, below).  My event flag variable g_flags is initialized elsewhere before this thread is created.  Other threads access the same event flag but use their own bits within the flag.

My problem is with the timed wait behavior of the event flag.  At startup I see an initial wait of 30 seconds before the first display update occurs, but the update occurs continually after the initial timeout.  The local variable flags always reads 0, indicating timeout has occurred.  My understanding is that calling cyg_flag_timed_wait at the top of the loop restarts the timer, but this does not seem to be the case.  What am I missing here?  Is there something I must do to clear the timeout event?

Variable allocation and initialization:
static cyg_flag_t g_flags;                                              // thread sync event flags
cyg_flag_init(&g_flags);                                                // init thread sync flag


// ogDisplayThread - update display
static void ogDisplayThread(cyg_addrword_t data)
{
    diag_printf("Entering ogDisplayThread...\r\n");

    cyg_flag_setbits(&g_flags, OG_FLAG_DISP_RDY);                       // say this thread is ready

    while (1)
    {
        cyg_flag_value_t flags;

        flags = cyg_flag_timed_wait(&g_flags,                           // timed wait
                OG_FLAG_DISP_EXIT,                                      // wait for EXIT flag or timeout
                CYG_FLAG_WAITMODE_AND,
                3000);                                                  // 30 second timeout

        diag_printf("ogDisplayThread flag = %08X\r\n", flags);

        if (flags & OG_FLAG_DISP_EXIT)                                  // if EXIT event occurred
        {
            diag_printf("Exiting ogDisplayThread\r\n");

            cyg_flag_maskbits(&g_flags,                                 // say this thread is no longer ready
                    OG_FLAG_DISP_RDY|OG_FLAG_DISP_EXIT);

            cyg_thread_exit();                                          // and exit thread
        }
        else if (!flags)                                                // if timeout occurred (normal condition)
        {
            diag_printf("ogDisplayThread sending data\r\n");
            ogp_msg_t *msg;

            // send IP address
            if (NULL == (msg = malloc(sizeof(ogp_msg_t))))             // allocate a message buffer
                diag_printf("ogDisplayThread malloc error\r\n");
            else
            {
                msg->sync = htonl(OGP_SYNC_WORD);                      // build message
                msg->src = LOCAL_CMD_SRC;
                msg->dst = LOCAL_CMD_DST_SET_IPADDR;
                msg->mtype = LOCAL_CMD_MTYPE;
                api_eth_get_ip(msg->data, 16);                         // get IP address string
                msg->len = htons(strlen(msg->data)+1);                 // set length
                ogpPutTxQ(msg);                                        // send message
            }
        }
        else                                                           // should never get here
            diag_printf("ogDisplayThread unexpected event flag\r\n");
    }
}

Debug output (continual after 30 seconds):
ogDisplayThread flag = 00000000
ogDisplayThread sending data
ogDisplayThread flag = 00000000
ogDisplayThread sending data
ogDisplayThread flag = 00000000
ogDisplayThread sending data
ogDisplayThread flag = 00000000
ogDisplayThread sending data
ogDisplayThread flag = 00000000
ogDisplayThread sending data
ogDisplayThread flag = 00000000
ogDisplayThread sending data
ogDisplayThread flag = 00000000
ogDisplayThread sending data


Thanks,
Michael


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

Reply | Threaded
Open this post in threaded view
|

AW: [ECOS] cyg_flag_timed_wait doesn't seem to work as expected

Richard Rauch
Hi Michael,

do you initialize the flags somewhere with cyg_flag_init() ?
This initialisation needs to be made before the first access of the event
flag variable.

Best Regards
Richard
www.itrgmbh.com


> -----Ursprüngliche Nachricht-----
> Von: [hidden email] [mailto:ecos-discuss-
> [hidden email]] Im Auftrag von Michael W. Ellis
> Gesendet: Freitag, 27. Mai 2016 15:31
> An: [hidden email]
> Betreff: [ECOS] cyg_flag_timed_wait doesn't seem to work as expected
>
> I'm running an old version of eCos (2.0.98) from eCosCentric and I'm
> attempting to use cyg_flag_timed_wait to periodically update a display
(see
> code, below).  My event flag variable g_flags is initialized elsewhere
before
> this thread is created.  Other threads access the same event flag but use
their
> own bits within the flag.
>
> My problem is with the timed wait behavior of the event flag.  At startup
I
> see an initial wait of 30 seconds before the first display update occurs,
but
> the update occurs continually after the initial timeout.  The local
variable
> flags always reads 0, indicating timeout has occurred.  My understanding
is
> that calling cyg_flag_timed_wait at the top of the loop restarts the
timer, but
> this does not seem to be the case.  What am I missing here?  Is there
> something I must do to clear the timeout event?
>
> Variable allocation and initialization:
> static cyg_flag_t g_flags;                                              //
thread sync event flags
> cyg_flag_init(&g_flags);                                                //
init thread sync flag
>
>
> // ogDisplayThread - update display
> static void ogDisplayThread(cyg_addrword_t data) {
>     diag_printf("Entering ogDisplayThread...\r\n");
>
>     cyg_flag_setbits(&g_flags, OG_FLAG_DISP_RDY);                       //
say this
> thread is ready
>
>     while (1)
>     {
>         cyg_flag_value_t flags;
>
>         flags = cyg_flag_timed_wait(&g_flags,                           //
timed wait
>                 OG_FLAG_DISP_EXIT,                                      //
wait for EXIT flag or
> timeout
>                 CYG_FLAG_WAITMODE_AND,
>                 3000);                                                  //
30 second timeout
>
>         diag_printf("ogDisplayThread flag = %08X\r\n", flags);
>
>         if (flags & OG_FLAG_DISP_EXIT)                                  //
if EXIT event
> occurred
>         {
>             diag_printf("Exiting ogDisplayThread\r\n");
>
>             cyg_flag_maskbits(&g_flags,                                 //
say this thread is no
> longer ready
>                     OG_FLAG_DISP_RDY|OG_FLAG_DISP_EXIT);
>
>             cyg_thread_exit();                                          //
and exit thread
>         }
>         else if (!flags)                                                //
if timeout occurred (normal
> condition)
>         {
>             diag_printf("ogDisplayThread sending data\r\n");
>             ogp_msg_t *msg;
>
>             // send IP address
>             if (NULL == (msg = malloc(sizeof(ogp_msg_t))))             //
allocate a
> message buffer
>                 diag_printf("ogDisplayThread malloc error\r\n");
>             else
>             {
>                 msg->sync = htonl(OGP_SYNC_WORD);                      //
build message
>                 msg->src = LOCAL_CMD_SRC;
>                 msg->dst = LOCAL_CMD_DST_SET_IPADDR;
>                 msg->mtype = LOCAL_CMD_MTYPE;
>                 api_eth_get_ip(msg->data, 16);                         //
get IP address string
>                 msg->len = htons(strlen(msg->data)+1);                 //
set length
>                 ogpPutTxQ(msg);                                        //
send message
>             }
>         }
>         else                                                           //
should never get here

>             diag_printf("ogDisplayThread unexpected event flag\r\n");
>     }
> }
>
> Debug output (continual after 30 seconds):
> ogDisplayThread flag = 00000000
> ogDisplayThread sending data
> ogDisplayThread flag = 00000000
> ogDisplayThread sending data
> ogDisplayThread flag = 00000000
> ogDisplayThread sending data
> ogDisplayThread flag = 00000000
> ogDisplayThread sending data
> ogDisplayThread flag = 00000000
> ogDisplayThread sending data
> ogDisplayThread flag = 00000000
> ogDisplayThread sending data
> ogDisplayThread flag = 00000000
> ogDisplayThread sending data
>
>
> Thanks,
> Michael
>
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Reply | Threaded
Open this post in threaded view
|

Re: cyg_flag_timed_wait doesn't seem to work as expected

Nick Garnett-2
In reply to this post by Michael W. Ellis


On 27/05/16 14:30, Michael W. Ellis wrote:

> I'm running an old version of eCos (2.0.98) from eCosCentric and I'm
> attempting to use cyg_flag_timed_wait to periodically update a
> display (see code, below).  My event flag variable g_flags is
> initialized elsewhere before this thread is created.  Other threads
> access the same event flag but use their own bits within the flag.
>
> My problem is with the timed wait behavior of the event flag.  At
> startup I see an initial wait of 30 seconds before the first display
> update occurs, but the update occurs continually after the initial
> timeout.  The local variable flags always reads 0, indicating timeout
> has occurred.  My understanding is that calling cyg_flag_timed_wait
> at the top of the loop restarts the timer, but this does not seem to
> be the case.  What am I missing here?  Is there something I must do
> to clear the timeout event?
>

The problem is your use of 3000 for the timeout. In eCos, timeouts give
the wakeup time, not the duration. So, the first call waits until tick
3000, but the rest return immediately since it is now past 3000.

The solution is to use cyg_current_time()+3000 in the timeout argument.

--
Nick Garnett                                         Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com    The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.        +44 1223 245571
Registered in England and Wales:                      Reg No: 4422071

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

Reply | Threaded
Open this post in threaded view
|

RE: cyg_flag_timed_wait doesn't seem to work as expected

Michael W. Ellis
> -----Original Message-----
> From: [hidden email] [mailto:ecos-discuss-
> [hidden email]] On Behalf Of Nick Garnett
> Sent: Friday, May 27, 2016 11:27 AM
> To: [hidden email]
> Subject: Re: [ECOS] cyg_flag_timed_wait doesn't seem to work as
> expected
>
>
>
> On 27/05/16 14:30, Michael W. Ellis wrote:
> > I'm running an old version of eCos (2.0.98) from eCosCentric and I'm
> > attempting to use cyg_flag_timed_wait to periodically update a
> display
> > (see code, below).  My event flag variable g_flags is initialized
> > elsewhere before this thread is created.  Other threads access the
> > same event flag but use their own bits within the flag.
> >
> > My problem is with the timed wait behavior of the event flag.  At
> > startup I see an initial wait of 30 seconds before the first display
> > update occurs, but the update occurs continually after the initial
> > timeout.  The local variable flags always reads 0, indicating
timeout
> > has occurred.  My understanding is that calling cyg_flag_timed_wait
> at
> > the top of the loop restarts the timer, but this does not seem to be
> > the case.  What am I missing here?  Is there something I must do to
> > clear the timeout event?
> >
>
> The problem is your use of 3000 for the timeout. In eCos, timeouts
give
> the wakeup time, not the duration. So, the first call waits until tick
> 3000, but the rest return immediately since it is now past 3000.
>
> The solution is to use cyg_current_time()+3000 in the timeout
argument.
>
> --
> Nick Garnett                                         Kernel Architect
> eCosCentric Limited    http://www.eCosCentric.com    The eCos experts
> Barnwell House, Barnwell Drive, Cambridge, UK.        +44 1223 245571
> Registered in England and Wales:                      Reg No: 4422071
>

This makes perfect sense now.  I made this change and everything is
working as I expect.

Thanks,

Michael

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

Reply | Threaded
Open this post in threaded view
|

eCos Configuration Tool clewan and rebuild

Michael W. Ellis
In reply to this post by Michael W. Ellis
I have inherited a project based on eCos 2.0.98 and have reached a point
where I need to rebuild my library.  Most of the folks who originally
worked on this project are no longer with the company and our internal
documentation is scarce at best.

My understanding is that the eCos Configuration Tool is used to make
changes to a .ecc file, and then to use this file to build the library.
I have located the .ecc file for my project and have attempted to
rebuild the library but something seems to be amiss.  I see the
extras.o, libextras.a and libtarget.a files in _install/lib change but
the target.ld and vectors.o files remain unchanged.  On one of my
changes I updated linker-related files for my hardware in the eCos
repository, but the linker files never seem to be regenerated.  If I
manually delete target.ld and rebuild the library then a new linker file
is created.

Is there something I'm missing here?  I have tried cleaning and then
building but nothing seems to make a difference to the linker file.

Michael

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

Reply | Threaded
Open this post in threaded view
|

Re: eCos Configuration Tool clewan and rebuild

Grant Edwards-6
On 2016-06-16, Michael W. Ellis <[hidden email]> wrote:
> I have inherited a project based on eCos 2.0.98 and have reached a point
> where I need to rebuild my library.  Most of the folks who originally
> worked on this project are no longer with the company and our internal
> documentation is scarce at best.
>
> My understanding is that the eCos Configuration Tool is used to make
> changes to a .ecc file, and then to use this file to build the library.

Yes.  However, there are two different ecos configuration tools.  A
command line one, and a GUI one (there might be multiple similar but
different look/feel GUI ones, I don't really know).

For all our actuall production code, we use the command-line
ecosconfig utility exclusivly.  That way you can write a shell script
that calls the ecosconfig utility to generate an .ecc file from
scratch and then creates the build tree.

That shell script is then placed under source control just like the
rest of source code.  IMO, relying on a GUI tool and
accurate/repeatable human clicking for building production code is a
huge mistake.  You can place the .ecc file under version control if
you want, but (IMO) it's far more important that the script that
_builds_ the .ecc file is under source control.

> I have located the .ecc file for my project and have attempted to
> rebuild the library but something seems to be amiss.  I see the
> extras.o, libextras.a and libtarget.a files in _install/lib change
> but the target.ld and vectors.o files remain unchanged.

You probably need to start with a new build tree.

> On one of my changes I updated linker-related files for my hardware
> in the eCos repository, but the linker files never seem to be
> regenerated.

Only the .c files are used directory from the repository.  Most other
files get processed and then copied into the build tree.

> If I manually delete target.ld and rebuild the library then a new
> linker file is created.
>
> Is there something I'm missing here?  I have tried cleaning

What do you mean by "cleaning"?

> and then building but nothing seems to make a difference to the
> linker file.

If you're using the GUI config tool, I can't really help.  If you're
using the command-line one, start with an empty directory.  Your
script should start with

  ecosconfig new <platform>

then, as needed

  ecosconfig add <package>
  econsonfig del <package>

and finally change/set/clear whatever package options you need to

  cat >.tmp$$.cdl <<EOF
  cdl_component CYGSEM_KERNEL_SCHED_TIMESLICE {user_value 0}
  cdl_option CYGPKG_IO_NFILE {user_value 256}
  cdl_option CYGNUM_FILEIO_NFILE {user_value 256}
  cdl_option CYGNUM_FILEIO_NFD {user_value 256}
  cdl_option CYGPKG_NET_TFTP {user_value 0}
  EOF

  ecosconfig import .tmp$$.cdl

That produces the .ecc file. Now you create the build tree

  ecosconfig tree

Now you have a "build tree" that contains things like include files,
Makefiles, linker scripts, and basically everything except the .c files.

Finally do the build

  make

If you want to rebuild because

 0) you changed a CDL file: start over completely at the "ecosconfig
    new" step in an empty directory.

 1) you changed a .h file or linker script or memory map file: start
    at the "ecosconfig tree" step in a directory containing nothing
    but the .ecc file.

 2) you changed a .c file: you can generally just run "make" again.

--
Grant Edwards               grant.b.edwards        Yow! I'm in direct contact
                                  at               with many advanced fun
                              gmail.com            CONCEPTS.


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

Reply | Threaded
Open this post in threaded view
|

Re: eCos Configuration Tool clewan and rebuild

Michael W. Ellis
> -----Original Message-----
> From: [hidden email] [mailto:ecos-discuss-
> [hidden email]] On Behalf Of Grant Edwards
> Sent: Thursday, June 16, 2016 12:10 PM
> To: [hidden email]
> Subject: [ECOS] Re: eCos Configuration Tool clewan and rebuild
>
> On 2016-06-16, Michael W. Ellis <[hidden email]> wrote:
> > I have inherited a project based on eCos 2.0.98 and have reached a
> > point where I need to rebuild my library.  Most of the folks who
> > originally worked on this project are no longer with the company and
> > our internal documentation is scarce at best.
> >
> > My understanding is that the eCos Configuration Tool is used to make
> > changes to a .ecc file, and then to use this file to build the
> library.
>
> Yes.  However, there are two different ecos configuration tools.  A
> command line one, and a GUI one (there might be multiple similar but
> different look/feel GUI ones, I don't really know).
>
> For all our actuall production code, we use the command-line
ecosconfig
> utility exclusivly.  That way you can write a shell script that calls
> the ecosconfig utility to generate an .ecc file from scratch and then
> creates the build tree.
>
> That shell script is then placed under source control just like the
> rest of source code.  IMO, relying on a GUI tool and
> accurate/repeatable human clicking for building production code is a
> huge mistake.  You can place the .ecc file under version control if
you
> want, but (IMO) it's far more important that the script that _builds_
> the .ecc file is under source control.

Our approach in the past was to use the GUI tool but I agree that your
approach is better since the script file more or less self-documents the
process and is easily tracked under revision control.  Getting from the
GUI based configuration to script based configuration requires some
trial and error grunt work with file comparison tools to figure out
exactly what options were changed in the GUI but it's probably worth it
in the long run.

You asked what I meant by "cleaning".  The GUI tool basically has three
build options: clean, library and tests.  I had tried using the build
clean option, expecting it to remove all intermediate and output files
(including my linker file) but this didn't seem to do what I expected.

Thanks for the tips.  This has helped clarify the situation immensely.

Michael

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

Reply | Threaded
Open this post in threaded view
|

Re: eCos Configuration Tool clewan and rebuild

Grant Edwards-6
On 2016-06-16, Michael W. Ellis <[hidden email]> wrote:

> Our approach in the past was to use the GUI tool but I agree that
> your approach is better since the script file more or less
> self-documents the process and is easily tracked under revision
> control.  Getting from the GUI based configuration to script based
> configuration requires some trial and error grunt work with file
> comparison tools to figure out exactly what options were changed in
> the GUI but it's probably worth it in the long run.

Yep, reverse-engineering a script from an existing .ecc file is a bit
of a chore, but I think it's probably worth it.  Like you said, it
takes a bit of of file comparison.  If enough work was done up-front
so that there's a template that includes the proper set of packages
it's possible that you won't need much more more than

  "ecosconfig new <whatever>"
  "ecosconfig tree"

... with perhaps a few option settings in between.

You can also add new templates or change existing ones so that you
have to do fewer "ecosconfig add" and "ecosconfig del" commands in
your script.  That's mostly a matter of personal taste.

> You asked what I meant by "cleaning".  The GUI tool basically has
> three build options: clean, library and tests.

Ah.  I don't know what exactly what the GUI does when you tell it to
"clean".  It might just do a "make clean", or it might remove
everything except the .ecc file and do an "ecosconfig tree".

BTW: I've been assuming you're doing development on a *nix host.  If
you're doing it under Windows+Cywgin, pretty much all the advise
applies, but you end up with a whole extra layer of possible issues
with Cygwin.

--
Grant Edwards               grant.b.edwards        Yow! An INK-LING?  Sure --
                                  at               TAKE one!!  Did you BUY any
                              gmail.com            COMMUNIST UNIFORMS??


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

Reply | Threaded
Open this post in threaded view
|

Re: eCos Configuration Tool clewan and rebuild

Alex Schuilenburg-2
On 16/06/16 22:41, Grant Edwards wrote:
> [...]
> Ah. I don't know what exactly what the GUI does when you tell it to
> "clean". It might just do a "make clean",

That is exactly what it does.

> or it might remove everything except the .ecc file and do an
> "ecosconfig tree". BTW: I've been assuming you're doing development on
> a *nix host. If you're doing it under Windows+Cywgin, pretty much all
> the advise applies, but you end up with a whole extra layer of
> possible issues with Cygwin.

The anoncvs version of GUI configtool is broken when it comes to
dependencies, the handling of templates, and even creating a new target
configuration.  In fact the ordering of the appearance of dependencies
within CDL could change the configuration you ended up with as a result
of the way that the anoncvs GUI configtool resolves dependencies.

Using anoncvs ecosconfig is the better solution as you state, but it too
has issues with dependencies so you are recommended to "make clean",
"ecosconfig tree", and "make" to ensure everything is built from the
correct headers and makefiles.

FWIW, the issues with these tools have been been resolved within the
eCosPro host tools since eCosPro 3.1.X (including dropping cygwin
entirely) and the GUI configtool has become very useful but
unfortunately these changes have not made their way back into anoncvs.

-- Alex
http://www.ecoscentric.com/             The eCos Experts


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

Reply | Threaded
Open this post in threaded view
|

AW: [ECOS] Re: eCos Configuration Tool clewan and rebuild

Richard Rauch
Actually we prefer to work with the GUI. .ecc Files are application  project
related. It is much more convenient to create the eCos configuration by
usage of GUI tool. We were working on all of our projects with the GUI
config tool.
We managed to create a version, not based on Cygwin as well. Regarding the
build library behavior, there should be no difference to the Cygwin version.

There is one issue maybe. When we are changing major things in our eCos
configuration, we delete the complete build tree folders with file system.
Then the config tool is forced to rebuild everything.
The folders are somehow named like .\.......build and .\....install\. They
are located relative to your path, where the .ecc file is.

Richard Rauch
www.itrgmbh.com





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

Reply | Threaded
Open this post in threaded view
|

Re: AW: [ECOS] Re: eCos Configuration Tool clewan and rebuild

Alex Schuilenburg-2
On 17/06/16 05:05, Richard Rauch wrote:
> There is one issue maybe. When we are changing major things in our eCos
> configuration, we delete the complete build tree folders with file system.
> Then the config tool is forced to rebuild everything.
> The folders are somehow named like .\.......build and .\....install\. They
> are located relative to your path, where the .ecc file is.
These are created <basename>_install and <basename>_build where
<basename> is the base name of the saved .ecc file.

Yes, when using the anoncvs GUI configtool the safest method when
changing configurations is to delete all and rebuild.

However, the anoncvs GUI configtool has a subtle major flaw when
creating a configuration by selecting a target that is not the default.
All new target configurations are created against the current target and
template (often default target and "default" template), and switched to
the new target (and/or template).  If you have two similar but distinct
targets you could end up with conflicts that the anoncvs GUI tool cannot
resolve automatically.  Even creating a new configuration for the
default target can and often does result in a slightly different
configuration (but entirely valid) to that created by ecosconfig.

If you are using the anoncvs tools, the safest way to create a new
configuration is to use "ecosconfig" - it is the tool that almost all
eCos maintainers outside eCosCentric use.

eCosPro users should upgrade to version 3.1.10 of the Host Tools which
exhibit none of the anoncvs host tools issues - new configurations
created by both tools are identical - and use the "File->New Target"
functionality illustrated in
http://www.ecoscentric.com/ecospro/doc/html/user-guide/using-configtool-windows-linux.html

-- Alex
http://www.ecoscentric.com/             The eCos Experts





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

Reply | Threaded
Open this post in threaded view
|

AW: AW: [ECOS] Re: eCos Configuration Tool clewan and rebuild

Richard Rauch
>
> However, the anoncvs GUI configtool has a subtle major flaw when creating
a
> configuration by selecting a target that is not the default.
> All new target configurations are created against the current target and
> template (often default target and "default" template), and switched to
the
> new target (and/or template).  If you have two similar but distinct
targets you
> could end up with conflicts that the anoncvs GUI tool cannot resolve
> automatically.  Even creating a new configuration for the default target
can
> and often does result in a slightly different configuration (but entirely
valid)
> to that created by ecosconfig.

We delete the build folders only, but not the .ecc file.
If rebuilding with GUI config tool (after build folders deleted) with same
.ecc file, the result is exactly the same!


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

Reply | Threaded
Open this post in threaded view
|

Re: AW: AW: [ECOS] Re: eCos Configuration Tool clewan and rebuild

Alex Schuilenburg
On 18/06/16 13:01, Richard Rauch wrote:
> We delete the build folders only, but not the .ecc file.
> If rebuilding with GUI config tool (after build folders deleted) with same
> .ecc file, the result is exactly the same!
It ought to be - the same libcdl is called to regenerate the build tree
if you use the same .ecc file.

What I am saying is:
  File->New in the anoncvs configtool
can generate a different configuration from the
  ecosconfig new <target>
anoncvs command.

-- Alex
http://www.ecoscentric.com/             The eCos Experts



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

Reply | Threaded
Open this post in threaded view
|

Input from debug console

Michael W. Ellis
In reply to this post by Grant Edwards-6
My application calls diag_printf() to display information to the debug
console using serial port 0 of my processor.  I would like to be able to
implement some simple diagnostics that are initiated through the console
port.  Is it possible to accept input from the console?  If so, how is
this done?

Michael

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

Reply | Threaded
Open this post in threaded view
|

RE: Input from debug console

Michael W. Ellis
> -----Original Message-----
> From: [hidden email] [mailto:ecos-discuss-
> [hidden email]] On Behalf Of Michael W. Ellis
> Sent: Thursday, June 30, 2016 9:54 AM
> To: [hidden email]
> Subject: [ECOS] Input from debug console
>
> My application calls diag_printf() to display information to the debug
> console using serial port 0 of my processor.  I would like to be able
> to implement some simple diagnostics that are initiated through the
> console port.  Is it possible to accept input from the console?  If
so,
> how is this done?

Correction - I'm using the AT91SAM9260 processor and the debug console
uses a serial port connected to the Debug Unit instead of serial port 0.
The console device name is "/dev/ttydiag".  Without writing new drivers,
is it possible to get simple input from this port?

Michael

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

Reply | Threaded
Open this post in threaded view
|

Re: Input from debug console

dushistov (Bugzilla)
On Thu, Jun 30, 2016 at 11:02:53AM -0500, Michael W. Ellis wrote:

> > -----Original Message-----
> > From: [hidden email] [mailto:ecos-discuss-
> > [hidden email]] On Behalf Of Michael W. Ellis
> > Sent: Thursday, June 30, 2016 9:54 AM
> > To: [hidden email]
> > Subject: [ECOS] Input from debug console
> >
> > My application calls diag_printf() to display information to the debug
> > console using serial port 0 of my processor.  I would like to be able
> > to implement some simple diagnostics that are initiated through the
> > console port.  Is it possible to accept input from the console?  If
> so,
> > how is this done?
>
> Correction - I'm using the AT91SAM9260 processor and the debug console
> uses a serial port connected to the Debug Unit instead of serial port 0.
> The console device name is "/dev/ttydiag".  Without writing new drivers,
> is it possible to get simple input from this port?
>

I read from /dev/dbgu on at91sam9363 using such code:

 cyg_io_handle_t serialH;
 err = cyg_io_lookup("/dev/dbgu", &serialH);
 cyg_io_read(serialH,...);

--
/Evgeniy

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

Reply | Threaded
Open this post in threaded view
|

Re: Input from debug console

Grant Edwards-6
In reply to this post by Michael W. Ellis
On 2016-06-30, Michael W. Ellis <[hidden email]> wrote:

>> -----Original Message-----
>> From: [hidden email] [mailto:ecos-discuss-
>> [hidden email]] On Behalf Of Michael W. Ellis
>> Sent: Thursday, June 30, 2016 9:54 AM
>> To: [hidden email]
>> Subject: [ECOS] Input from debug console
>>
>> My application calls diag_printf() to display information to the debug
>> console using serial port 0 of my processor.  I would like to be able
>> to implement some simple diagnostics that are initiated through the
>> console port.  Is it possible to accept input from the console?  If
> so,
>> how is this done?
>
> Correction - I'm using the AT91SAM9260 processor and the debug console
> uses a serial port connected to the Debug Unit instead of serial port 0.
> The console device name is "/dev/ttydiag".  Without writing new drivers,
> is it possible to get simple input from this port?

Does your eCos HAL profide hal_if_diag_read_char()?  I thought that
was pretty standard.  I modified my HAL to also provide a non-blocking
version of that call -- it only required writing a few lines of code.

--
Grant





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