[ECOS] gdb remote debug problem...running an ecos application...

[ECOS] gdb remote debug problem...running an ecos application...

[Srinivasan Sriram]

Hello!
Could someone help me fix this problem -
I use Linux as host and PC as target.
Using 
dd conv=sync if=./gdb_module.bin of=/dev/fd0h1440
I copy the .bin file on to a floopy.
I connect my host to target via a null modem cable.
When my target PC boots from this floppy, I see the
following line on the target monitor-
++$T0508:a43.....and so on.

I type i386-elf-gdb -nw hello, then I get the (gdb)
prompt.
I type the following -
(gdb) set remotebaud 38400
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
Ignoring packet error, continuing....
Ignoring packet error, continuing....
Ignoring packet error, continuing....
Couldn't establish connection to remote target
Malformed response to offset query, timeout
(gdb)load
You can't do that when your target is 'exec'.

----
1.Is this due to mismatch of baudrate of host and
target?
Setting baudrate to 19200 gives me the same output.
2. How do I run my application on the target?

Thanks
Kavita



__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

Re: [ECOS] gdb remote debug problem...running an ecos application...

[Christoph Csebits]

On Wed, Jun 06, 2001 at 05:44:06AM -0700, Srinivasan Sriram wrote:
> I type the following -
> (gdb) set remotebaud 38400
> (gdb) target remote /dev/ttyS0
> Remote debugging using /dev/ttyS0
> Ignoring packet error, continuing....
> Ignoring packet error, continuing....
> Ignoring packet error, continuing....

Use 
set debug remote 1
for tracing the packets

Christoph

Re: [ECOS] gdb remote debug problem...running an ecos application...

[Jonathan Larmour]

Srinivasan Sriram wrote:
> 
> Hello!
> Could someone help me fix this problem -
> I use Linux as host and PC as target.
> Using
> dd conv=sync if=./gdb_module.bin of=/dev/fd0h1440
> I copy the .bin file on to a floopy.
> I connect my host to target via a null modem cable.
> When my target PC boots from this floppy, I see the
> following line on the target monitor-
> ++$T0508:a43.....and so on.

This looks right.
 
> I type i386-elf-gdb -nw hello, then I get the (gdb)
> prompt.
> I type the following -
> (gdb) set remotebaud 38400
> (gdb) target remote /dev/ttyS0
> Remote debugging using /dev/ttyS0
> Ignoring packet error, continuing....
> Ignoring packet error, continuing....
> Ignoring packet error, continuing....
> Couldn't establish connection to remote target
> Malformed response to offset query, timeout
> (gdb)load
> You can't do that when your target is 'exec'.
> 
> ----
> 1.Is this due to mismatch of baudrate of host and
> target?
> Setting baudrate to 19200 gives me the same output.
> 2. How do I run my application on the target?

It could be a serial overrun. Try again with "set remotedebug 1" fist
before the target remote and post the results here.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions    http://www.redhat-techworld.com/

Re: [ECOS] gdb remote debug problem...running an ecos application...

[Srinivasan Sriram]

Hello!
When I use -
set remote debug 1, 
I get the following output...

Sending packet: $Hc-1#09...Sending packet:
$Hc-1#09...Sending packet: $Hc-1#09..
Sending packet: $Hc-1#09...Timed out.
Timed out.
Timed out.
Ignoring packet error, continuing...
Sending packet: $qC#b4...Sending packet:
$qC#b4...Sending packet: $qC#b4...Sendi
ng packet: $qC#b4...Timed out.
Timed out.
Timed out.
Ignoring packet error, continuing...
Sending packet: $qOffsets#4b...Sending packet:
$qOffsets#4b...Sending packet: $q
Offsets#4b...Sending packet: $qOffsets#4b...Timed out.
Timed out.
Timed out.
Ignoring packet error, continuing...
Couldn't establish connection to remote target
Malformed response to offset query, timeout
(gdb)
 
-----
I repeated the above with lower baudrates, but there
seems to be no variation in the output.

Just to check if my serial null modem connected at
COM2 is working fine, I ran kermit on Linux host and
Hyperterminal on my target. There is no loss of data
at 38400 baud.

Could you help me debug this problem?
thanks
Kavita

--- Jonathan Larmour <jlarmour@redhat.com> wrote:
> Srinivasan Sriram wrote:
> > 
> > Hello!
> > Could someone help me fix this problem -
> > I use Linux as host and PC as target.
> > Using
> > dd conv=sync if=./gdb_module.bin of=/dev/fd0h1440
> > I copy the .bin file on to a floopy.
> > I connect my host to target via a null modem
> cable.
> > When my target PC boots from this floppy, I see
> the
> > following line on the target monitor-
> > ++$T0508:a43.....and so on.
> 
> This looks right.
>  
> > I type i386-elf-gdb -nw hello, then I get the
> (gdb)
> > prompt.
> > I type the following -
> > (gdb) set remotebaud 38400
> > (gdb) target remote /dev/ttyS1
> > Remote debugging using /dev/ttyS1
> > Ignoring packet error, continuing....
> > Ignoring packet error, continuing....
> > Ignoring packet error, continuing....
> > Couldn't establish connection to remote target
> > Malformed response to offset query, timeout
> > (gdb)load
> > You can't do that when your target is 'exec'.
> > 
> > ----
> > 1.Is this due to mismatch of baudrate of host and
> > target?
> > Setting baudrate to 19200 gives me the same
> output.
> > 2. How do I run my application on the target?
> 
> It could be a serial overrun. Try again with "set
> remotedebug 1" fist
> before the target remote and post the results here.
> 
> Jifl
> -- 
> Red Hat, Rustat House, Clifton Road, Cambridge, UK.
> Tel: +44 (1223) 271062
> Maybe this world is another planet's Hell -Aldous
> Huxley || Opinions==mine
> Come to the Red Hat TechWorld open source conference
> in Brussels!
> Keynotes, techie talks and exhibitions   
http://www.redhat-techworld.com/


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

Re: [ECOS] gdb remote debug problem...running an ecos applicatio

[Gary Thomas]

On 07-Jun-2001 Srinivasan Sriram wrote:
> Hello!
> When I use -
> set remote debug 1, 
> I get the following output...
> 
> Sending packet: $Hc-1#09...Sending packet:
> $Hc-1#09...Sending packet: $Hc-1#09..
> Sending packet: $Hc-1#09...Timed out.
> Timed out.
> Timed out.
> Ignoring packet error, continuing...
> Sending packet: $qC#b4...Sending packet:
> $qC#b4...Sending packet: $qC#b4...Sendi
> ng packet: $qC#b4...Timed out.
> Timed out.
> Timed out.
> Ignoring packet error, continuing...
> Sending packet: $qOffsets#4b...Sending packet:
> $qOffsets#4b...Sending packet: $q
> Offsets#4b...Sending packet: $qOffsets#4b...Timed out.
> Timed out.
> Timed out.
> Ignoring packet error, continuing...
> Couldn't establish connection to remote target
> Malformed response to offset query, timeout
> (gdb)
>  
> -----
> I repeated the above with lower baudrates, but there
> seems to be no variation in the output.
> 
> Just to check if my serial null modem connected at
> COM2 is working fine, I ran kermit on Linux host and
> Hyperterminal on my target. There is no loss of data
> at 38400 baud.
> 
> Could you help me debug this problem?

Try typing the debug commands manually, via hyperterm.  

  Connect to the unit
  Reset & wait for it to start
  Send '$Hc-1#09'  (it shouldn't echo anything)
  See what comes back

> thanks
> Kavita
> 
> --- Jonathan Larmour <jlarmour@redhat.com> wrote:
>> Srinivasan Sriram wrote:
>> > 
>> > Hello!
>> > Could someone help me fix this problem -
>> > I use Linux as host and PC as target.
>> > Using
>> > dd conv=sync if=./gdb_module.bin of=/dev/fd0h1440
>> > I copy the .bin file on to a floopy.
>> > I connect my host to target via a null modem
>> cable.
>> > When my target PC boots from this floppy, I see
>> the
>> > following line on the target monitor-
>> > ++$T0508:a43.....and so on.
>> 
>> This looks right.
>>  
>> > I type i386-elf-gdb -nw hello, then I get the
>> (gdb)
>> > prompt.
>> > I type the following -
>> > (gdb) set remotebaud 38400
>> > (gdb) target remote /dev/ttyS1
>> > Remote debugging using /dev/ttyS1
>> > Ignoring packet error, continuing....
>> > Ignoring packet error, continuing....
>> > Ignoring packet error, continuing....
>> > Couldn't establish connection to remote target
>> > Malformed response to offset query, timeout
>> > (gdb)load
>> > You can't do that when your target is 'exec'.
>> > 
>> > ----
>> > 1.Is this due to mismatch of baudrate of host and
>> > target?
>> > Setting baudrate to 19200 gives me the same
>> output.
>> > 2. How do I run my application on the target?
>> 
>> It could be a serial overrun. Try again with "set
>> remotedebug 1" fist
>> before the target remote and post the results here.
>> 
>> Jifl
>> -- 
>> Red Hat, Rustat House, Clifton Road, Cambridge, UK.
>> Tel: +44 (1223) 271062
>> Maybe this world is another planet's Hell -Aldous
>> Huxley || Opinions==mine
>> Come to the Red Hat TechWorld open source conference
>> in Brussels!
>> Keynotes, techie talks and exhibitions   
> http://www.redhat-techworld.com/
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail - only $35 
> a year!  http://personal.mail.yahoo.com/

Re: [ECOS] gdb remote debug problem...running an ecos applicatio

[Srinivasan Sriram]

Greetings!

I think I have solved the problem partially though I'm
left with some doubts.

The mistake I had done was to connect the null modem
cable to my target's com2.
Connecting it to com1 and typing
(gdb)load hello.o
on my host set my program running.

There is yet another hiccup!
1. On my target screen I see a lot of output and
somewhere highlighted in between is my output "HEllo
world". How do I eliminate all that output?

2. I would like to eliminate null modem cable and
remote debugging. Now I want to boot my target and
execute my program from a floppy.
What are the files that need to go to the floopy,
inorder to achieve this end?

Any documentation or help in this regard?

Kavita

--- Gary Thomas <gthomas@cambridge.redhat.com> wrote:
> 
> On 07-Jun-2001 Srinivasan Sriram wrote:
> > Hello!
> > When I use -
> > set remote debug 1, 
> > I get the following output...
> > 
> > Sending packet: $Hc-1#09...Sending packet:
> > $Hc-1#09...Sending packet: $Hc-1#09..
> > Sending packet: $Hc-1#09...Timed out.
> > Timed out.
> > Timed out.
> > Ignoring packet error, continuing...
> > Sending packet: $qC#b4...Sending packet:
> > $qC#b4...Sending packet: $qC#b4...Sendi
> > ng packet: $qC#b4...Timed out.
> > Timed out.
> > Timed out.
> > Ignoring packet error, continuing...
> > Sending packet: $qOffsets#4b...Sending packet:
> > $qOffsets#4b...Sending packet: $q
> > Offsets#4b...Sending packet: $qOffsets#4b...Timed
> out.
> > Timed out.
> > Timed out.
> > Ignoring packet error, continuing...
> > Couldn't establish connection to remote target
> > Malformed response to offset query, timeout
> > (gdb)
> >  
> > -----
> > I repeated the above with lower baudrates, but
> there
> > seems to be no variation in the output.
> > 
> > Just to check if my serial null modem connected at
> > COM2 is working fine, I ran kermit on Linux host
> and
> > Hyperterminal on my target. There is no loss of
> data
> > at 38400 baud.
> > 
> > Could you help me debug this problem?
> 
> Try typing the debug commands manually, via
> hyperterm.  
> 
>   Connect to the unit
>   Reset & wait for it to start
>   Send '$Hc-1#09'  (it shouldn't echo anything)
>   See what comes back
> 
> > thanks
> > Kavita
> > 
> > --- Jonathan Larmour <jlarmour@redhat.com> wrote:
> >> Srinivasan Sriram wrote:
> >> > 
> >> > Hello!
> >> > Could someone help me fix this problem -
> >> > I use Linux as host and PC as target.
> >> > Using
> >> > dd conv=sync if=./gdb_module.bin
> of=/dev/fd0h1440
> >> > I copy the .bin file on to a floopy.
> >> > I connect my host to target via a null modem
> >> cable.
> >> > When my target PC boots from this floppy, I see
> >> the
> >> > following line on the target monitor-
> >> > ++$T0508:a43.....and so on.
> >> 
> >> This looks right.
> >>  
> >> > I type i386-elf-gdb -nw hello, then I get the
> >> (gdb)
> >> > prompt.
> >> > I type the following -
> >> > (gdb) set remotebaud 38400
> >> > (gdb) target remote /dev/ttyS1
> >> > Remote debugging using /dev/ttyS1
> >> > Ignoring packet error, continuing....
> >> > Ignoring packet error, continuing....
> >> > Ignoring packet error, continuing....
> >> > Couldn't establish connection to remote target
> >> > Malformed response to offset query, timeout
> >> > (gdb)load
> >> > You can't do that when your target is 'exec'.
> >> > 
> >> > ----
> >> > 1.Is this due to mismatch of baudrate of host
> and
> >> > target?
> >> > Setting baudrate to 19200 gives me the same
> >> output.
> >> > 2. How do I run my application on the target?
> >> 
> >> It could be a serial overrun. Try again with "set
> >> remotedebug 1" fist
> >> before the target remote and post the results
> here.
> >> 
> >> Jifl
> >> -- 
> >> Red Hat, Rustat House, Clifton Road, Cambridge,
> UK.
> >> Tel: +44 (1223) 271062
> >> Maybe this world is another planet's Hell -Aldous
> >> Huxley || Opinions==mine
> >> Come to the Red Hat TechWorld open source
> conference
> >> in Brussels!
> >> Keynotes, techie talks and exhibitions   
> > http://www.redhat-techworld.com/
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Get personalized email addresses from Yahoo! Mail
> - only $35 
> > a year!  http://personal.mail.yahoo.com/


__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/

Re: [ECOS] gdb remote debug problem...running an ecos applicatio

[Jonathan Larmour]

Srinivasan Sriram wrote:
> 
> 1. On my target screen I see a lot of output and
> somewhere highlighted in between is my output "HEllo
> world". How do I eliminate all that output?
> 
> 2. I would like to eliminate null modem cable and
> remote debugging. Now I want to boot my target and
> execute my program from a floppy.
> What are the files that need to go to the floopy,
> inorder to achieve this end?
> 
> Any documentation or help in this regard?

For a start, we've just revamped all the x86 support last Friday. I'd
strongly recommend updating to current CVS.

After that it should just be a case of changing the CYG_HAL_STARTUP in your
eCos configuration to floppy, rebuilding eCos and then relinking your app.
Then convert your built app to binary format and write it to floppy.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions    http://www.redhat-techworld.com/

Re: [ECOS] gdb remote debug problem...running an ecos applicatio

[Srinivasan Sriram]

Hello!

I'm trying out condition variables for 
the first time.
As per the reference manual,
cyg_cond_wait releases the mutex (I don't 
have to explicitly use 
cyg_mutex_release(&mut)).

But incase of cyg_cond_broadcast, I quote 
from the documentation - "Wakes all the 
threads waiting on the condition variable.
 Each time a thread is awakened it will
become the current owner of the mutex."

But the threads waiting on the condition 
variables are not awakened until I 
explicitly release the mutex after 
cyg_cond_broadcast call.

Please look at my dummy code where thr1 
and thr3 act as consumers and thr2 is the 
producer.

-----
#include<stdio.h>
#include<cyg/kernel/kapi.h>
 
cyg_thread thr[3];
char stack[3][4096];
cyg_handle_t hthr1,hthr2,hthr3;
cyg_thread_entry_t fthr1,fthr2,fthr3;
cyg_thread thr1,thr2,thr3;
cyg_mutex_t mut;
cyg_cond_t cond;
int i;
 
cyg_user_start()
{
 
cyg_thread_create(1,fthr1,(cyg_addrword_t)0,"THREADA",(void
*)stack[0],4096,&hthr1,&thr[0]);

cyg_thread_create(2,fthr2,(cyg_addrword_t)0,"THREADB",(void
*)stack[1],4096,&hthr2,&thr[1]);

cyg_thread_create(1,fthr3,(cyg_addrword_t)0,"THREADC",(void
*)stack[2],4096,&hthr3,&thr[2]);
cyg_thread_resume(hthr1);
cyg_thread_resume(hthr2);
cyg_thread_resume(hthr3);
cyg_mutex_init(&mut);
cyg_cond_init(&cond,&mut);
}
 
 
void  fthr1(cyg_addrword_t y)
{
 
cyg_bool_t a;
a=cyg_mutex_lock(&mut);
printf("thr1 %d\n",(char *)a);
 
cyg_cond_wait(&cond);
printf("thr1..unlocking \n");
cyg_mutex_unlock(&mut);
 
printf("thr1 exiting \n");
}
 
void fthr2(cyg_addrword_t y)
{
cyg_bool_t a;
 
a=cyg_mutex_lock(&mut);
printf("thr2 %d\n",a);
 
cyg_thread_delay(200);
cyg_cond_broadcast(&cond);
printf("thr2..after broadcast \n");

cyg_mutex_unlock(&mut); /*I HAVE TO EXPLICITLY USE
THIS*/

printf("thr2 exiting....\n");
}
 
void fthr3(cyg_addrword_t y)
{
cyg_bool_t a1;
a1=cyg_mutex_lock(&mut);
printf("thr3 %d\n",a1);
 
cyg_cond_wait(&cond);
printf("thr3...unlocking \n");
 
cyg_mutex_unlock(&mut);
printf("thr3 exiting \n ");
}
                                      
----------
I GET THE FOLLOWING O/P ->

thr1 1
thr3 1
thr2 1
thr2..after broadcast
thr1..unlocking
thr1 exiting
thr3.unlocking
thr3 exiting
thr2 exiting....

----
IN CASE I COMMENT CYG_MUTEX_UNLOCK AND EXPECT
CYG_COND_BROADCAST  TO AUTOMATICALLY RELEASE THE 
MUTEX, THE THREADS THR1 AND THR3 ARE NOT AWAKENED. THE
O/P IS -

thr1 1
thr3 1
thr2 1
thr2..after broadcast
thr2 exiting....   

--------------------

1.
Can anyone explain this? Why should thr2 release the
mutex when cyg_cond_broadcast should automatically
release it?                                 

2. The ecos documentation says, I quote -
The thread can only be awakened by a call to
cyg_cond_signal() or
cyg_cond_broadcast() on the same condition variable.
When the thread is awakened, the
mutex will be reclaimed before this function proceeds.
Since it may have to wait for this,
cyg_cond_wait() should only be used in a loop since
the condition may become false in the
meantime. This is shown in the following example: 

  extern cyg_mutex_t mutex;
  extern cyg_cond_t cond;

  cyg_mutex_lock( &mutex );
  ...

  while( condition_not_true )
  {
   cyg_cond_wait( &cond );
  }

  ...

  cyg_mutex_unlock( &mutex );

------

WHY DO WE REQUIRE THE WHILE LOOP? ANY WAY THE
CYG_COND_WAIT CANNOT PROCEED BEFORE IT OBTAINS THE
MUTEX AND BROADCAST FROM THE PRODUCER AND OTHER
THREADS?

ALSO COULD ANYONE EXPLAIN - WHAT IS THE VARIABLE IN
THE WHILE LOOP. WHAT DOES IT TEST?

thanks
Kavita


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

[ECOS] CONDITION VARIABLES & MUTEXES

[Srinivasan Sriram]

Hello!

I'm trying out condition variables for 
the first time.
As per the reference manual,
cyg_cond_wait releases the mutex (I don't 
have to explicitly use 
cyg_mutex_release(&mut)).

But incase of cyg_cond_broadcast, I quote 
from the documentation - "Wakes all the 
threads waiting on the condition variable.
 Each time a thread is awakened it will
become the current owner of the mutex."

But the threads waiting on the condition 
variables are not awakened until I 
explicitly release the mutex after 
cyg_cond_broadcast call.

Please look at my dummy code where thr1 
and thr3 act as consumers and thr2 is the 
producer.

-----
#include<stdio.h>
#include<cyg/kernel/kapi.h>
 
cyg_thread thr[3];
char stack[3][4096];
cyg_handle_t hthr1,hthr2,hthr3;
cyg_thread_entry_t fthr1,fthr2,fthr3;
cyg_thread thr1,thr2,thr3;
cyg_mutex_t mut;
cyg_cond_t cond;
int i;
 
cyg_user_start()
{
 
cyg_thread_create(1,fthr1,(cyg_addrword_t)0,"THREADA",(void
*)stack[0],4096,&hthr1,&thr[0]);

cyg_thread_create(2,fthr2,(cyg_addrword_t)0,"THREADB",(void
*)stack[1],4096,&hthr2,&thr[1]);

cyg_thread_create(1,fthr3,(cyg_addrword_t)0,"THREADC",(void
*)stack[2],4096,&hthr3,&thr[2]);
cyg_thread_resume(hthr1);
cyg_thread_resume(hthr2);
cyg_thread_resume(hthr3);
cyg_mutex_init(&mut);
cyg_cond_init(&cond,&mut);
}
 
 
void  fthr1(cyg_addrword_t y)
{
 
cyg_bool_t a;
a=cyg_mutex_lock(&mut);
printf("thr1 %d\n",(char *)a);
 
cyg_cond_wait(&cond);
printf("thr1..unlocking \n");
cyg_mutex_unlock(&mut);
 
printf("thr1 exiting \n");
}
 
void fthr2(cyg_addrword_t y)
{
cyg_bool_t a;
 
a=cyg_mutex_lock(&mut);
printf("thr2 %d\n",a);
 
cyg_thread_delay(200);
cyg_cond_broadcast(&cond);
printf("thr2..after broadcast \n");

cyg_mutex_unlock(&mut); /*I HAVE TO EXPLICITLY USE
THIS*/

printf("thr2 exiting....\n");
}
 
void fthr3(cyg_addrword_t y)
{
cyg_bool_t a1;
a1=cyg_mutex_lock(&mut);
printf("thr3 %d\n",a1);
 
cyg_cond_wait(&cond);
printf("thr3...unlocking \n");
 
cyg_mutex_unlock(&mut);
printf("thr3 exiting \n ");
}
                                      
----------
I GET THE FOLLOWING O/P ->

thr1 1
thr3 1
thr2 1
thr2..after broadcast
thr1..unlocking
thr1 exiting
thr3.unlocking
thr3 exiting
thr2 exiting....

----
IN CASE I COMMENT CYG_MUTEX_UNLOCK AND EXPECT
CYG_COND_BROADCAST  TO AUTOMATICALLY RELEASE THE 
MUTEX, THE THREADS THR1 AND THR3 ARE NOT AWAKENED. THE
O/P IS -

thr1 1
thr3 1
thr2 1
thr2..after broadcast
thr2 exiting....   

--------------------

1.
Can anyone explain this? Why should thr2 release the
mutex when cyg_cond_broadcast should automatically
release it?                                 

2. The ecos documentation says, I quote -
The thread can only be awakened by a call to
cyg_cond_signal() or
cyg_cond_broadcast() on the same condition variable.
When the thread is awakened, the
mutex will be reclaimed before this function proceeds.
Since it may have to wait for this,
cyg_cond_wait() should only be used in a loop since
the condition may become false in the
meantime. This is shown in the following example: 

  extern cyg_mutex_t mutex;
  extern cyg_cond_t cond;

  cyg_mutex_lock( &mutex );
  ...

  while( condition_not_true )
  {
   cyg_cond_wait( &cond );
  }

  ...

  cyg_mutex_unlock( &mutex );

------

WHY DO WE REQUIRE THE WHILE LOOP? ANY WAY THE
CYG_COND_WAIT CANNOT PROCEED BEFORE IT OBTAINS THE
MUTEX AND BROADCAST FROM THE PRODUCER AND OTHER
THREADS?

ALSO COULD ANYONE EXPLAIN - WHAT IS THE VARIABLE IN
THE WHILE LOOP. WHAT DOES IT TEST?

thanks
Kavita


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Re: [ECOS] gdb remote debug problem...running an ecos applicatio

[Hugo Tyson]

Srinivasan Sriram <pet_jimmy@yahoo.com> writes:

> I'm trying out condition variables for the first time.  As per the
> reference manual, cyg_cond_wait releases the mutex (I don't have to
> explicitly use cyg_mutex_release(&mut)).

(and reclaims it - which may require waiting further - when the condition
 variable is signalled)
 
> But incase of cyg_cond_broadcast, I quote from the documentation - "Wakes
> all the threads waiting on the condition variable.  Each time a thread is
> awakened it will become the current owner of the mutex."

Yes, that's right.  But if there are many threads, they will wait in turn
for each other to release the mutex.  That's what mutexes do.

> But the threads waiting on the condition variables are not awakened until
> I explicitly release the mutex after cyg_cond_broadcast call.

Yes they are - and then they immediately sleep again waiting for the mutex
instead of the codition variable, because someone else holds the mutex.
The someone else happens to be the thread that did the cyg_cond_broadcast()
in your code, but that's your choice in the way you wrote your application.

> 1.
> Can anyone explain this? Why should thr2 release the
> mutex when cyg_cond_broadcast should automatically
> release it?                                 

No, cyg_cond_broadcast SHOULD NOT automatically release the mutex; there is
no requirement to own a mutex when you broadcast to the associated
condition variable.  Anyone can set or broadcast the condition variable.
A DSR can set or broadcast a condition variable asynchronously!
 
> 2. The ecos documentation says, I quote -
> The thread can only be awakened by a call to cyg_cond_signal() or
> cyg_cond_broadcast() on the same condition variable.  When the thread is
> awakened, the mutex will be reclaimed before this function proceeds.
> Since it may have to wait for this, cyg_cond_wait() should only be used
> in a loop since the condition may become false in the meantime. This is
> shown in the following example:
> 
>   extern cyg_mutex_t mutex;
>   extern cyg_cond_t cond;
> 
>   cyg_mutex_lock( &mutex );
>   ...
> 
>   while( condition_not_true )
>   {
>    cyg_cond_wait( &cond );
>   }
> 
>   ...
> 
>   cyg_mutex_unlock( &mutex );
> 
> ------
> 
> WHY DO WE REQUIRE THE WHILE LOOP? ANY WAY THE CYG_COND_WAIT CANNOT
> PROCEED BEFORE IT OBTAINS THE MUTEX AND BROADCAST FROM THE PRODUCER AND
> OTHER THREADS?

It can proceed, but it might not want to - a condition variable does not
tell you things like "there is data in the buffer", it can only tell you
"there *might* be data in the buffer".  So you must check whether there is
data in the buffer before deciding to do the work to deal with that data.

In a simple application you might not need the loop.  But if you modify it
later you might get nasty bugs if you don't write this using a loop.

Suppose you have two threads both doing this but only one "thing" arrives.
Both threads awaken.  The first to get the mutex handles the "thing" and
releases the mutex.  The second thread wakes up and wants to handle a
"thing" but there is no "thing" there - because the other thread already
handled it.  So the second thread should just wait on the condition again.
That's what the loop does.

> ALSO COULD ANYONE EXPLAIN - WHAT IS THE VARIABLE IN
> THE WHILE LOOP. WHAT DOES IT TEST?

It's an example.  The "variable" should be replaced by whatever condition
you are waiting for.  If you are waiting for a buffer to contain data for
you to handle, you must write "buffp->length > 0" or whatever the correct
code is for your application.  (Ie. the "is there a thing there" test)

A condition variable is a way to wake up threads and pass hints about your
data structures.  It doesn't know anything about your data structures, only
you do, and only you can test whether your data structure truly needs
attention.

	- Huge

Re: [ECOS] CONDITION VARIABLES & MUTEXES

[Robin Farine]

Srinivasan Sriram <pet_jimmy@yahoo.com> writes:

[...]

> cyg_user_start()
> {
>  
> cyg_thread_create(1,fthr1,(cyg_addrword_t)0,"THREADA",(void
> *)stack[0],4096,&hthr1,&thr[0]);
> 
> cyg_thread_create(2,fthr2,(cyg_addrword_t)0,"THREADB",(void
> *)stack[1],4096,&hthr2,&thr[1]);
> 
> cyg_thread_create(1,fthr3,(cyg_addrword_t)0,"THREADC",(void
> *)stack[2],4096,&hthr3,&thr[2]);
> cyg_thread_resume(hthr1);
> cyg_thread_resume(hthr2);
> cyg_thread_resume(hthr3);
> cyg_mutex_init(&mut);
> cyg_cond_init(&cond,&mut);

Bug here, you should initialize the mutex and condition variable *before* using
them, i.e. before starting the threads!

[...]

> 
> WHY DO WE REQUIRE THE WHILE LOOP? ANY WAY THE
> CYG_COND_WAIT CANNOT PROCEED BEFORE IT OBTAINS THE
> MUTEX AND BROADCAST FROM THE PRODUCER AND OTHER
> THREADS?
> 
> ALSO COULD ANYONE EXPLAIN - WHAT IS THE VARIABLE IN
> THE WHILE LOOP. WHAT DOES IT TEST?
> 

Friendly advice: read some articles or books on this subject (threads,
semaphores, condition variables,.) or get ready for big troubles (such as
race-conditions, dead-locks,. not the easiest bugs to find out).

[ECOS] Re: CONDITION VARIABLES & MUTEXES

[Jonathan Larmour]

Srinivasan Sriram wrote:
> 
> 1.
> Can anyone explain this? Why should thr2 release the
> mutex when cyg_cond_broadcast should automatically
> release it?

You read too much into the documentation. When it says that
cyg_cond_broadcast() wakes all threads waiting on the CVS and the wakened
thread becomes the owner of the mutex, it *doesn't* mean that the broadcast
does an implicit unlock. Producer threads are not meant to be locking and
unlocking the mutex underlying the cv.
 
> 2. The ecos documentation says, I quote -
> The thread can only be awakened by a call to
> cyg_cond_signal() or
> cyg_cond_broadcast() on the same condition variable.
> When the thread is awakened, the
> mutex will be reclaimed before this function proceeds.
> Since it may have to wait for this,
> cyg_cond_wait() should only be used in a loop since
> the condition may become false in the
> meantime. This is shown in the following example:
> 
>   extern cyg_mutex_t mutex;
>   extern cyg_cond_t cond;
> 
>   cyg_mutex_lock( &mutex );
>   ...
> 
>   while( condition_not_true )
>   {
>    cyg_cond_wait( &cond );
>   }
> 
>   ...
> 
>   cyg_mutex_unlock( &mutex );
> 
> ------
> 
> WHY DO WE REQUIRE THE WHILE LOOP? ANY WAY THE
> CYG_COND_WAIT CANNOT PROCEED BEFORE IT OBTAINS THE
> MUTEX AND BROADCAST FROM THE PRODUCER AND OTHER
> THREADS?

Two threads waiting on the condition may be woken up. They won't run at the
same time since only one can have the mutex locked, but when the second one
runs, the condition will not be true any more.
 
> ALSO COULD ANYONE EXPLAIN - WHAT IS THE VARIABLE IN
> THE WHILE LOOP. WHAT DOES IT TEST?

The condition you are waiting for...

As Robin says, you should read some general books about concurrency theory.
There's probably stuff on the web, or I can recommend Concurrent Systems by
J. Bacon published by Addison Wesley.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions    http://www.redhat-techworld.com/

Re: [ECOS] Re: CONDITION VARIABLES & MUTEXES

[Robin Farine]

The following URL provides interesting stuff on this subject:

        http://www.bell-labs.com/topic/books/os-book/

Robin