ESP8266 Community Forum

- Wed May 20, 2020 9:35 am #87215 I have the following librarys included
#include <ESP8266WebServer.h>
#include <WebSocketsServer.h>
#include <DNSServer.h>
#include "MSP.h"


I have the following ISR conected to Timer0

void inline ppmISR(void){
static boolean state = true;
if (state) { //start pulse
digitalWrite(sigPin, onState);
next = next + 24000;
state = false;
alivecount++;
}
else{ //end pulse and calculate when to start the next pulse
static byte cur_chan_numb;
digitalWrite(sigPin, !onState);
state = true;
if(cur_chan_numb >= CHANNEL_NUMBER){
cur_chan_numb = 0;
next = next + 840000 ;
digitalWrite(DEBUGPIN, !digitalRead(DEBUGPIN));
tick ++ ;
}
else{
next = next + cppm[cur_chan_numb] ;
cur_chan_numb++;
}
}
timer0_write(next);
}

This is a cut down version of one I found in an instructible.
I am using a websocket on a peer to peer network to form a HID.


Now the Problem is that I am seeing advice that says not to use timer 0
"Other processes use the same timer and it has been reported that a 2 ms tick will crash the ESP8266 if you are using WiFi."

Well it does not crash in my case, and my shortest interrupt is 300us (the sync pulse on my cppm.)
but I am seeing noise on the pulse train as the server serves html.
can anyone clarify this?

- Fri Sep 25, 2020 7:28 pm #88898 WiFi is a higher priority than most other interrupts, so it may cause jitter in your timer depending on where the WiFi hits. If you have a high traffic environment or large packets then it's plausible that it'll be processing WiFi when the timer overflows, and the interrupt for Timer 0 won't get serviced until WiFi is finished. If your packets are large, that could be quite some time.

Additionally, the SDK switches speed when it processes WiFi (don't remember whether it shifts down to 80 or up to 160, but I've seen it mess up the periods from the ets_timers. Try flipping the CPU speed in your compile and see if that makes the 'noise' better or worse.