[ECOS] Idle thread trying to sleep

[ECOS] Idle thread trying to sleep

[Trenton D. Adams]

This is what I'm doing.  I'm trying to delay 300ms inside a function.
This function is called in response to an interrupt.  Can I not delay
from within a DSR?  How would I delay without using the cyg_thread_delay
() function?  How am I supposed to know that I'm delaying the right
amount of time if I can't use cyg_thread_delay ()?


TRACE: <1>[376]CardInitialize() Enable Power
TRACE: <1>[379]CardInitialize() Delay 300 for powerup
ASSERT FAIL: <1>[191]void Cyg_Scheduler_Implementation::rem_thread()
Idle thread trying to sleep!

Re: [ECOS] Idle thread trying to sleep

[Hugo Tyson]

"Trenton D. Adams" <tadams@extremeeng.com> writes:
> This is what I'm doing.  I'm trying to delay 300ms inside a function.
> This function is called in response to an interrupt.  Can I not delay
> from within a DSR?  How would I delay without using the cyg_thread_delay

Correct, you cannot.

> () function?  How am I supposed to know that I'm delaying the right
> amount of time if I can't use cyg_thread_delay ()?

The uS delay function in the HAL and hal_if.h - it busy-waits, very
inefficient and all that.  That the unit is uS is a hint about how it's
appropriate to be used. ;-)

But more importantly, if you have to delay 300mS (one third of a second!)
you utterly should not do this within a DSR!  Use the DSR to awaken a high
priority thread, and have that do the work and the cyg_thread_delay() and
so on.  That's what DSRs and threads are for.

For one thing, looping in a DSR will cause you to lose 30 clock ticks,
because you'll block the system from running any other DSRs for all that
time.

HTH,
	- Huge

Re: [ECOS] Idle thread trying to sleep

[Fabrice Gautier]

On 06 Jul 2001 16:37:40 +0100
Hugo Tyson <hmt@redhat.com> wrote:
> 
> For one thing, looping in a DSR will cause you to lose 30 clock ticks,
> because you'll block the system from running any other DSRs for all that
> time.

Really? I thougth ISR were enabled during the DSR. And I thougth that
each ISR was taken into account to update the clock counter.

Thx,

-- 
Fabrice Gautier <gautier@email.enstfr>

Re: [ECOS] Idle thread trying to sleep

[Hugo Tyson]

Fabrice Gautier <gautier@email.enst.fr> writes:
> On 06 Jul 2001 16:37:40 +0100
> Hugo Tyson <hmt@redhat.com> wrote:
> > 
> > For one thing, looping in a DSR will cause you to lose 30 clock ticks,
> > because you'll block the system from running any other DSRs for all that
> > time.
> 
> Really? I thougth ISR were enabled during the DSR. And I thought that
> each ISR was taken into account to update the clock counter.

Actually, it can depend on the platform, but for most of the recent ports,
you're absolutely right.  What you describe is exactly the intent.  The
clock will likely be numerically right after all that time, but you'll have
missed (delayed) any alarms and events that were set to occur in the
interval, and any other DSRs of course.

	- Huge

RE: [ECOS] Idle thread trying to sleep

[Gary Thomas]

On 06-Jul-2001 Trenton D. Adams wrote:
> This is what I'm doing.  I'm trying to delay 300ms inside a function.
> This function is called in response to an interrupt.  Can I not delay
> from within a DSR?  How would I delay without using the cyg_thread_delay
> () function?  How am I supposed to know that I'm delaying the right
> amount of time if I can't use cyg_thread_delay ()?

You can't do anything which blocks, including sleeping, in a DSR since
DSRs are run anonymously.

The way to solve this is to have your DSR control a separate thread which
can sleep, etc.

Look at the CF ethernet code for an example.  There is a separate thread
which is used to handle card events.  When a card is inserted, the DSR 
will cause the thread to run.  That thread can then do things like enable
power, etc, which must be sequenced.

Note: it might be nice to have this sort of functionality as part of the
generic CF/PCMCIA support, but at the current time it is associated with
the specific card driver.

RE: [ECOS] Idle thread trying to sleep

[Trenton D. Adams]

  > On 06-Jul-2001 Trenton D. Adams wrote:
  > > This is what I'm doing.  I'm trying to delay 300ms inside 
  > a function. 
  > > This function is called in response to an interrupt.  Can 
  > I not delay 
  > > from within a DSR?  How would I delay without using the 
  > > cyg_thread_delay
  > > () function?  How am I supposed to know that I'm delaying 
  > the right
  > > amount of time if I can't use cyg_thread_delay ()?
  > 
  > You can't do anything which blocks, including sleeping, in 
  > a DSR since DSRs are run anonymously.
  > 
  > The way to solve this is to have your DSR control a 
  > separate thread which can sleep, etc.
  > 
  > Look at the CF ethernet code for an example.  There is a 
  > separate thread which is used to handle card events.  When 
  > a card is inserted, the DSR 
  > will cause the thread to run.  That thread can then do 
  > things like enable power, etc, which must be sequenced.

Yes, I've seen that code.  I suppose it would be best to do it in a
thread.  How would I know when the card is ready to use though?  Should
I maybe use a mutex or a semaphore in my card driver and PCMCIA driver?
The PCMCIA driver could make the semaphore/mutex global and then my card
driver could attempt access and be blocked until the PCMCIA has
initialized the card.  Which should I use, a semaphore or a mutex?

  > Note: it might be nice to have this sort of functionality 
  > as part of the generic CF/PCMCIA support, but at the 
  > current time it is associated with the specific card driver.

I'm trying to get it working inside my PCMCIA driver so I don't have to
do it in the card driver.


p.s.
I'm kind of doing my PCMCIA driver and CARD driver at the same time.

Thanks Gary and Hugo.