Backmerge #3
Merged
Backmerge #3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Make sure to remove that next rebuild
* Allow configuration of Ethernet PHY clock source Refer to espressif/esp-idf#1127 The internal APLL can be used to generate the 50MHz clock for the internal EMAC and the external Ethernet PHY. The clock can either be input on GPIO0 (as before) or output on GPIO0, GPIO16 or GPIO17 (only GPIO17 extensively tested). New example available. * Allow configuration of Ethernet PHY clock source Refer to espressif/esp-idf#1127 The internal APLL can be used to generate the 50MHz clock for the internal EMAC and the external Ethernet PHY. The clock can either be input on GPIO0 (as before) or output on GPIO0, GPIO16 or GPIO17 (only GPIO17 extensively tested). New example available.
… generated if the wrong method is called to retrieve the data stream. (#934)
* Update mDNS and LEDC * update toolchain * Update IDF to 1c3dd23 * Advertise the board variant for Arduino OTA * Add generic variant definition for mDNS
This fixes the compile error when we include SPI.h
* Small grammar fixes and clarifications Just fixed some small grammar issues in the comments and clarified a few things that might seem confusing. * More spelling fixes that I introduced...
adding an additional step that is required to make sure the BLE libs are synced
* Added a lastError method to WiFiClientSecure so that a connection error from mbedTLS can be retrieved if connection fails (and then presented to a user). * Changed to dos CRLF * Made buffer size a const\nMore cleanup to match source
* Retrieve some code from what has been done on the ESP8266. Clarify a bit the signification of several bytes in the response. * Add the type and class as members of the DNS class for an eventual future use. * Clarify the sense of a magic number present in DNS server. * A bit of aesthetics for the DNS server. * Add a structure for the DNS question, use it DNS server to store the question data and to create the DNS answer from scratch.
* enchanced EEPROMClass * Added eeprom examles and modified partition * added eeprom class and extra examples * No changes * No changes * added eeprom class and examples * fixed typo * length() returns user-defined sector size * updated and annotated example
* Add ttgo-lora32-v1 folder to variants folder * Add ttgo-lora32-v1 info to boards.txt * Add defs to pins_arduino.h for I2C OLED and SPI LoRa radio pinouts as per @stickbreaker
If you receive a package with a data length of zero, parsePacket returns 0, but rx_buffer will exist. So if another parsePacket with no read access returns to zeros, there is still data that can be read. This example would not work: https://www.arduino.cc/en/Reference/EthernetUDPParsePacket Also I added a check if rx_buffer exit when you try to flush it.
Sketch for ESP32 boards that allow them to connect to WPA/WPA2 Enterprise Networks.
* Add M5Stack-FIRE board * updated m5stack-fire boards.txt * remove pins 16 and 17
When a package of size 0 arrives, "buf" is created, but never released. (Sorry, that was my mistake in the last patch)
* Selective compilation * Optimized component.mk * Autoconnect WiFi now forces WiFi
…1677) speed up uploading data. Now there is no need to call time consuming client.connected() method.
* Added a define to format the spiffs in SPIFFS_Test.ino * Uncommented the define * Matched define names
* Added instructions for installation with boards manager (stolen directly from esp8266) * changed to production link instead of dev * Added to main README. Made mods to images as requested. * Added links for development package
* Added instructions for installation with boards manager (stolen directly from esp8266) * changed to production link instead of dev * Added to main README. Made mods to images as requested. * Added links for development package * Moved version images to README.md * Just a little change for cleaner look * Cleaned up README.md and boards_manager.md to make installation easier.
…1695) Because TCP is stream-based, an earlier read can 'take away' the "OK" response from the device, so that a later read doesn't get the message.
* 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.
* informations about sketch * Update README.md
add a troubleshooting hint
If the esp32 is reset during a i2c read cycle the slave device may be in control of the SDA line. If the SDA line is held low, the esp32 cannot issue a START or STOP to recover the bus. The previous code did not correctly configure the SCL output pin, and it cycled SCL 9 times with SDA Low. Since the slave device was in a READ cycle, it just continued outputting the bits of the current byte. When the ACK/NAK bit space occurred, The low output value of SDA was interpreted as ACK so the slave device continued with the next byte. It never terminated the READ cycle. This new code will correctly recover from an interrupted READ
The original pins_arduino.h did not correspond to the actual hardware.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.