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

wang cui iucgnaw@msn.com
Thu Nov 16 02:49:00 GMT 2006

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))) {
<             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
>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?
>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

More information about the Ecos-discuss mailing list