Make waveform generator a NMI to run always, increase accuracy

[earlephilhower]

Make the waveform generator an NMI using the same code as in 2.4.0.
Making it NMI will ensure it runs even when interrupts are disabled.

Fixes #5568

[earlephilhower]

Ran the SpeedTest.ino on SPIFFS in PR #5511 with a 1KHz PWM output on a single pin and it's looking good.

Attempted the WiFi Server test at https://gist.github.com/arunoda/3f17eba4f3f1fd5e1a7adc86e7b62ca7 with a 1KHz output on a single pin as well, TCP v2 hi BW, 160MHz, and got about 670KByte/sec (5.3Mbit/sec) downloads from the 8266. W/o PWM I get ~700KByte/sec, so this ~5% lower perf with PWM

At 10KHz I can get occasional SPIFFS WDT timeouts when writing 512KByte at a time in 256byte chunks (but adding in yields() every 32KB fixes this while reducing write BW by under 10%, so it's not really a showstopper), but WiFi works fine and delivers ~620KBytes/sec (4.96Kbit/sec) doe to increased CPU usage by the PWM generator.

Simple and stupid downloads to the ESP8266 from a local server on my LAN of a 10M file take 51s using simple client code and no PWM and 57s with the same 10khz PWM (so again ~10% lower). No WDT or anything seen with this. Code below, but this is not meant to be a good example snippet, only a straightforward one. :)

  WiFiClient client;
  client.connect("192.168.1.8", 80);
  client.write("GET /zero\r\n\r\n");
  uint32_t start, end;
  Serial.printf("%d start\n", start =millis());
      while(client.status()) {
       const int bufSize = 1460;
       // Initialize a random set of bytes
       byte clientBuf[bufSize];
       client.readBytes((uint8_t *)clientBuf, bufSize);
    }
  Serial.printf("%d end\n", end = millis());
  Serial.printf("delta=%d\n", end - start);

[devyte]

This looks ok to me code-wise. I don't know the implications for functionality.

[earlephilhower]

Argh, looking over it one last time I realize it's now going to be a problem as-adjusted.

Before we could twiddle with IRQ data structures as long as we bracketed it with disable-irq/.../enable-irq.

For NMI, disable/enable irq doesn't do anything. So we could catch an interrupt while in the middle of changing values and bad stuff will happen.

Need to make it lockless somehow, may be a significant effort.

[devyte]

Looks ok now, nothing jumps out at me.

[Jason2866]

With this change Tasmota is nearly unresponsible. Before it worked very well.

[earlephilhower]

@Jason2866, please open an issue and be much more specific or we're not going to be able to help you out. Also, are you sure it's related to this specific PR and not #5513 which was noticed at the 1st 2.5.0-dev release. Thx, -EFP3

[Jason2866]

@earlephilhower Thx for your comment. Did more testing. At the end the behaviour was a part defective Wemos Mini!! Everything is fine now :-)

[davidmpye]

This is causing me a problem :-(

If you try to use something timing critical like FastLED (or Adafruit_Neopixel) and PWM at the same time, you run into issues.

When I write the LED data out, I need to have interrupts disabled, otherwise, the NMI firing causes the FastLED data sequence to glitch, making the LEDs flash randomly. The fastled library suggests disabling interrupts during the write sequence, but obviously this fails if using NMI.

Is it possible to create a #define or similar to set whether the PWM code uses NMI or not?

David

[earlephilhower]

@davidmpye the most compatible is going to be stopWaveform/etc. right before the code in question followed by startWaveform/etc. right after. There may be other code in the processor (WiFi, etc.) which also comes in the binary SDK. This isn't as bad as it sounds since the tone/analogWrite would be garbage while writing the LEDs anyway since w/IRQs disabled they won't do anything at all and will be stuck at full high or low.

Alternately, look in the core_esp8266_waveform.cpp file where it's pretty straightforward to hack code in to make it a normal IRQ (but will fail during SPIFFS writes or other periods when IRQs are disabled for any period).