GitLab

EEPROM.h uses data types which are declared through Arduino.h but that file does not contain an #include directive for Arduino.h. This does not cause any problems when the EEPROM library is #included from a .ino file because the Arduino IDE automatically adds an #include directive for Arduino.h but this is not the case for .cpp files. If a .cpp file has an #include directive for EEPROM.h that does not follow an #include directive for Arduino.h then compilation fails:

E:\arduino\hardware\espressif\esp32\libraries\EEPROM/EEPROM.h:91:5: error: 'float_t' does not name a type

     float_t readFloat(int address);

     ^

E:\arduino\hardware\espressif\esp32\libraries\EEPROM/EEPROM.h:92:5: error: 'double_t' does not name a type

     double_t readDouble(int address);

     ^

E:\arduino\hardware\espressif\esp32\libraries\EEPROM/EEPROM.h:95:5: error: 'String' does not name a type

     String readString(int address);

     ^

E:\arduino\hardware\espressif\esp32\libraries\EEPROM/EEPROM.h:110:36: error: 'float_t' has not been declared

     size_t writeFloat(int address, float_t value);

                                    ^

E:\arduino\hardware\espressif\esp32\libraries\EEPROM/EEPROM.h:111:37: error: 'double_t' has not been declared

     size_t writeDouble(int address, double_t value);

                                     ^

E:\arduino\hardware\espressif\esp32\libraries\EEPROM/EEPROM.h:114:37: error: 'String' has not been declared

     size_t writeString(int address, String value);

* Initial support for ALKS variant

the 'eject' ERROR is and indication of an interrupt triggering without an source.  I am working to eliminate these serviceable interrupt.  This update increase stability on a HelTek Wifi Lora 32 board. with a SSD1306 OLED.  This update fixes a glaring error in the interrupt allocation code, the Interrupt mask was wrong.  I also dynamically adjust the FiFo thresholds based on Bus clockrate. The change to FiFo thresholds has reduced the number for 'eject' events.  I also change 'eject' from and ERROR to DEBUG.  An 'eject' event does not compromise i2c transmissions. It happens after a transaction has completed. 

Chuck.

* Create pins_arduino.h

* Update boards.txt

* Update pins_arduino.h

* Allow using argument with attachInterrupt

* formatting

replace tabs with spaces

* fix bug more then 1 interrupt

* leftover

* add example

* make attachInterruptArg public

* update example

* leftover

Fixes: https://github.com/espressif/arduino-esp32/issues/1597

* script exec fails on curl error

Thanks @igrr

If Core Debug Level is at DEBUG, a confusing debug message will be emitted if the I2C transaction takes longer complete than the  calculated minimum time.  This original debug message was just to prove that this new i2c code could correctly handle SCL stretching or interrupt latency issues. This delay is not a problem, or an error.  Usually it is caused by a higher priory interrupt starving the i2c ISR.  Usually WiFi is the culprit.  As long of this delay is within the configured timeout (by default 50ms, or can be set with Wire.setTimeOut(milliseconds);) no problem will occur and the transaction will successfully complete.
Chuck.

* Add PSRAM init and malloc funtions

* Rebuild IDF libs

* added OTAWebUpdater

* added OTAWebUpdater

* Updated OTAWebUpdater