This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Mutex & Asserts during initialisation
- From: Will Wagner <will_wagner at carallon dot com>
- To: Andrew Lunn <andrew at lunn dot ch>
- Cc: eCos Discussion <ecos-discuss at ecos dot sourceware dot org>
- Date: Fri, 08 Jul 2005 15:21:12 +0100
- Subject: Re: [ECOS] Mutex & Asserts during initialisation
- References: <42CE6EEB.1070309@carallon.com> <20050708140827.GA2640@lunn.ch>
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