ULP-I2C

[barosu]

Hi!
I just started with the esp32. I wanted to use an extern 16-bit ADC with the ESP. And I also intended to read that ADC with the ULP. As the ULP supports I2C I thought it was no problem.
Now I studied the Technical Reference Manuell and read about the RTC_I2C Controller. Apparently the I2C interface of the ULP is very limited. With the given I2C instruction I can only read one byte from the ADC before sending the STOP conditions. The 16-bit ADC I saw so far, required to read both bytes without a stop condition in between. So it is somehow possible to send an ACK instead of a STOP after reading one byte with ULP to receive the second half of my 16-bit Value. Or does someone know an 16-bit ADC where I can address the data bytes individually?
Well I can still fallback on the internal ADC but any other suggestions are welcome.

Greetings barosu

[tomtor]

I2C protocol could be implemented in ULP assembly code.

I did this for the DHT-22 protocol, which is slightly less complex, but I think I2C is doable.

EDIT: I'll implement and test it for you with the BMP-180 sensor and ADS-1015 ADC

EDIT2: See

https://github.com/tomtor/ulp-i2c

@barosu This example reads the 16 bit raw temperature data from a BMP-180 sensor

[barosu]

Wow thank you very much. I allready had the idea that this must be possible somehow in a way like this. I didn't had time for a detailed look into it, but I'll play around with your code soon. I actually didn't expect a working code example and I really appreciate the extra effort. Well time to work on it myself, but I think your code has also given me a better understanding on how to use the ULP

[jas39_]

This is a cool example! I'm wondering if it's possible to extend it with a slave mode? Can the ULP processor receive an "interrupt on pin change" or is it polling only? When I did this last time on another processor I used interrupts to detect start/stop and bitshifts.

If interrupts can't be used it would probably limit the max SCL frequency to be used since you have to continuously "bitbang read" the SDA/SCL status