Hi guys,
would it also be possible to use 8 bit parallel connection with nodemcu board (esp 12e)?
Hi,
I have a txt 320x480 parallel 8 bit display purchased on ebay:
https://www.ebay.fr/itm/303086392816?ViewItem=&item=303086392816
To connect to my ESP8266 I made a pseudo bus 4 bit interface with only 3 x 74HC173. To control this display I have written some cpp code on the Arduino IDE.
The interface consumes 8 x GPIO to the inputs of the interface and provides 12 output wires to control the display on 8080 bus system.
The code initializes the display with the commands recommended in datasheet RM68140 / ILI9488
I have a writeCmdLCD(uint8_t) and writeData (uint8_t) function to write on the display.
That works well. Clear the screen in 0.536 seconds.
Now I would like to hang these two commands to an existing driver like TFT_eSPI.
Do you think that this possibility exists and someone can help me because it would not be reasonable to write a complete library.
inline void writeCmdLCD(uint8_t cmd) /* 13 à 14 microsecondes*/
{
write8(cmd); //put cmd code on lcd bus
writeControl(0b0001); // set CS, RS et WR = LOW
writeControl(0b0111); // WR up for write
}
/* CS RS WR RST positions on lcd control bus*/
inline void writeDataLCD(uint8_t param)
{
write8(param); //put parameter on 8 bit lcd bus
writeControl(0b0101); //CS LOW RS LOW WR = LOW
writeControl(0b0111); //WR up for write
}
Your screen has an RM68140 controller.
Bodmer's TFT_eSPI library is for SPI displays (and 8080-8 parallel with ESP32)
Why would you expect quad positive-edge triggered D-type flip-flop chips to be any use?
Seriously. Buy a TTGO ESP32 board and connect all the signals to the sockets specified by Bodmer.
RM68140 is different to ILI9486. Bodmer does not support RM68140.
David.
Dear David,
The number of GPIO is insufficient to control a TFT in parallel with an ESP8266. That's why I use 3 x 74HC173. Two for the 8 bit of data, the last one for the 3 control wires of the LCD: CS, RS and WR.
This feature allows me to save GPIO outputs on the ESP8266 and keep the SPI bus wires.
I know that the most logical solution for a project is to use a display with an SPI interface. I want to associate this viewer to an existing project using an ESP8266.
I made the basic bricks to display correctly on the screen simple things (clear screen, fill screen). I thought (but maybe I'm stupid) that it will be easy to hang on to the TFT_eSPI parallel mode.
Yes, you can make some external electronics. The question is WHY?
An ESP32 has sufficient GPIO for 8080-8. STM32 has sufficient GPIO.
ESP32, Due clone, STM32, ... are all very cheap.
Certainly easier than hand-wiring suspect chips.
Likewise, you can buy an SPI ILI9488 display cheaply. Runs out of the box with Bodmer's TFT_eSPI and ESP8266.
But it will also work with ESP32 too. And still have plenty of spare GPIO, SPI, I2C, ...
David.
I agree with what you said David. I have to tell you that the facility is not my thing .. I asked myself a challenge: Pilot this display with an ESP8266. I studied the specs of the 68140 and the relevant forums and made a lot of effort to write the necessary lines of code and achieve a satisfactory result.
Now you tell me that it is useless! That's not very nice..
I wish I could somehow be able to display something other than color bars. For example text lines etc ..
Good. I will immerse myself in the sources of the TFT_eSPI for what I can do as a new challenge.
It is easy enough to use a single shift register. i.e. for the 8080-8 data bus.
Much the same as the RPi displays use shift registers to drive a 8080-16 data bus. (and Bodmer supports)
Personally I am always more interested in a read-write bus. e.g. parallel input-output shift register.
The Waveshare RPi abortions are parallel-out only.
Hey-ho. RM68140 needs a few mods relative to ILI9486.
David.
You are obviously right on all these points David. A write-only system is not great. And using a shift register will bring nothing more (rather less speed).
I would just finish this work before moving on to something else (that's my stubborn side).
Maybe Bodmer could bring me some help?
I saw that MCUFRIEND_kbv treats RM68140 and ILI9488 the same way in its sources. What do you think?
No, RM64180 is a little weird when you change rotations.
Regarding pins. Surely a shift register is the only way to manage with few pins.
Controller SPI interfaces work fast. Likewise Flash memory chips. Standard HC or LVC logic is slow.
Or you use the quad-speed style of SD. But even that uses several GPIO lines.
If ESP32 or STM32 cost $100 I could understand the desire for ESP8266.
Life is so much simpler if you can use a singlechip MCU.
David.
I did a test with an MCP23S17. The result was horribly slow. This chip uses a shift register. You think a solution based on 74HC595 would be faster?
A HC595 will be reasonably quick. From memory the MCP23S17 requires a few commands per shift.
Probably with a 10MHz SPI max speed. The ESP8266 can do SPI much faster. The ESP8266 can wiggle GPIO pins quite fast.
Personally, I think it is a crazy exercise. I have a SPI ILI9488 display.
David.
Hello David,
That's it. I finished writing subclass of Adafruit GFX. It works pretty much as planned except for rotation that I still have to develop. So I can display text, rectangles, circles etc.
Of course with a transmission of 4-bit data it does not go very fast. FillSreen = 578 milliseconds for example. This should be useful for a write-only application like a weather station. The interface is very simple. No resistance, no capacitor, only 3 x 74HC173. 8 x input wire, 11 x output wire.
This work allowed me to learn how a controller like the R68140 works and how to make a subclass of Adafruit and raise a lot of mysteries.
Go on. It is quite simple. Just compare the write-cycle of an 8080-8 interface with a SPI interface. The timing diagrams are in every TFT controller data sheet.
You can replace the parallel port from the Arduino with a shift register e.g. HC595.
The High Level Logic remains the same. Instead of write_8() to an 8-bit PORT you use SPI.write(), you latch the shift register (by wiggling the WR line)
You should be able to achieve reasonable speeds with a HC595.
It should be faster than 8080-8 on a Mega2560 (with the Shield random PORT pins)
Making a bi-directional SPI interface is messy.
David.
Support for the RM68140 is now included in the TFT_eSPI library. This update has been provided by a library user and tested with ESP32 and 8 bit parallel interface.
The updated library is available direct from GitHub. A new release for the Arduino library manager download will be created soon.
489/5000
Hello,
Thank you Bomel for taking the time to answer me, I am very happy for this good news.
I managed my challenge. Here is the result (modest):
- ClearScreen: 463 ms
- FiullScreen: 475 ms
- 5 x "Hello Word !!: 120 ms
I will now be able to test the same 808-8 display with the ESP32 and your TFT_eSPI.h and TFT_eSPI.cpp.
Logically, the speed should be 2 x higher than minimum, going from 4 bit to 8 bit.
I will not bother David anymore with my 74HC173 story.
Jean of Paris.
@bisra If you use an UNO style display with an UNO style ESP32 board then this will give the best chance of success.
If you are hand wiring the display to another style of ESP32 board then keep the wires as short as possible, yes I mean really short, as the edge speeds put out by the ESP32 are high and causes signal integrity problems (edge ringing). Use thick wire for the 0V return to minimise lead inductance and reduce ground bounce.
An ESP32 in 8 bit parallel mode should clear a 320x480 screen in around 40ms. Whether that speed is important or not will depend on what you want to display on your TFT and how often screen updates are made.
4 ms .. Waoo! After optimization with your "lookup table", my best result is 180 milliseconds for a screen fill, which is still 6 times slower than you!
@David_Pentice
Hello David,
I replaced my three 74HC173 with 1 74HC595. The code is a little simpler but the result unconvincing.
To clear the screen with the 74HC173 solution, 184 milliseconds are set. With the 74HC595 solution, it takes 3 times more time: 580 milliseconds. The CPU frequency is 160 MHz and the SPI frequency 80 MHz on the ESP8266. I just rewritten the code write8 () to adapt it to the SPI. I took the hardware SPI with HMOSI on pin 13, HCLK on pin 14 and HCS on pin 15. I used a direct access to GPIO with GPOS and GPOC.
#define SL (GPOC=(1<<15))
#define SH (GPOS=(1<<15))
void SPI595::write8(uint8_t x)
{
SL;
SPI.transfer(x); //Send one byte
SH;
}
Go on. You just have to look at the Waveshare 16-bit shift register schematic.
And look at Bodmer's driver code.
Then draw the equivalent schematic for 8-bit shift register.
And write the appropriate driver code.
Or look at his 8080-8 parallel driver.
Life is an awful lot easier if you just buy a TTGO ESP32 board.
You can buy them in Europe. Or buy from China and wait a LONG time.
David.
Hi David,
My driver is finished with the 74HC595.