1. 19 11月, 2018 7 次提交
  2. 27 9月, 2018 1 次提交
  3. 21 9月, 2018 2 次提交
    • C
      Reduce resource requirements, Share Interrupt (#1877) · e5ea089a
      chuck todd 提交于
      #1869 exposed a resource exhaustion issue. The current HAL layer for I2C support is designed to use a shared interrupt, But, during debugging to solve the interrupt overloading condition identified in #1588, and the generation of pr #1717, the interrupt allocation parameters were changed.  This change was unnecessary, the code will work successfully with shared interrupts.  So, there is no need to assign a private interrupt for each I2C peripheral.
      e5ea089a
    • M
      Update IDF to 3.2-3276a13 and esptool.py to 2.5.0 (#1878) · 96822d78
      Me No Dev 提交于
      * TX Flow Control and Code cleanup
      
      * Use semaphore instead of delay
      
      TX functionality is done.
      
      * Use single buffer and empty queue on exit
      
      * Fix compile issues because of LwIP code relocation
      
      * Add temporary header to fix Azure not compiling
      
      * Fix AsyncUDP early init
      
      * AsyncUDP Multicast fixes
      
      * Add source mac address and rework multicast
      
      * Allow redefinition of default pins for Serials 1 and 2
      
      * Update IDF to 3276a13
      
      * Update esptool.py to 2.5.0
      
      * Fix sketches
      
      * Fix log level in BluetoothSetial
      96822d78
  4. 18 9月, 2018 17 次提交
  5. 27 8月, 2018 1 次提交
  6. 18 8月, 2018 5 次提交
  7. 16 8月, 2018 1 次提交
  8. 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
  9. 30 7月, 2018 1 次提交