Problems with Linux/SX28AC i2c interfacing

hopefully-a-name-noone-else-has-registered

This message has been cross posted in Linuxquestions and the SX discussion groups.

I’m having a problem with the standard i2c software for the SX28 microprocessor when interfacing to Linux.

My PC is running Linux & I’m using the parallel port via a Philips design i2c interface based around the 74LS05 and some 10k pull-up resistors to provide the i2c interface, and on the other end of the i2c bus I have an Ubicom SX28AC microprocessor running the standard i2c software – of which there appears to be several versions. The version I’m running is the version that runs in the ISR, and in my particular case that is every 6uS.

It all works fine when there isn’t much activity on the i2c bus, but if I start hammering the bus with a lot of read/writes, then Linux starts complaining with (typically).

Nov 23 19:22:20 rhobert user.err kernel: i2c-algo-bit.o: Philips Parallel port adapter sendbytes: error - bailout.
Nov 23 19:22:21 rhobert user.err kernel: i2c-algo-bit.o: Philips Parallel port adapter sendbytes: error - bailout.
Nov 23 19:22:22 rhobert user.err kernel: i2c-algo-bit.o: Philips Parallel port adapter sendbytes: error - bailout.
Nov 23 19:22:22 rhobert user.err kernel: i2c-algo-bit.o: Philips Parallel port adapter sendbytes: error - bailout.

This particular error in the Linux kernel is associated with “arbitration or no acknowledge” on the bus. I have tried enabling more error diagnostics in Linux, but that has the effect of slowing down the bus and then the errors disappear. I don't think it's a timing problem with the SX28 interrupt service, because a thousand read/writes only generates 4 errors, and I'd expect more if the service routine was too slow.

Now, I know I can program around this in C on Linux by testing the read/write error returns and re-issuing the request if it fails, but why is it happening ? has anyone else experienced this ?

John Thompson

What about making the interrupt run faster, say every 3us or possibly even faster.
I know that I2C can run up to 400kHz clock speed (period 2.5us).

Dont know what else is timed from this interrupt so you might have to be careful!

Or slow it down at the PC side.

Sounds like a speed problem to me.

hopefully-a-name-noone-else-has-registered

Hmmm, I agree, my gut feeling is that it is a speed issue with the ISR, but I don't understand why it doesn't happen all the time - only when the i2c bus is being stressed.

Bean

Depending on what value of resistor you are using for the pull-ups, you might want to try a slightly lower value. This will lower the rise-time of the signals. I don't know if that is what the problem is or not, but you can try it.
Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95

http://www.parallax.com/detail.asp?product_id=30012

"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015

Product web site: www.sxvm.com

Those that would give up freedom for security will have neither.
·

hopefully-a-name-noone-else-has-registered

I tried reducing the pull-up resistors but unfortunately, I then start loosing data on the bus. I've also tried running the ISR faster (3uS to double the speed) and that made no difference either.
Still scratching my headon this one.

Thanks for the suggestions though.