esp32 i2c is not implemented yet

[mnfisher]

Just spent some time trying to get i2c working on an esp32. No joy at all.

Taking a peek at the source C:\ProgramData\MatrixTSL\FlowcodeV9\CAL\ESP\ESP_CAL_I2C.c and I see that hardware mode isn't actually implemented yet:

For example showing a short function - but the pattern repeats:

Code: Select all

CALFUNCTION(void, FC_CAL_I2C_Master_Init_, (void))
{

	#if (MX_I2C_CHANNEL_X == 0)															//Use Master I2C Software
		GET_PORT_PIN(MX_I2C_SDA_PORT_X, MX_I2C_SDA_PIN_X);								//Configure SDA as Input
		GET_PORT_PIN(MX_I2C_SCL_PORT_X, MX_I2C_SCL_PIN_X);								//Configure SCL as Input
	#endif

	#if (MX_I2C_CHANNEL_X == 1)													//Use Master I2C Hardware 1

	#endif
}

if MX_I2C_CHANNEL = 1 (channel 1) then nothing happens.... (Which would also apply to channel 2)

I'm not sure if this counts as a bug, but a compiler warning to the effect that hardware channels are not implemented would be good. (I'm guessing this is a knock-on from ARM i2c not working in hardware mode too?)

Transaction mode looks to be implemented (again as per ARM) - but I couldn't get this to work either - either in software or hardware mode <code>Transaction_Initialise(100)
Transaction_Write(.buf, 10)
Transaction_Uninit
</code>
sent 100 (only) - is this the correct way to use this?

Software mode (Start, TxByte etc) seems to work perfectly however!

Martin

[LeighM]

Hi Martin,
Yes, you are correct, the ESP I2C hardware only works with transactions, as ARM
You only need to do the uninit if you want to later address a different device with the same component
The address passed in the init should be the 7 bit device address, not the bit shifted (for r/w flag) value
Hope that helps

[mnfisher]

Thanks Leigh,

Transaction_Write only seems to send the address - I tried with and (originally) without the Uninit call afterwards.
I viewed the output on the oscilloscope - rather than sending to a particular device - so maybe it was missing an ACK - I'll try connecting to a 'real' i2c device and try that....

Code: Select all

		if ( CALFUNCTION( , FC_CAL_I2C_Master_TxByte_, (MX_I2C_ADDRESS_X<<1)))     //  Receiving NACK here so return 0?
			return 0;
		while (n < Length)
		{
			if ( CALFUNCTION( , FC_CAL_I2C_Master_TxByte_, (Buffer[n])))
				break;
			++n;
		}

I still can't get the built in OLED display to work (on A15 and A4)

Martin

[LeighM]

Yes, it would need the ack before it proceeds.
Which is why I thought you might have the wrong address.

[LeighM]

I still can't get the built in OLED display to work (on A15 and A4)

What's your target device/module?

[p.erasmus]

Guys

just a question,are these changes/things some where written/documented that we can pick these things up because it is now clear from the above that an I2C component created on PIC or and Atmega (UNO) will never work on a ARM(STM) or ESP .

[LeighM]

.. and Raspberry Pi
Although software mode does work (OK, not ideal
Yes, sorry, you could be correct, I'm not sure what info we do have on this.
We have gone through all the I2C based components in our Component Libraries and converted these to use the transaction mode API.
This is backwards compatible with target devices (PIC etc) that do not actually use transactions.

[p.erasmus]

Leigh,

Thanks the question is now how do I handle this because I made a component which work perfectly on PIC and UNO then try ESP no go
can you give some pointers please these are the tricky things that is not so clear in component creation

[LeighM]

You first need to do the Transaction Init passing the device address.
Then you can either write a number of data bytes to the device or read a number of bytes from the device.
The data is transferred from/to a byte buffer.
So for example a small serial eeprom might need the transaction write of a single memory address byte, followed by a single (or multiple) data byte transaction read.

[mnfisher]

It's possibly a foolish idea, but could the cal i2c 'fudge' the txByte etc (as a temporary fix) using the transaction routines - I can see that transmit would be fairly straightforward - start would clear a buffer - TxByte would add to the buffer and then 'stop' send it (using the first byte as address) using the transaction send.
Read seems harder but similar Start clears buffer, tx of byte with read bit set starts recording how many byte are to be read (each ca!l to read) before stop does a transaction read?

There might be issues with maximum buffer size and with ack/nack handling? It's still going to need some code modifications to 'get' the data - since the program will expect read to return it. So it might have to call transaction read for every byte.

It might be easier to just implement TxByte etc?

Martin