- Sun Oct 08, 2017 4:44 pm
#70725
Aha I see. Sounds like the interrupt handling is just not fast enough for 400khz. It may be moot for your project but I think your code and scope trace may be making the problem look worse than it actually is since the ISR is copying the input pin state rather than just doing an inverse. If the latency is near one clock cycle, it will look sorta random like this.
Moderator: igrr
- Sun Oct 08, 2017 8:42 pm
#70731
The real problem is not being able to capture the start of the transmission. Once that was determined the code can then just watch the port pins in a regular loop. There is no reason to use interrupts for watching the data transmission. The problem is that you don't want to only watch for I2C activity when it isn't happening. We also want/need to do other tasks.
The most logical solution is to use a more capable framework. A second processor that would just be dealing with watching/decoding I2C, and the ESP that handles the resultant data and sends it to where it needs to go. In theory the ESP32 should be able to do this. It has one dedicated processor for WiFi and the other to do dedicated work without without the WiFi overhead. At this time I would go for a dual processor approach rather than the ESP32. Because I personally don't have any real experience with the ESP32 yet. Only tried a few examples.
The most logical solution is to use a more capable framework. A second processor that would just be dealing with watching/decoding I2C, and the ESP that handles the resultant data and sends it to where it needs to go. In theory the ESP32 should be able to do this. It has one dedicated processor for WiFi and the other to do dedicated work without without the WiFi overhead. At this time I would go for a dual processor approach rather than the ESP32. Because I personally don't have any real experience with the ESP32 yet. Only tried a few examples.
