From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15310 invoked by alias); 21 Nov 2003 17:28:31 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 15303 invoked from network); 21 Nov 2003 17:28:30 -0000 Received: from unknown (HELO hermes.chez-thomas.org) (63.225.98.241) by sources.redhat.com with SMTP; 21 Nov 2003 17:28:30 -0000 Received: by hermes.chez-thomas.org (Postfix, from userid 2000) id 6968D50D8A9; Fri, 21 Nov 2003 10:28:30 -0700 (MST) Received: from localhost (localhost.localdomain [127.0.0.1]) by hermes.chez-thomas.org (Postfix) with ESMTP id E380250D88A; Fri, 21 Nov 2003 10:28:28 -0700 (MST) From: Gary Thomas To: Aaron Case Cc: Ecos-Discuss In-Reply-To: <1069435326.1961.724.camel@hermes> References: <1069435326.1961.724.camel@hermes> Content-Type: text/plain Organization: MLB Associates Message-Id: <1069435708.1961.726.camel@hermes> Mime-Version: 1.0 Date: Fri, 21 Nov 2003 17:28:00 -0000 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: RE: [ECOS] context for creating interrupts on edb7312 X-SW-Source: 2003-11/txt/msg00304.txt.bz2 On Fri, 2003-11-21 at 10:22, Gary Thomas wrote: > On Fri, 2003-11-21 at 09:32, Aaron Case wrote: > > > > > > > > Im looking for something along the lines of #define > > > hal_interrupts_enable > > > > cyg_interrupt_enable(). > > > > > > Actually, there is no explicit call like this (anymore). Interrupts > > > will get enabled when the scheduler "starts" the first thread (minimally > > > the 'idle' thread). Thread contexts are initialized with interrupts > > > enabled and this just sort of falls out with the washing :-) > > > > > > -- > > > Gary Thomas > > > MLB Associates > > > > > > > > > > Gary, > > > > Thanks for the prompt answer. I was speaking more in the context of linking > > and compiling the image. > > > > I see that a call to enable interrupts is not necessary when threads are > > initialized. > > > > I also see the cyg_interrupt_enable in the map file, which jumps to the > > hal_interrupts_enable( from vector.S but not in the map file) code in the > > application. > > I'm not sure I understand what you mean by this (in the map file?), but > if a function isn't used (cyg_interrupt_enable() is not used by the > kernel except for a single test), then even if that function is defined > it doesn't end up in the resulting application. > > IMO there is absolutely no need to ever call cyg_interrupt_enable(), > except for the kernel test which tests it. > > If you need to manipulate the interrupt state (and there are very few > cases even for this), this is a better approach: > > cyg_uint32 state; > HAL_DISABLE_INTERRUPTS(state); // Disables interrupts > ... > HAL_RESTORE_INTERRUPTS(state); // Restore interrupts Or, even better when writing device drivers: cyg_drv_isr_lock(); ... cyg_drv_isr_unlock(); -- Gary Thomas MLB Associates -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss