ESP8266 Community Forum

- Sat Oct 07, 2017 5:27 pm #70694 I had found that and came up with, too little hardware support. Like the I2C support being done in software rather than hardware. The ESP8266 just doesn't have a lot of hardware for efficient interrupt handling, given all the tasks it has to do.

- Sat Oct 07, 2017 5:45 pm #70695 In general, hi end processors, although having high speed clock capability, they are not optimized for fast handling the I/Os, since the pipeline of the fetched instructions implies on a latency to execute each command, depending on how it were implemented in firmware and optimized by compiler. In addition, even having for example 80MHz clock, it is not the same for all the the CPU, there is one clock for the core and another for peripherals. In general, fast response to these architectures is achieved through hardware resources such as specific peripherals. Note that the I/O mapping for this uC is very strange, it is not a simple bit-oriented access, but it has to mask and shift a lot of stuffs. There are people complaining the same issue with Cortex cores, achieving ridiculous speed for a blinking led application, but there is no way, for faster response, smaller arquictetures...

"part of the world that you live in, you are the part that you're giving" - Renaissance

- Sat Oct 07, 2017 11:25 pm #70704 I would suggest as schufti says to put the ISR in ram, otherwise it will have to load that function from flash at the moment the interrupt triggers. You should ALWAYS do this with pin change ISRs actually, because they can fire in the middle of reading from the flash for other tasks, which will corrupt the flash state machine and cause the chip to crash.

Change your ISR definitions to:

Code: Select allvoid ICACHE_RAM_ATTR chgSCL() {

- Sun Oct 08, 2017 2:12 am #70705

Change your ISR definitions to:

Code: Select allvoid ICACHE_RAM_ATTR chgSCL() {

I forgot to mention that, but I already did, together with shutting down wifi. Didn't help.