ESP8266 Community Forum

Are these tasks simultaneously possible with an ESP8266 alone?

1st task (phase angle control):

- Read pin change interrupt (120hz zero cross signal) and generate digital output exacly (+- 150us) 0ms-8.3ms later with 83us granularity

2nd task (read analog periodic signal):

- Read 10bit adc every 1ms (timer-based); times of readings may fluctuate +-250us but never more than 1ms

3rd task (graphical display):

- SPI with 4MHz-10MHz to send 128 bytes every 5ms over SPI to display

4th task (wifi):

- Send binary data to computer for visualization by app (128 bytes every 500ms) and, maybe, serve dynamic web pages

In theory, yes, I think, but in practise you need to be prepared to cope with quite a bit of jitter. Your code isn't the only code that needs to run to keep wlan running...

If jitter is a problem, I'd suggest to handle the timing critical tasks by a simple 8 bit microcontroller (ATmega or PIC) and have it send the results over UART to the esp8266.

eriksl wrote:Your code isn't the only code that needs to run to keep wlan running...

Thanks for your opinion. Is the wlan code interrupt-heavy and potentially blocking other interrupts for more than ca. 250us? I could put all of my jitter-critical code in interrupts (firing adc for analog signal sampling in a timer interrupt; waiting for zero-cross signal via a pin-change interrupt; starting phase-angle timer in that pin's interrupt handler).

While I have experience with AVR, I'd be tempted to investigate the EMW3165 if the ESP8266 doesn't work out for my scenario: safe one AVR, use the module's Cortex-M4 (execept that at this point, I have no idea how much of that is available for my code and how much it tied up by wifi, too).

mi_ka wrote:I could put all of my jitter-critical code in interrupts [...]

The problem is that the ESP8266 has non-maskable interrupts that (probably) can interrupt your interrupt handler. I have seen code purporting to temporarily disable non-maskable interrupts but I have no experience using it.

Another factor that contributes to jitter related to ISR-controlled actions is interrupt latency, i.e. the time between when the interrupt occurs and when your ISR gets control.