Mosaic
Well-Known Member
Hi all:
Spent a lot of hours debugging i2c comms between a 16F886 and ESP12e using a 24LC256 i2c EEPROM as a bridge.
The data transfer involved the PIC getting a few Kbytes serially over a USB/CP2102 bridge and converting it on the fly to I2C via 64byte page writes to the EEPROM using ASM.
Well, this raised a number of issues which I shall summarise here:
1) The ESP12e, with wi-Fi active has a very erratic current drain, 100mA spikes are common.
2) Getting a 5V 16x2 LCD to work requires a 3.6V supply, not a 3.3V. or your contrast will be almost non-existent.
3) Do not use dropping diodes to bring a 5V rail down to supply the ESP12 etc. You'll get ripple of up to 1/4V on the rail.
4) DO use a 0.1uF bypass cap close to the ESP power pins.
5) Sharing a 3.6V rail with the ESP12e and the 16F886 required an additional 10uF MLCC cap near the existing 0.1uf close to the 16f886 power pins.
6) The ESP12e creates noise on the SCL/SDA shared lines and screws up the Acks and Nacks comms with the 16F886
7) I used a PFET driven by the 16F886 to power down the ESP12e when doing I2C to the EEPROM.
8) Use 10K resistors as SDA/SCL pull ups, I was using 1K pullups (400Kbaud) and after a bit the EEPROM couldn't do the pulldown and the Acks vanished.
9) You CAN use GPIO 0,2,15 as I/O but your boot time levels on those pins must be set properly or you could boot into flash or SPI mode. 10K pull ups/downs can sort this out as req'd. An RC delay can be employed to alter the post boot default state automatically after a few mS.
10) While using GPIo3 is ok , GPIO1 seems to freeze the ESP if it is held hi on boot.
11) So you actually have 10 ESP12e GPIO if you're cognisant of the boot states required, GPs 0,2,3,4,5,12,13,14,15,16
12) The ADC is 10 bit over the range 0 to 1V. So don't fry it with 3.3V.
13)I can recommend the $40 EBAY 'Chinese' New USB Logic 100MHz 16Ch Logic Analyzer for ARM FPGA as essential for debugging serial/i2c and spi comms simultaneously.
This is the s'ware to drive it: https://www.saleae.com/downloads
Two minor bugs: You have to select the default i2c analyzer protocol each time you capture or it won't decode correctly after a few dozen serial bytes. Also, set the glitch rejection to 1 sample or you can get a few oddball missing Acks/Nacks.
Spent a lot of hours debugging i2c comms between a 16F886 and ESP12e using a 24LC256 i2c EEPROM as a bridge.
The data transfer involved the PIC getting a few Kbytes serially over a USB/CP2102 bridge and converting it on the fly to I2C via 64byte page writes to the EEPROM using ASM.
Well, this raised a number of issues which I shall summarise here:
1) The ESP12e, with wi-Fi active has a very erratic current drain, 100mA spikes are common.
2) Getting a 5V 16x2 LCD to work requires a 3.6V supply, not a 3.3V. or your contrast will be almost non-existent.
3) Do not use dropping diodes to bring a 5V rail down to supply the ESP12 etc. You'll get ripple of up to 1/4V on the rail.
4) DO use a 0.1uF bypass cap close to the ESP power pins.
5) Sharing a 3.6V rail with the ESP12e and the 16F886 required an additional 10uF MLCC cap near the existing 0.1uf close to the 16f886 power pins.
6) The ESP12e creates noise on the SCL/SDA shared lines and screws up the Acks and Nacks comms with the 16F886
7) I used a PFET driven by the 16F886 to power down the ESP12e when doing I2C to the EEPROM.
8) Use 10K resistors as SDA/SCL pull ups, I was using 1K pullups (400Kbaud) and after a bit the EEPROM couldn't do the pulldown and the Acks vanished.
9) You CAN use GPIO 0,2,15 as I/O but your boot time levels on those pins must be set properly or you could boot into flash or SPI mode. 10K pull ups/downs can sort this out as req'd. An RC delay can be employed to alter the post boot default state automatically after a few mS.
10) While using GPIo3 is ok , GPIO1 seems to freeze the ESP if it is held hi on boot.
11) So you actually have 10 ESP12e GPIO if you're cognisant of the boot states required, GPs 0,2,3,4,5,12,13,14,15,16
12) The ADC is 10 bit over the range 0 to 1V. So don't fry it with 3.3V.
13)I can recommend the $40 EBAY 'Chinese' New USB Logic 100MHz 16Ch Logic Analyzer for ARM FPGA as essential for debugging serial/i2c and spi comms simultaneously.
This is the s'ware to drive it: https://www.saleae.com/downloads
Two minor bugs: You have to select the default i2c analyzer protocol each time you capture or it won't decode correctly after a few dozen serial bytes. Also, set the glitch rejection to 1 sample or you can get a few oddball missing Acks/Nacks.
