Any examples of more general i2c messaging?

[turboscrew]

I've been trying to find examples of HAL-based i2c messaging, such as writing changing to reading without restart condition, and request-response messaging (= start, arbitrary number of bytes written, restart, arbitrary number of bytes received, stop).

Has anyone come across such?

Also, is it possible to easily switch off the i2c such that it doesn't act as slave after stop? Infineon's TLE493D shares interrupts with i2c clock pin and I haven't figured out how to handle that. It also uses "2-byte read", which is bus address, register address and receiving data, and the chip doesn't support restarts at all.

From the reference manual (F429) I got the impression that the direction (read or write) can be changed only by generating a start condition, in which case the last bit of the next byte (device address) defines it? It also looks like switching between clock and interrupt can be only done by disabling i2c and changing the GPIO-pin alternate function?

[S.Ma]

SW I2C can do this with a single function, passing a structure.

When there will be offered possibility to easily share application code snippets, such code will be shared.

[turboscrew]

You mean bit banging?

I guess arbitrary write-read could be built using sequentials, but I'm not so sure about the rest - whether the i2c HW is capable...

[Pavel A.]

> I've been trying to find examples of HAL-based i2c messaging, such as writing changing to reading without restart condition, and

Without "restart condition" - not so common.

> request-response messaging (= start, arbitrary number of bytes written, restart, arbitrary number of bytes received, stop).

Yes, this is known as "repeated start". Very commonly used. This is how commands with parameters are implemented in protocols above i2c (smbus, pmbus).

Better to stick to the common way, unless deliberately looking for fun.

>  Infineon's TLE493D shares interrupts with i2c clock pin

In-band interrupts are supported in the new I3C spec. Various vendors do whatever they do with the i2c technology.

-- pa

[turboscrew]

Basically HAL_I2C_Mem_Read() is a request-response mechanism, but with restart (repeated start) condition and writing limited to 3 bytes: device ID and 16-bit memory address.

About the in-band interrupts: I wonder how exti fits in the picture of GPIOs? They are not alternate functions, but seem to be independent parallel functionality?

I'm thinking of quick way to "pause" (enable/disable) the exti interrupts...

[S.Ma]

EXTI can be used on any GPIO, it's an independent feature if you read a reference manual.

This flexibiity was hidden by the HAL's #define and MX pin config.

So yes, you can try to use it. Just make sure for your overall interrupts their max latency and durations/priorities not to bump with overnight glitches.

(this is where there is little help from any provided source/tool)

[turboscrew]

That's the catch: It looks like routing the input somewhere else but the I2C receiver gets hard. With GPIO and EXTI the I2C still hangs on the line - and gets to see the interrupts. I read that even disabling I2C (PE in I2C_CR1) doesn't make it blind to glitches (interrupts) on the clock line. The I2C still gets to busy state and waits for stop condition to get out of it. And if you need to send something through the I2C to stop those glitches...

Even reset (SWRST in I2C_CR1) doesn't help.

 The funny thing is that the problem only exists with cold start. If I start with debugger, it doesn't happen, and if I then disconnect the debugger and do a warm start, it doesn't happen (the setting is already there to stop interrupts). I just don't understand the difference between cold start "as-is" and cold start using the debugger (uploading + run).