fixed delays for esp32

[ChrisIdema]

esp32 uses FreeRTOS delay with default 10 ms timer tick., so ticks are rounded down to 10 ms tick intervals and a tick can take 0 milliseconds worst case. So the reset sequence was invalid as the delays were too short. I used a longer delay for the reset sequence and used micro second delays for other functions. Some functions do not have a CMD_DELAY listed in the datasheet and work fine without a delay. In fact readFillArray is too slow with a delay so it clogs up the FIFO.

You have to continuously check the FIFO or else it will fill up and first the values will lag behind and then you will get invalid values because there are FIFO errors. I haven't found a way to avoid this. I've created an example which avoids this problem by reading it quickly.

I have only tested this on the ESP32. So be sure to test it on other Arduinos.

[kylejohnson]

@ChrisIdema Would this also be required on the ESP8266?

[ChrisIdema]

@kylejohnson I think it will be required since it uses freertos with default 10ms tick too.

[kylejohnson]

So on an ESP8266 (specifically a NodeMCU), I had the sensor mostly working with sparkfun:master. I use "mostly" because occasionally the sensor would stop responding - it would fail to light up red when my finger was placed on it, and I'd just get 0 back for heartrate, confidence, oxygen, and status.

With this code, that isn't happening anymore, so I'll call that a win!

[kylejohnson]

Is there any significance to the 500 value on https://github.com/sparkfun/SparkFun_Bio_Sensor_Hub_Library/pull/16/files#diff-a76216630f9dd91290ed658e29d2644e8799df2fed916716a695b670d9ff8e73R154? I want to gather data once a second, so I imagine changing 500 to 1000 is all I'd need to do?

[ChrisIdema]

@kylejohnson
It slows down the printing without slowing down the reading of the sensor. You can use any arbitrary value (or better use a constant or define instead of a magic number). I'm glad to hear it works on the ESP8266!

[edspark]

This is great, simple, unfortunately I had to do a number of updates to the library itself. If it's not too much trouble, do you think you could add these changes to the updated library? If not let me know. I think if it's not compatible with Arduino boards right out of the box that we could fix it with a number of preprocessor statements to check the hardware being used.

[edspark]

This is very interesting and I've used the info to further research the issue - though it is a difficult one to track down. If I can indeed confirm which I think will just require the sensor sticking to my finger for an extended period then I'll implement something similar with regards to using delayMicroseconds. None the less since this is pull request is so old I'll be closing it.