This is the mail archive of the
ecos-devel@sourceware.org
mailing list for the eCos project.
Re: New hal port + interrupts + rescheduling + call_pending_dsrs problem
- From: Andrew Lunn <andrew at lunn dot ch>
- To: Davy Wouters <davy dot wouters dot atos at gmail dot com>
- Cc: ecos-devel at ecos dot sourceware dot org
- Date: Fri, 27 Jun 2008 20:24:56 +0200
- Subject: Re: New hal port + interrupts + rescheduling + call_pending_dsrs problem
- References: <111ced750806270740k430d9ca9we3f3f1bd84d65ab7@mail.gmail.com>
> I assume a return from interrupt should be executed somewhere between
> the execution of the isr/post_dsr and the call_pending_dsrs?
Nope. If the scheduler is not locked, the DSR is called in the
interrupt handler context. If the scheduler is locked, the DSR will be
called when the scheduler is unlocked.
> Is it correct that call_pending_dsrs should be executed only when
> other interrupts are allowed again, in other words after return from
> the interrupt?
After returning from the interrupt handler which has been registered
with eCos, but before the actual reti instruction, or what ever is
used to return the processor from interrupt context back into normal
context.
> Sorry if my questions are a bit confusing, but i don't quite
> understand the problems i'm having at this point (Crashes when having
> a lot of communication
> on my uart rx resulting in ASSERT_FAIL: <6>mutex.cxx[249]cyg_bool
> Cyg_Mutex::lock() Locking mutex I already own)
Is this crash in thread code? You are not allowed to use mutex, or any
other blocking call in ISR or DSR context.
Andrew