kanflo/esp-open-rtos-driver-i2c

I2C driver for esp-open-rtos

esp-open-rtos-driver-i2c's Issues

Documentation: "Add to your project"

Hi Johan,

I had problems, when I was following your approach regarding the usage as a git submodule

% git submodule add https://github.com/kanflo/esp-open-rtos-driver-i2c.git
% mv esp-open-rtos-driver-i2c i2c

My proposal would be to use the following in the documentation

% git submodule add https://github.com/kanflo/esp-open-rtos-driver-i2c.git i2c

So git is able to follow the changed repository name.

Thanks for the great work

Angus71

[Enhancement] -- Provide "bus reset" functionality

Regrettably, I2C devices can hang the bus.

At least as I understand it, the master can "force a reset" by clocking at least 9 times.

I first found out about this "35 year old 'well known secret'" at https://community.nxp.com/thread/316813 (TomE post on Feb 28, 2017):

http://www.nxp.com/documents/user_manual/UM10204.pdf

If you read section "3.1.16 Bus Clear" it tells you to assert the "Reset Pins" of all the I2C devices. The whole point of I2C is to minimise the number of bus pins, so almost no devices have Reset pins. But then it gives the advice that "everybody knows", which is:

If the data line (SDA) is stuck LOW, the master should send nine clock pulses. The device that held the bus LOW should release it sometime within those nine clocks.

Another reference that seems clear and reputable is http://www.analog.com/media/en/technical-documentation/application-notes/54305147357414AN686_0.pdf

The method is quite simple. It is the master’s job to recover
the bus and restore control to the main program. When
the master detects the SDA line stuck in the low state, it
merely needs to send some additional clocks and generate
a STOP condition. How many clocks will be needed?
The number will vary with the number of bits that remain
to be sent by the slave. The maximum would be 9. This
number is derived from the worst-case scenario, the case
where the processor was reset just after sending an ACK
to the slave. Now the slave is ready to send 8 data bits and
receive 1 ACK (or NAK in the case of a bus recovery).

The procedure is as follows:

1. Master tries to assert a Logic 1 on the SDA line
2. Master still sees a Logic 0 and then generates a clock
   pulse on SCL (1-0-1 transition)
3. Master examines SDA. If SDA = 0, go to Step 2; if
   SDA = 1, go to Step 4
4. Generate a STOP condition

At least for me, I'm not sure that the complication of checking to see if SDA has gone high is "required" to save a couple of ~100 kHz clock cycles. I certainly don't expect the code to determine if the bus is hung! I'd be happy with i2c_bus_reset() or the like.

I2c_slave_read question

Hi, i'm Andrea,
I'm using this library with SuperHouse rtos sdk to start a comunication between esp8266 and atmega328 with Arduino.
Wire lib of Arduino have the 'onReceive' and 'onRequest' function.
With other fw in ESP I was able to create a multitasking comunication where , first I send a command from esp ( master ) to atmega(slave) writing a byte and saving ir in a buffer slave-side with onReceive function. After this I start read request, given me from the onRequest function in atmega slave, decided from the command given from the master.
I notice that the slave_read function don't leave me di the same, and I can't use all two function in atmega.
Seems the slave_read is before write and then read , so if I use the onRequest will never call because it's always a onReceive.
Maybe I'm wrong, now I'm working on it and I'm trying to solve.
Maybe I'm using it in a wrong way.
Could you give me some hint?
Thanks

Not working when using gpios unequal to GPIO0/GPIO2?

Hi Johan,

I used your I2C driver with a ESP-12 module (nodemcu V2) and no communication was possible to the I2C slave, when using GPIO14 as SCL_PIN. I checked for "pull-up" resistors on GPIO14, but even with a "pull-up" it was not working.

Previously I used a rewritten version of the diver from zarya [1] to work with esp-open-rtos and the GPIO14 was usable right out of the box.

Are you able to reproduce this?

Thanks for the good work

Angus71

[1] https://github.com/zarya/esp8266_i2c_driver