New 3.5" Color LCD display

We are currently building the first batch of full color graphical displays with WiFi.


2 people like this

@Ken We agree, the first firmware 5.1.0 was essentially a proof of concept, attempting to approximate the old display. 


The interface is by no means final, we took static images of the web interface. Future versions will use the LVGL.


We plan to add additional screens that will automatically change, showing the the session log, usage and history. In addition we are working on an enclosure with a cutout, seals and a touch display. The watertight seals are really tricky. The hardware is capable of display sleep, it is on the list.

Music to my ears.

Is it possible to confirm if the new LCD is a direct replacement for the old LED board and Wifi module?


My wifi module fails to perform a factory reset on the password and I figured if I was going to be going into the box to perform a manual reset, that I would go ahead and upgrade to the LED to the LCD with built-in wifi.

@Levi The NEW TFT LCD replaces the WiFi. Technically you could continue to use the older 2 line text LCD or the LED based displays. If you have the polycarbonate enclosure with the 2 line display, we have a lid only option that has the proper window for the new much larger display. If you have the older "portable" enclosure with the LED light only (no display) you would need to replace the whole enclosure and the size is too small.



That makes sense. I have the two line LED right now with the polycarbonate enclosure with the malfunctioning wifi module as mentioned. I'll take a look on the store to see if I can find the lid and add that to the card with the TFT LCD Display.


Assuming that the LCD display and wifi come pre-flashed with the latest firmware?



Any news on when the firmware can be updated for the new large LCD?

@ Ken


The current repartition process for the TFT LCD in the short term requires a USB => Serial adapter and esptools (requires Python and pyserial). 


Download the 5.1.2 - openevse_wifi_tft_v1.bin, bootloader_16mb.bin and partitions_16mb.bin from

https://github.com/OpenEVSE/openevse_esp32_firmware/releases/tag/v5.1.2


Connect the module to the USB => Serial adapter, then put the module in bootloader mode by holding BOOT and then pressing RESET then release BOOT


Run the command:


esptool --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_size=detect 0x1000 bootloader_16mb.bin 0x8000 partitions_16mb.bin 0x10000 openevse_wifi_tft_v1.bin

On Thursday, I received my TFT LCD and cover for upgrading my old OpenEvse Kit.

It came pre-flashed 

I love It !!

image


@ OpenEVSE Support I can’t seem to enter bootloader mode using the boot and the reset buttons and the instructions above. Maybe the boot button doesn’t work on my board? The reset button resets the screen and just boots it up normally. But holding the boot button and pressing the reset button just resets the screen and boots back up.
@OpenEVSE Support I’m having some trouble putting the 3.5” TFT LCD board into bootloader mode. Maybe the boot button doesn’t work on my board? When I follow the steps mentioned in a previous post, the screen just resets and boots back up normally. The reset button appears to work. Are there any workarounds?
@ OpenEVSE Support Never mind my previous question. I found the GPIO0 pin on the ESP32 and shorted it to simulate the boot button press and then pressed the reset button. I was able to get into bootloader mode and update to 5.1.2.

Conveniently I have an FTDI UART to use and a spare screen cable with the correct connector for the UART was included with the new screen and lid. Power and Gnd were 'loose' but I was able to crimp on the right terminal and add them to the connector (and USB 3 from the Mac was sufficient to power it all). However, the TX and RX were the wrong way around (I.e. RX to RX and TX to TX), so I had to pull them from the connector and switch them. Only took a very short time to do, but I'm puzzled why the cable had been supplied with them the wrong way around. I assume that spare cable was to enable this process and the screen connector has the same pinouts as the UART connector, except the cable's RX and TX were the wrong way around. Is there a reason why the cable is supplied like this?


Putting the screen module into bootloader mode did work, but the buttons were not easy to use, with no tactile feedback when they were pressed, so it was hard to know if they were detecting being pressed, especially as there seemed to be no other indication it had successfully switched into bootloader mode. The screen did turn off, but that was all and I just hoped all was correct and ran the esptool command.


Which seemed to execute correctly and after restarting it I was able to access the module and see that it reported now being on the new firmware. Is thre any way to actually detect a successful switch into bootloader mode without having to just run the command and see what happens?


A cursory look indicates the new firmware does not appear to have changed the screen layout at all. Now we have the ability to update directly from Github, can we expect an update soon that will provide better use of the new large screen which so far has been less useful than the old small screen?


Sorry If I'm sounding negative. It's meant to be constructive criticism. I just want that nice big screen to be better.


1 person likes this

@Ken Gillett


The wire is the correct way around for its intended purpose, connecting the WiFi module to older OpenEVSE controllers (v5 and prior). If the USB serial module is ordered from OpenEVSE it comes ready to go with the correct serial to WiFi/LCD harness, with all pins terminated and TX/RX correct for the use. Your use of the legacy harness was creative, good for you.


We do plan on many future updates for the new display, now that you have repartitioned you should be good to go for github updates.

Looking forward to them :-)

Login or Signup to post a comment