It sounds like, you have a misunderstanding about I2C:
What you try to do (based on your code):
a) master sends something and stops (e.g. with I2C SCL just for the CMD)
b) you expect that "master" gets something received (from a "slave" now starting to send)
I2C is always a "Master" and "Slave" relation:
Maybe you could, but you have to toggle the "master" (on both ends) to a "slave".
Usually, what happens is this:
You need a "master - slave" relation, a "protocol", sending as master still all the time SCL, just changing direction between a WRITE and READ phase. And often, a READ from a slave happens after a RESTART signal (not as a separate, new I2C transaction).
What you try to do (based on your code):
a) master sends something and stops (e.g. with I2C SCL just for the CMD)
b) you expect that "master" gets something received (from a "slave" now starting to send)
I2C is always a "Master" and "Slave" relation:
- master provides SCL and sends a command
- master keeps providing SCL, can change direction for a READ, so that slave uses the same SCL (provided) by master, to send the response as a slave
- a slave never acts like a master, e.g. starting now to provide SCL (than it would be a master and the original master has to change into a slave mode)
Maybe you could, but you have to toggle the "master" (on both ends) to a "slave".
Usually, what happens is this:
- A master sends a CMD, e.g. writing a register address where it wants to read from
- it keeps clocking, with a RESTART, so that the slave can respond with sending now the register value
You need a "master - slave" relation, a "protocol", sending as master still all the time SCL, just changing direction between a WRITE and READ phase. And often, a READ from a slave happens after a RESTART signal (not as a separate, new I2C transaction).
Statistics: Posted by tjaekel — Sun Sep 01, 2024 9:24 pm