Re: [ECOS] Mutex & Asserts during initialisation

[Will Wagner <will_wagner@carallon.com>]

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