public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] cyg_thread_delay vs cyg_flag_wait behavior
@ 2006-06-19 13:07 Chase, Tom
  2006-06-19 17:20 ` Andrew Lunn
  0 siblings, 1 reply; 3+ messages in thread
From: Chase, Tom @ 2006-06-19 13:07 UTC (permalink / raw)
  To: ecos-discuss

Hello,

I am working on my fourth ecos project.  Historically I have had a thread
monitoring a serial port.  The thread has the lowest priority and sits at a
getc until some data arrives then deals with it.  This has worked well for
debugging and configuration allowing a PC application to talk to the device
and set up frequencies or what not.

On the latest project this isn't working reliably.  It will work for a few
bytes of data then stop responding.  The change in performance appears to be
related to cyg_thread_delay vs. cyg_flag_wait.  For the first time, I have a
higher priority thread that has no cyg_thread_delays in it.  It sits at a
cyg_flag_wait most of the time (servicing flags every 100 to 250 ms).  If I
add a cyg_thread_delay to that thread (putting it just before the flag_wait
for example) then the serial behavior is as I expect.

I am working on an OMAP5912 and using the interrupt driven serial.  I have
verified that the thread is indeed waking up from the wait as I expect (10
times a second) and not always running (I.E. there is time available for
lower priority threads).  I have tried using various settings (buffered, non
buffered, stdin, TTY etc.) with no change in performance.  I have a
cyg_thread_delay that is called when the unit prepares to power down (to
lock out the keyboard) and any buffered serial inputs are handled then
(which is one clue to why this was happening).

I can add a delay but I would like to understand the differences between
these two functions while they are blocking.  Conceptually I think of the
delay and the wait doing the same thing and do not understand why they
behave differently while they are in effect.  Can anyone advise?  

Thanks,

Tom Chase
DTC Communications
Software Engineering Manager


-- 
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] 3+ messages in thread

* Re: [ECOS] cyg_thread_delay vs cyg_flag_wait behavior
  2006-06-19 13:07 [ECOS] cyg_thread_delay vs cyg_flag_wait behavior Chase, Tom
@ 2006-06-19 17:20 ` Andrew Lunn
  0 siblings, 0 replies; 3+ messages in thread
From: Andrew Lunn @ 2006-06-19 17:20 UTC (permalink / raw)
  To: Chase, Tom; +Cc: ecos-discuss

On Mon, Jun 19, 2006 at 09:07:26AM -0400, Chase, Tom wrote:
> Hello,
> 
> I am working on my fourth ecos project.  Historically I have had a thread
> monitoring a serial port.  The thread has the lowest priority and sits at a
> getc until some data arrives then deals with it.  This has worked well for
> debugging and configuration allowing a PC application to talk to the device
> and set up frequencies or what not.
> 
> On the latest project this isn't working reliably.  It will work for a few
> bytes of data then stop responding.  The change in performance appears to be
> related to cyg_thread_delay vs. cyg_flag_wait.  For the first time, I have a
> higher priority thread that has no cyg_thread_delays in it.  It sits at a
> cyg_flag_wait most of the time (servicing flags every 100 to 250 ms).  If I
> add a cyg_thread_delay to that thread (putting it just before the flag_wait
> for example) then the serial behavior is as I expect.
> 
> I am working on an OMAP5912 and using the interrupt driven serial.  I have
> verified that the thread is indeed waking up from the wait as I expect (10
> times a second) and not always running (I.E. there is time available for
> lower priority threads).  I have tried using various settings (buffered, non
> buffered, stdin, TTY etc.) with no change in performance.  I have a
> cyg_thread_delay that is called when the unit prepares to power down (to
> lock out the keyboard) and any buffered serial inputs are handled then
> (which is one clue to why this was happening).
> 
> I can add a delay but I would like to understand the differences between
> these two functions while they are blocking.  Conceptually I think of the
> delay and the wait doing the same thing and do not understand why they
> behave differently while they are in effect.  Can anyone advise?  

It sounds like the thread that is waiting is actually spinning inside
the wait function. From the sources:

    // this loop allows us to deal correctly with spurious wakeups
    while ( result && (0 == saveme.value_out) ) {
        self->set_sleep_reason( Cyg_Thread::WAIT );
        self->sleep();
        // keep track of myself on the queue of waiting threads
        queue.enqueue( self );

        // Allow other threads to run
        Cyg_Scheduler::reschedule();

So there is a while loop there making a spin possible. I would take a
closer look at this and see if it really is spinning rather than
sleeping, and if so why.

          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] 3+ messages in thread

* [ECOS] cyg_thread_delay vs cyg_flag_wait behavior
@ 2014-10-17 15:14 Leschke Serafin (lesc)
  0 siblings, 0 replies; 3+ messages in thread
From: Leschke Serafin (lesc) @ 2014-10-17 15:14 UTC (permalink / raw)
  To: ecos-discuss

hi and sorry to awake this zombie but I could not find anything other
then this old thread relating to my problem:


I have a programm (part of a driver ethernet driver) wich is needed to
do some perodic duties (sending special packets) and waiting for events
(handling special packets wich are not to be deleviered to the OS).
Waiting for this events is realised via flags because I get only one
interrupt for all packet and events ariving.

My Code loocks something like this:

initalize_threads(){
    /*init timer thread this is only used to create the timer so it can
has a custom priority*/
    cyg_thread_create(TIMER_PRIOROTY,
                      initialize_timer,
                      0,
                      "timer thread",
                      timer_stack,
                      TIMER_STACK_SIZE,
                      &timer_thread_hdl,
                      &timer_thread_obj);
    cyg_thread_resume(timer_thread_hdl);

    /*init irq dispatcher thread*/
    cyg_thread_create(DISPATCHER_PRIOROTY,
                      irq_dispatcher,
                      0,
                      "dispatcher thread",
                      dispatcher_stack,
                      DISPATCHER_STACK_SIZE,
                      &dispatcher_hdl,
                      &dispatcher_obj);
    cyg_thread_resume(dispatcher_hdl);
}

initialize_timer(cyg_addrword_t data){
     sys_clk= cyg_real_time_clock();
    cyg_clock_to_counter(sys_clk, &counter_hld);
    cyg_alarm_create(delay_req_counter_hld,
                    timer_handler,
                    (cyg_addrword_t)&_index,
                    &alarm_hld,
                    &alarm);
    cyg_alarm_initialize(alarm_hld,
                         START_DELAY,
                         TIMER_INTERVAL);
}

timer_handler(cyg_handle_t delay_req_alarm_hld,
                             cyg_addrword_t data){
        printf("WORKS!");
}

irq_dispatcher(cyg_addrword_t data){
    cyg_uint32 flags = 0;
    while (1){
        /*This do-while is not really imperative, it's just for the case
that the thread is woken up force-fully, which is probably never*/
        do{
            /* if I put a cyg_thread_delay() here everything works */
            flags = cyg_flag_wait(&isr_flags,PTCP_IRQ_FLAGS,
CYG_FLAG_WAITMODE_OR);
        }while(! flags);
        {
            /*Handling the events*/
          }
}

The Problem now is this only works if TIMER_PRIOROTY <
DISPATCHER_PRIOROTY otherwise the timer_handler is never called. On the
other hand it works if i put a cyg_thread_delay before my wait.

I hope I stated my problem clear, this is my first ecos project and I
still have quite a lot of trouble with it.

best regards Serafin

-- 
Serafin Leschke, BSc in Computer Sience UAS Zurich
Research Assistant

ZHAW, Zurich University of Applied Sciences
InES, Institute of Embedded Systems
Postfach
Technikumstr. 22
CH-8401 Winterthur
--
Tel: +41 58 934 69 79
Fax: +41 58 935 76 87
E-Mail: serafin.lescke@zhaw.ch
Web: http://ines.zhaw.ch
--


--
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] 3+ messages in thread

end of thread, other threads:[~2014-10-17 15:14 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-06-19 13:07 [ECOS] cyg_thread_delay vs cyg_flag_wait behavior Chase, Tom
2006-06-19 17:20 ` Andrew Lunn
2014-10-17 15:14 Leschke Serafin (lesc)

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).