This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: newbie question regarding i2c device drivers


>>>>> "Steve" == Steve Simpson <s.simpson@genesysdesign.com.au> writes:

    Steve> The LPC2124 provides integrated I2C support. The data sheet
    Steve> for the LPC2124 states that if (a) the generation of a
    Steve> start condition is requested by software and (b) an
    Steve> external device is acting as bus master that the integrated
    Steve> I2C handler will wait (indefinitely) for an oppotunity to
    Steve> generate a start condition AND not generate an interrupt in
    Steve> the interim.

    Steve> Now I may have got this the wrong way, but with structure
    Steve> of the I2C drivers that I've seen couldn't this result in
    Steve> the I2C client thread being suspended indefinitely. I'm
    Steve> concerned that some physical condition on the bus may
    Steve> prevent the generation of an I2C interrupt. This would
    Steve> prevent the release of the client thread, would it not??
    Steve> WOuld it be appropriate to introduce a watchdog timer for
    Steve> the interrupt handler to safeguard against such conditions?

I think this depends on your exact hardware. If the I2C bus is limited
to the main circuit board then there should be no possibility of an
errant physical condition on the bus. Should a failure occur then you
are trying to run the application on broken hardware, and all bets are
off. You get to decide how much effort to expend on trying to cope
cleanly with this, as opposed to just letting the system crash or
hang.

On the other hand, if the I2C bus is accessible on an expansion
connector and it is legitimate to plug in extra devices then there is
a real possibility of a non-fatal failure condition. The appropriate
way to recover from this will again depend on the application. It may
involve a separate thread monitoring I2C operations, detecting
a lock-up, and warning the user by means of a flashing LED or some
message on a display. Or it may involve code in the driver to detect a
timeout and pass a failure back up to higher level code where
hopefully something will detect the failure and act appropriately. The
latter assumes that there is a way to tell the I2C hardware to abort
the pending operation, and any such abort code is likely to involve
some nasty race conditions.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]