henryyao

Ya, I'm using 4.2. Now i'm looking for a better solution rather than multi- thread. I've been searching for a week but cannot find one..

i am not sure about 4.3, but in 4.2 its blocking - means nothing happens till a connection is etablished.

 

you may want to put it in a thread so your programm keeps running, same for receiving data

Maybe you could use an event wait handle to do the same thing as Thread.Join(), something like this:

    public class Connector	{		private IPEndPoint _remoteEndPoint;		private AutoResetEvent _waitForConnection;		Socket _socket;		public Socket ConnectTo(byte[] ipAddress, int port)		{			_remoteEndPoint = new IPEndPoint(new IPAddress(ipAddress), port);			_socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);			while (true)			{				_waitForConnection = new AutoResetEvent(false);				var connectorThread = new Thread(WaitForConnection);				connectorThread.Start();				if (!_waitForConnection.WaitOne(2000, false))				{					connectorThread.Abort();					_socket = null;				}				return _socket;			}		}		public void WaitForConnection()		{			_socket.Connect(_remoteEndPoint);			_waitForConnection.Set();		}	}

 

What makes Thread.Abort() dangerous is that you don't get the chance to clean up anything you've done inside the Thread.  Threads are usually used for long-running operations and so normally you need to clean up any resources you've allocated.  But that's not the case here - you're using a thread simply as a timeout mechanism.  If you make sure to keep the thread code as simple as possible, and you never need to clean up anything, then you should be fine. 

 

Worst case scenario here is that a connection is established between _waitForConnection.WaitOne() and _waitForConnection.Set(), so we have a connected socket that we think is unconnected.  But the socket will be disposed of anyway, so I don't think that will cause problems.

I see what you mean. Thanks for the explanation on abort().

And is there a difference between join() and autoresetevent in this situation?

Thanks everyone, I have ordered the new TPA sensor and it turns out the problem was with the old sensor.

Waste a lot of time on this...

What does "it does not work either" mean exactly? You should not get the argument exception with 0x68 slave address.


Well, unless you have the source code, you will not be able to step into .NET MF classes - just use 'step over'.

Also, although the documentation does not contain detailed description of the communication protocol, the linked tutorial mentions that repeated start condition is needed when reading from or writing to the slave device; you'd need special I2C methods to achieve that.

Hi CW2,

I did get some result from 0x68 address, however the results are strange.

I did not use the special I2C method you provided, instead, i changed my code to the following, so I think a startup sequence is triggered at each dev.Execute.

However, the results are still the same strange ones. Now the thing is, do I really have to use the special I2C method or its the problem with my sensor.

            I2CDevice.I2CTransaction[] action1 = new I2CDevice.I2CTransaction[] { write };            I2CDevice.I2CTransaction[] action2 = new I2CDevice.I2CTransaction[] { read };                     dev.Execute(action1, 1000);            dev.Execute(action2, 1000); 

Hi Henry, Are you sure that the address is 0xD0 and not 0x50? I2C addresses are generally 7-bit (with the top bit reserved for the write/read indicator). Chris

Thanks for that. The address is 0x68 in fact. It's a half of 0xD0. I'm corrected this and I keep getting strange data. It is not what its supposed to be. I guess the problem may be my TPA sensor.