[En-Nut-Discussion] TWI and Lua problem

[Bernd Walter]

On Sun, Apr 10, 2011 at 09:32:11AM +0200, Andre Riesberg wrote:
> Hello all,
> 
> I use NutOS 4.9.10 on a board like EIR with a SAM7S CPU. I use a big 
> display board with 72 LED using four LTC3220 LED driver and a PCA9546A 
> I2C multiplexer. Everything works fine when I access the devices from c 
> code. If I try to access the device from a Lua script (I had written a 
> Lua function wrapper for TwMasterTransact) I run into problems. After 
> some bytes (5 to 15) I see a too short clock pulse. Normally the clock 
> pulse is 100µs long, both high and low part. The too short low pulse is 
> only 0.5µs long. This equivalent to a frequency of 1MHz and much too 
> fast for the I2C devices I use.
> If I call the Lua wrapper function directly from c, It works fine. It 
> fails only together with Lua.
> 
> I have higher the stack space of the Lua thread. Same result.
> I check heap memory with NUTMEM_GUARD and NUTDEVICE_HEAP, everything is ok.
> Nobody change the port pins (SDA, SCL).

This is not specificly about your short impulse, but there is an
annoying point about the TWI controller, which is worth mentioning.
You start a transfer with an internal addressing setup.
So in fact it does a start, addresses for writing writes a few bytes,
then depending on the intended data direction it does a restart for
reading or stays in writing.
This all happens without further software intervention.
Now for transfering data you need to read/write the data register.
DMA as in most other IO-controller is not available.
Normaly you would expect that if you don't read/write the register the
clock just stops to pause transmission and that's it, but that's not
true for that hardware.
What the TWI controller does is issuing a stop and when you finally
access the data register it issues a start again.
This should be true at least for all the single-master-only controllers
as in RM9200, most SAM7S, SAM7X.
The SAM7S16 and SAM7S161 at least have an updated TWI with master/slave
support - I don't know the details, since the controller wasn't
attractive for me.
Maybe if you are just slightly out of timing for register access you
get such a glitch...
You should try a slower clock speed for verification.
That said: I've never used the NutOS twi code, so maybe such conditions
are completely avoided by software design.

About the multiplexer in general - they have a very high resitive
on mode, which has a major influence if you have a high wire capacity.
I don't think this can explain your glitch, but might change the
symptoms of short glitches.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.