From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30449 invoked by alias); 8 Jul 2005 14:18:21 -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 30233 invoked by uid 22791); 8 Jul 2005 14:17:53 -0000 Received: from carallon.force9.co.uk (HELO carallon.f9.co.uk) (80.229.37.120) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 08 Jul 2005 14:17:53 +0000 Received: from [192.168.42.8] by carallon.com (MDaemon.PRO.v8.0.2.R) with ESMTP id md50000011944.msg for ; Fri, 08 Jul 2005 15:21:14 +0100 Message-ID: <42CE8BD8.2080404@carallon.com> Date: Fri, 08 Jul 2005 14:18:00 -0000 From: Will Wagner User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Andrew Lunn CC: eCos Discussion References: <42CE6EEB.1070309@carallon.com> <20050708140827.GA2640@lunn.ch> In-Reply-To: <20050708140827.GA2640@lunn.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: willw@carallon.com X-Spam-Processed: carallon.f9.co.uk, Fri, 08 Jul 2005 15:21:14 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.42.8 X-Return-Path: will_wagner@carallon.com X-MDaemon-Deliver-To: ecos-discuss@ecos.sourceware.org X-MDAV-Processed: carallon.f9.co.uk, Fri, 08 Jul 2005 15:21:16 +0100 Subject: Re: [ECOS] Mutex & Asserts during initialisation X-SW-Source: 2005-07/txt/msg00087.txt.bz2 Thanks Andrew. Will try that. The issue with SPI and i2c is that all the functions ensure only 1 thread can access the buses at once and hence the lock. Before the scheduler is started there is no possibility of another thread running and so no need to lock the mutex. However the generic functions don't test for this case. Will Andrew Lunn wrote: > On Fri, Jul 08, 2005 at 01:17:47PM +0100, Will Wagner wrote: > >>Hi All, >> >>I am trying to run with asserts on to test a couple of things. However >>there seems to be a problem with the mutex check_this function has been >>implemented. >> >>If anything tries to lock a mutex before the scheduler has been started >>then an assert goes off. This is because when locking the mutex >>Cyg_Thread::self() returns NULL. So in the check this function locked is >>true but owner is NULL so it fails. >> >>This means that you can't use SPI or i2c before the scheduler starts. If >>you have any driver that is initialised via static constructor that uses >>either of those then the system asserts. An example of this would be the >>DS1307 wallclock. >> >>How has anyone worked around this in the past? > > > Humm, i think this is reasonable behaviour. Anything that tries to use > a mutex must assume it can block. Otherwise why are you using a mutex! > > I think the solution for you is to also start the schedular in a > static constructor. Just give it a higher priority than anything that > needs the schedular enabled. > > 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