RE: [ECOS] Re: CYG_ASSERTCLASS() fail when use wallclock->dallas->ds1307 device driver

["wang cui" <iucgnaw at msn dot com>]

Thanks.
I solved this issue in another way.
As it fails when call 
cyg_drv_mutex_lock()/cyg_drv_mutex_trylock()/cyg_drv_mutex_unlock() in 
i2c.cxx, I add a cyg_thread_self() call before these calls, to check 
whether the I2C APIs are called in a thread context. Something like:

<     if (cyg_thread_self() != 0) {
<         while (! cyg_drv_mutex_lock(&(bus->i2c_lock)));
<     }
<     ...

<     if (cyg_thread_self() != 0) {
<         if (cyg_drv_mutex_trylock(&(bus->i2c_lock))) {
< #ifdef CYGDBG_USE_ASSERTS
<             bus->i2c_current_device = dev;
< #endif
<             result = true;
<         }
<     } else {
<     ...

<     if (cyg_thread_self() != 0) {
<         cyg_drv_mutex_unlock(&(bus->i2c_lock));
<     }
<     ...

Maybe more ugly, but it can be used in both STARTUP and SCHEDULER stage.

Still waiting for eCOS maintainers fix it officially, and update into CVS.

> This is the same problem discussed last year in the thread
> http://sourceware.org/ml/ecos-discuss/2005-07/msg00083.html.
>
> It appears that this problem has not been resolved, because I am also
> seeing the same assertion failure for a I2C based wallclock driver that
> I am writing for the Epson Rx-8025.
>
> It seems to me that the easiest fix would be to swap the priorities of
> CYG_INIT_CLOCK and CYG_INIT_IDLE_THREAD in cyg_type.h.  Is there any
> other reason than inertia that this fix has not been implemented?  If
> not, could one of the maintainers add this fix?
>
> Thanks
> Michael Checky

_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger:  http://messenger.msn.com/cn  


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss