Go Down

Topic: LCD keypad shield on WEMOS D1 R32 (Read 1 time) previous topic - next topic

Paul__B

The issue is that GPIO12 is special and must be held low during bootup.
Noted.  As are GPIO0, GPIO2 and GPIO15 on the ESP8266 "special".


If you use GPIO12 to control RS or EN it has issues since the hd44780 control signals are pulled up and will override the weak internal pulldown on GPIO12.
Ah!  I hadn't noted that before.  This is presumably part of facilitating a 4-bit control mode.  :smiley-lol: Nominal 125 μA at 5 V, essentially a 40k pull-up - kinda like the INPUT_PULLUP on the ATmega.

This would be an issue on any ESP32 module/board not just this board.
Clearly.   :smiley-cool:

bperrybap

#16
Aug 02, 2020, 12:06 pm Last Edit: Aug 02, 2020, 12:08 pm by bperrybap
This is presumably part of facilitating a 4-bit control mode.
Its been a while since I looked but I think the data lines are pulled low vs high.
What allows 4 bit mode control to work without having to strap the unused lower 4 bits is that the data lines are pulled down.
This ensures that function set commands can get the LCD back into 8 bit mode and then into 4 bit mode to always get the host and the LCD back into nibble sync.
In order for that to work, the unconnected D0-D3 pins must read consistently when in 8 bit mode.
There is a very long description of how this works in the hd44780 library in the  begin() function.

--- bill

bperrybap

#17
Aug 10, 2020, 12:24 am Last Edit: Aug 10, 2020, 12:27 am by bperrybap
In short, that board is a complete bodge!  :smiley-roll-sweat:
Ok, so I've changed my mind on this board.
I'm now down on this board design as well as many of the esp32 boards which use this same design for autoreset.
The reason being is that they have a funky DTR/RTS circuit from the USB to serial chip that is used for autoreset downloading.
Both signals from the USB chip go through a transistor. DTR controls EN, and RTS controls GPIO0/BOOT.
The transistors create an active low output and can only be used to sink the ESP signal pins low.
i.e. DTR and RTS don't directly control EN or GPIO0.
The odd part is that the two transistors are interconnected to ensure that both outputs can't be low at the same time.
i.e. DTR must be high and RTS low to get EN low
 and RTS must be high and DTR low to get GPIO0 low.
If RTS and DTR both are high or both low, then neither EN nor GPIO0 will be sunk low so they float back high.

However.....
In order to enter serial bootloader mode, you need both low at the same time so that EN can rise when GPIO0/BOOT is still low.
On paper the circuit doesn't work. However in practice it *works* on some systems.
The board depends on some built in capacitance to alter the slew rate of the rising EN signal to get it to work.
i.e. EN rises slow enough so when you sink GPIO0 low by setting DTR high and RTS low that EN remains low long enough so that the esp32 sees GPIO0 low when coming out of reset to enter serial bootloader mode.

However... It doesn't always work.
It seems to work all the time on one of my machines but not at all on another machine.
Both have identical OS and Arduino s/w.
But they are different motherboards with different processors (Intel vs AMD) and also different USB chipsets
The USB voltages on the two machines is also bit different.
I don't have a scope but this might be why it isn't working on the one machine.
I can see the timing difference on the logic analyzer to see the issue on the non working machine but it would be nice to see the real raw analog signal to see what is really going on.

Apparently, this auto boot failure issue is a well known issue in the esp32 world.
Many people simply press the "boot" button to get USB serial downloading to work.
The ESP32duino board doesn't have a boot button.
The other popular solution is to add a 10uf cap between EN and GND to slow down the signal rise time to allow USB serial autoreset to work for serial downloading.


What mess.

--- bill

Paul__B

So this is the same circuit as the WeMOS D1 Mini?

Doesn't matter to the 8266?

(Sorry, can't look into it in detail just now!  :smiley-roll: )

bperrybap

So this is the same circuit as the WeMOS D1 Mini?
It is similar but different.
Another thing I noticed is that ESP8266 has both RST and EN whereas the ESP32 only has EN.
The ESp8266 boards use RST to reset the board.
The espduino-32 board I have is feeding in 4.1 volts into the EN and GPIO0/BOOT pins.  :smiley-eek:
The two transistors are J3Y and the signals that feed it are from a CH430C USB to serial chip running at 5V with 5V logic signals.
So that is likely causing the collector to float up to 4.1 volts as the logic signals connected to the base and emitter are at 5V.

But the esp32 "mini" style board uses a different design and has 3.3v on the EN and BOOT pins.

There are so many versions of these boards and some if not all of them have issues.


--- bill

Paul__B

The two transistors are J3Y and the signals that feed it are from a CH430C USB to serial chip running at 5V with 5V logic signals.
So that is likely causing the collector to float up to 4.1 volts as the logic signals connected to the base and emitter are at 5V.
Pulled up by the base-collector junctions.  Arguably the base resistors should be 100k rather than 10k.



But the esp32 "mini" style board uses a different design and has 3.3v on the EN and BOOT pins.
OK, so it powers the CH340 from 3.3 V, why then does the D1 R32 not?  :smiley-roll:

bperrybap

On the espduino32 board I have, the CH240C connects VCC to USB VBUS for power and V3 connects through cap to gnd.
The cp2102 looks a bit more flexible in that i/o voltage output appears to track vdd rather than vcc.

The "mini" esp32 module that I have uses a cp2102 vs the espduino-32 uses the CH340C.

--- bill

bperrybap

#22
Aug 11, 2020, 06:09 am Last Edit: Aug 11, 2020, 07:00 pm by bperrybap Reason: correction to say the esp32 does *not* include an analogWrite() function.
smlee0511,
The hd44780 library has been updated to better support the esp32 platform and the espduino32 board.
The new release is version 1.3.1

Depending on the board you have there may be some h/w issues.
So you may have to do some h/w modifications to your WeMos D1 R32 board.

For the board I had, I had to:
- solder a 10k resistor between GPIO12 and ground
This h/w fix allows the board to work and download when the keypad shield is plugged in.
On a espduino32 board it is the header pin for D8

- solder a 10uf cap between EN and ground.
EN pin is wired up to the "reset" button and the header pin labled "RST"
This h/w fix allows the board to download if downloading isn't working and the ide is reporting:
A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header

I soldered the cap across the "reset" button on the side of the board by the usb connector.

Once you can download to the espduino32, all the included hd44780_pinIO examples should "just work" with the keypad shield plugged in.

One really sad thing is that the esp32 platform does not include an analogWrite() function, so this means that you will not be able to do any backlight dimming using the hd44780 library.
Here is the esp32 platform issue about it:
https://github.com/espressif/arduino-esp32/issues/4

The esp8266 boards including the Wemos D1 R1 uno form factor boards do not have these issues.

--- bill




Go Up