1. 18 9月, 2018 4 次提交
  2. 27 8月, 2018 1 次提交
  3. 18 8月, 2018 5 次提交
  4. 16 8月, 2018 1 次提交
  5. 14 8月, 2018 5 次提交
    • I
      Switch to isolated build flags per framework (#1748) · fff17830
      Ivan Kravets 提交于
      fff17830
    • M
      Informations about WifiClientEnterprise.ino sketch (#1737) · cb53ec48
      Martin 提交于
      * informations about sketch
      
      * Update README.md
      cb53ec48
    • T
      Update Arduino/hardware path (#1727) · 7d3a67ad
      Tokusei Noborio 提交于
      7d3a67ad
    • L
      d057e544
    • C
      Wire ReSTART fix, with others (#1717) · b05430cf
      chuck todd 提交于
      * ReSTART fix, Sequencing fix
      
      pr #1665 introduce a problem with ReSTART, when solving this problem I found an interaction between the TxFifo refill, RxFifo empty and CMD[] fill.  during certain sequences a dataqueue command would be skipped, this skipping resulted in a mismatch between the contents of the TxFifo and the i2c command sequence.  The problem manifested as an ACK error. 
      In addition to this required bug fix I propose:
      * `Wire.begin()` be changed from a `void` to a `bool` this will allow the reset functionality of `Wire.begin()` to be reported.  Currently `Wire.begin()` attempts to reset the i2c Peripheral, but cannot report success/failure.
      * `Wire.busy()` be added. this `bool` function returns the hardware status of the bus. This status can be use in multi-master environments for application level interleaving of commands, also in single master environment, it can be used to detect a 'hung' bus.  With the functional change to `Wire.begin()` this allows app level recover of a hung bus.
      * `Wire.lastError()` value updated for all errors, previously when interleaving `Wire.endTransmission(false)` and `Wire.readTransmission(false)`, the 128 byte `Wire.write()` buffer was exhausted without generating and error(very exotic). I discovered this error when I created a sequence of directed reads to a EEPROM. Each directed read used 2 bytes of the 128 byte `write()` buffer, so after 64 consecutive ReSTART writes with ReSTART reads, `Wire()`  had no room to record the directed address bytes.  It generated just a NAK check without setting the EEPROMs internal register address.  The succeeding ReSTART read succeeded at incorrect address.
      * Changes to the HAL layer:
      ** added `i2cGetStatus()` which returns the i2c peripheral status word, used to detect bus_busy currently
      ** added `i2cDebug()` programmatic control of debug buffer output
      ** changed `i2cAddQueue()` to allow data_only queue element this will allow a i2c transaction to use multiple data pointers.
      ** removed direct access to DumpInts(), DumpI2c() from app, use i2cDebug() to set trigger points 
       
      *
      
      * Update esp32-hal-i2c.c
      
      * Update Wire.cpp
      
      * ReSTART, Sequencing
      
      pr #1665 introduce a problem with ReSTART, when solving this problem I found an interaction between the TxFifo refill, RxFifo empty and CMD[] fill.  during certain sequences a dataqueue command would be skipped, this skipping resulted in a mismatch between the contents of the TxFifo and the i2c command sequence.  The problem manifested as an ACK error. 
      In addition to this required bug fix I propose:
      * `Wire.begin()` be changed from a `void` to a `bool` this will allow the reset functionality of `Wire.begin()` to be reported.  Currently `Wire.begin()` attempts to reset the i2c Peripheral, but cannot report success/failure.
      * `Wire.busy()` be added. this `bool` function returns the hardware status of the bus. This status can be use in multi-master environments for application level interleaving of commands, also in single master environment, it can be used to detect a 'hung' bus.  With the functional change to `Wire.begin()` this allows app level recover of a hung bus.
      * `Wire.lastError()` value updated for all errors, previously when interleaving `Wire.endTransmission(false)` and `Wire.readTransmission(false)`, the 128 byte `Wire.write()` buffer was exhausted without generating and error(very exotic). I discovered this error when I created a sequence of directed reads to a EEPROM. Each directed read used 2 bytes of the 128 byte `write()` buffer, so after 64 consecutive ReSTART writes with ReSTART reads, `Wire()`  had no room to record the directed address bytes.  It generated just a NAK check without setting the EEPROMs internal register address.  The succeeding ReSTART read succeeded at incorrect address.
      * Changes to the HAL layer:
      ** added `i2cGetStatus()` which returns the i2c peripheral status word, used to detect bus_busy currently
      ** added `i2cDebug()` programmatic control of debug buffer output
      ** changed `i2cAddQueue()` to allow data_only queue element this will allow a i2c transaction to use multiple data pointers.
      ** removed direct access to DumpInts(), DumpI2c() from app, use i2cDebug() to set trigger points 
       
      *
      
      * Forgot DebugFlags Return
      
      @andriyadi found this, total brain fade on my part.
      b05430cf
  6. 30 7月, 2018 4 次提交
  7. 28 7月, 2018 2 次提交
  8. 26 7月, 2018 4 次提交
  9. 25 7月, 2018 10 次提交
  10. 17 7月, 2018 4 次提交
    • L
      expose post args during upload (#1650) · e157ec06
      Luc 提交于
      e157ec06
    • M
      05d72f96
    • P
      Release notes formatting update (#1634) · b14f82b6
      pacucha42 提交于
      b14f82b6
    • P
      EEPROM library: Move #include of Arduino.h to header file (#1641) · c830511f
      per1234 提交于
      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);
      c830511f