>>>>> "Gary" == Gary Thomas <[EMAIL PROTECTED]> writes:
Gary> There is no way to do reliable sub-tick timing if interrupts
Gary> are enabled. If you need such things, then you need to have
Gary> the interrupts off and if the I2C routines work this way
Gary> (I've not followed that development closely), then I think
Gary> *they* should be rethought.
I2C bit-banging typically operates at 100KHz so you need delays of the
order of a few us. Obviously cyg_thread_delay() is not going to hack
it. However the delays do not have to be exactly a few us. The I2C
specification allows for a lot of variability so if a signal sticks
for a while because the bit-banging code got interrupted or preempted
then nothing nasty is going to happen - the attached I2C devices will
just wait around.
If we ever come across h/w which is timing sensitive then some
interrupt disabling could be added to the bitbanging code, under
configury control. Even then I am not entirely sure whether it would
be better to do the interrupt disabling in the bitbanging code or at
the application level. Alternatively it would probably be easier to
avoid the problem at the application level simply by ensuring the
bitbanging thread runs at a sufficiently high priority.
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
