Since the ESP8266 wasn’t working for this project, I ordered a Feather Huzzah ESP32, which features a slightly newer Wifi chip from Espressif. I had high hopes that this would be a cheaper alternative to the M0 feather, since it had a math-coprocessor and dual cores. I thought the second core could handle the 10kHz interrupt routine to read the microphone while the primary core did all the I/O with the WiFi.
It seemed to work well initially, but the processors starting panicking and resetting every few seconds. I built a test rig, and it was able to handle reading the mic at 10kHz no problem, however, as soon as I added my NTP routines to timestamp the buffers, then it reset almost immediately. My first thought was that the NTP estimation routine was slow enough to cause the interrupt service routine (ISR) to bleed into the next firing of the timer interrupt, but after a little research there appears to be another problem.
When I ripped out the hairy math that did time skew estimation and replaced it with slightly less hairy math, I used floating point calculations. I thought that the ESP32, with it’s dedicated floating-point co-processor would make quick work of these, and it probably does, but doing floating point math in the ISR is apparently a no-no. Maybe because the coprocessor uses interrupts to signal that it has completed its calculation, and that having interrupts within interrupts was causing a race condition of some kind, and that was occasionally reseting the chip.
So now I either have to go back to hairy integer math in the skew estimation routine, or I need to stick to the M0. I think I’ll stick with the M0, and swallow the additional $15 per microphone.