I2C Wire Library, handling Errors

Firmware
1

Hey Everyone,

I am doing some development with I2C devices connected to the Spark Core. Its going extremely well so far. I can send and receive with the unit and it works perfectly.

The last part really is handling errors on the I2C port. I want to make sure when a user tries to connect to an I2C device that the device is actually there, if not let them know. Here is what I do:

Wire.beginTransmission(21);
		byte status1 = Wire.endTransmission();
		if(status1 != 0){
			Wire.clearWriteError();
			Wire.flush();
			return;
		}

This returns an Error. However if I plug a device in that is listening at address 21 and try to run again it continues to return the error until I power cycle the Spark. It seems the Wire.clearWriteError() is not working. Can anyone confirm this or tell me if I am doing something wrong?

2

Hi @IOTrav

It looks like Wire.flush() is not implemented yet, so I think what is happening is that any new transmissions will error again.

I think you should file an issue on github for the team to look at this.

In the mean time, I think you can work around this by calling Wire.begin(); or Wire.begin(addr); in your cleanup code.

1 Like
3

Hi @bko

That works. I will just call Wire.begin() before each transmission. Seems to be working well. Just glad I wasn’t crazy and the clear error and flush really weren’t working. I suppose I could go in and fix that in firmware if I feel froggy later.

While I have you here though I have another quick question.

Most Stream objects like TCPClient for example have a read method which you can pass a byte array object and length to, to read bytes out of the stream. The Serial Library however does not seem to have that, it seems you have to pass a *char for some reason. Where would I go about implementing an override method there for readBytes that returns a byte array from the stream?

Thanks again @bko

4

Hi @IOTrav

TCP is a packet oriented transport so it is much more natural to think of doing operations on collections larger than one character, but UART serial is a character oriented transport so I am sure the original Arduino thinking on this was to provide only one character at a time on receive.

On Spark, the serial port data is buffered in circular buffers so you would have a chance to read multiple bytes from the stream but you would have to compile locally and make a few changes to the USART serial methods. I think it could be done by copying char’s out of the _rx_buffer.buffer into the byte array based in.