[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


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



More information about the Ecos-discuss mailing list