From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3183 invoked by alias); 30 Jun 2008 08:27:07 -0000 Received: (qmail 2907 invoked by uid 22791); 30 Jun 2008 08:27:05 -0000 X-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from yw-out-1718.google.com (HELO yw-out-1718.google.com) (74.125.46.156) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 30 Jun 2008 08:26:48 +0000 Received: by yw-out-1718.google.com with SMTP id 9so1118201ywk.66 for ; Mon, 30 Jun 2008 01:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=pjPrxkG582FnHAT6DX1BMRNBpGj6QSKgVS8LKB4HXEA=; b=ZA7qBWhRO57ev30fpH0oI2Snl7ECcg1rYjyBWk9R2/PTyKy86Jw4fy2KeSAwv21L83 fSCGQATI1pA8mhlmJ44WGZ52EhKdYQb89eFUdcjEwq8UlqqKhCqKOjgvwrHow37GentF 5IqxCu7F348D6Xh2Hz2wcFqii+W1x6/hyRokI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=toJdUENesPdeGJc9Rd96dni16bSSCoY5RnWO/5iBweQeQk7tNp5TNGE0WWLeiyr4N9 ArRe1NKnYZpVsofH94xREgSYZECimEfzYvZhiiZikH9mw/M/o+fwcXM+AOY6c+eXQm8/ W2VnvbUnGVIeIzbYH/1aa2NkfB/YafBvEpUIk= Received: by 10.151.144.15 with SMTP id w15mr7986082ybn.161.1214814404247; Mon, 30 Jun 2008 01:26:44 -0700 (PDT) Received: by 10.150.158.16 with HTTP; Mon, 30 Jun 2008 01:26:44 -0700 (PDT) Message-ID: <111ced750806300126v5ccc8120rcfa3cb106e891920@mail.gmail.com> Date: Mon, 30 Jun 2008 08:27:00 -0000 From: "Davy Wouters" To: "Andrew Lunn" Subject: Re: New hal port + interrupts + rescheduling + call_pending_dsrs problem Cc: ecos-devel@ecos.sourceware.org In-Reply-To: <20080627182456.GH696@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <111ced750806270740k430d9ca9we3f3f1bd84d65ab7@mail.gmail.com> <20080627182456.GH696@lunn.ch> Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2008-06/txt/msg00041.txt.bz2 Hi Andrew, I guess I got confused because i was thinking too much in the context of the processor in stead of that of eCos. The DSR mechanism has nothing to do with processor specific interrupt handling but more with the eCos kernel internal stuff, correct? In that case what is the exact role of the DSR in eCos? When to implement one or not in a device driver? I'm asking this because I thought that the DSR needed to be executed after returning from the interrupt (reti or what ever), which is not the case, in order to allow other interrupts at this point. I thought that when combining ISR and DSR in one interrupt handling of the processor, this would take too long and deteriorate real-time behaviour? Davy On Fri, Jun 27, 2008 at 8:24 PM, Andrew Lunn wrote: >> 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 >