From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24492 invoked by alias); 24 Jun 2005 13:18:42 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 24444 invoked by uid 22791); 24 Jun 2005 13:18:34 -0000 Received: from londo.lunn.ch (HELO londo.lunn.ch) (80.238.139.98) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 24 Jun 2005 13:18:34 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1Dlo3T-00041O-00; Fri, 24 Jun 2005 15:17:11 +0200 Date: Fri, 24 Jun 2005 13:18:00 -0000 To: e.coullien@faiveley.com Cc: ecos-discuss@ecos.sourceware.org Message-ID: <20050624131711.GC7187@lunn.ch> Mail-Followup-To: e.coullien@faiveley.com, ecos-discuss@ecos.sourceware.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i From: Andrew Lunn Subject: Re: [ECOS] eCos Interrupt timing X-SW-Source: 2005-06/txt/msg00241.txt.bz2 On Fri, Jun 24, 2005 at 02:59:07PM +0200, e.coullien@faiveley.com wrote: > > > > Hello, > > We try to understand what ecos is doing when receiving an interrupt. > We modified temporally the file vector.S to trace on a logic output a signal > that represent how long is the interrupt time process > In this file, we set the signal before the context saving and we unset it just > before the context restoring > Then on the oscilloscope, we see that the signal is set at every tick system and > it is unset 500us (for a tick of 1ms) later. > During this time, The Decrementer ISR is executed (100 us) then interrupt_end(). > It seems most of the time is spent in cyg_scheduler::unlock(). > We don't understand what does ecos during these 400us (500-100). It does all the interesting things.... If the unlock causes the schedular lock to become 0 unlock_inner() is called. When this is called it means the schedular is in a consistent state and can do some real work. If there are any pending DSR they are called. So for the timer ISR the timer DSR will be called. These DSRs may result in a higher priority thread becoming runnable, or the current thread might no longer be runnable. So after the DSRs are run it then decides if another thread should be run. If so it will setup the context to be restored so that the new thread is restored, not the one that was interrupted. Any ASRs which are queued may also be called. Plus there is various checking done if you have it enabled. Things like stack checking etc. The code is quite well commented, so just read it to find out what is going on. 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