ESP8266 Community Forum

- Mon Mar 20, 2017 11:30 pm #64033 FWIW, I've tried disabling WiFi and while it may of made a difference, it was small and doesn't solve the problem.

Anyone know if interrupts are better handled in the native SDK vs. Arduino? If I rewrote my code to use the SDK would it be more efficient/better?

- Tue Mar 21, 2017 7:48 am #64046

My understanding is that the ESP8266 will queue the ISR's up, and then execute them in some order. I can imagine that the queue is only so big though.

My understanding of interrupt queue is that it will hold the fact that one occurrence happened. If two happened in the same time then the answer is still one. Each source will have it's own interrupt flag but only one. And queue is the wrong term. Interrupts are not stacked based on time. Only on priority. And that is often fixed in hardware.

The ESP8266 doesn't seem like it is appropriate for doing what you need. I think you should have hardware that is more appropriate for the task. Use the ESP for communications.

- Tue Mar 21, 2017 6:15 pm #64069 Hi, the problem with the ESP for this application is that even with WiFi disabled it will still nip off and do stuff. If the adjustments you make to the shafts are manual, you could consider adding steppers to the shafts and driving them through buttons attached to the ESP. This way any 'breaks' the ESP takes from its program/sketch would be reflected in the movement of the steppers. If the movement is controlled by third party device it's going to be abit more tricky.

- Fri Mar 24, 2017 2:59 pm #64188

So I can't loose interrupts. I need perfect accuracy or there's really no point. It needs to be on CHANGE unless I were to do something strange and connect each encoder channel to two ESP pins and distribute the interrupts across 8 pins instead of 4 (each pin waits on Rising or Falling).

Sorry, but you are wrong here. If you need an interrupt on both edges (falling and rising) you do not need TWO inputs to realize this. You just reconfigure (reattach in this case) the interrupt in the ISR to wait an opposite edge when you detect one.

I still do not get why you need two interrupts per encoder. There are several encoder types, but let's say simple general encoder has two channels A and B and the edges on these channels allow to determine rotation direction. Clockwise - A channel leads and B channel follows; anticlockwise - B channel leads and A channel follows. Suppose A channel is on interrupt; when it fires, you read B channel and have full info about the situation - if B is low, it is rotated clockwise and vise versa.

This chis does not supports interrupt priorities so if several events occur at the same time - of course some could be lost. There is only one flag (in the dedicated register) for every interrupt, so you can serve the last interrupt on the particular pin, despite the fact that several events occurred during your busy (e.g. serving other interrupt) time.

I would suggest to keep this cpu for communications only and for your main program go for arm - e.g. stm32F4xx family. These chips are superior in every way.