I have an 8-bit Monocrome TFT (240 x 160) that is driven by MCU-A. I have MCU-B (Arduino) that needs to read the TFT Display in real-time. So far, I was able to 'split' the Flex wire to both MCU-A and MCU-B. The objective is for the Arduino MCU-B to read the binary data, send it to the web server and have the 'display' replicated in the web page.

I'm thinking that if Arduino can capture the right bits, the display can be reconstructed in the web UI by the use of some scripting language (process? for example).

So far, I'm getting different sets of bits for each screen at different test sets and I need help on how to do this properly.

The TFT datasheet is located here.

  • 1
    \$\begingroup\$ looks like SPI to me. \$\endgroup\$ Commented Aug 20, 2017 at 0:09
  • \$\begingroup\$ @marcus no, that LCD only uses the parallel interface. The controller does have a spi and i2c interface, but the LCDs datasheet does not reference it \$\endgroup\$
    – Passerby
    Commented Aug 20, 2017 at 4:45
  • \$\begingroup\$ Passerby is correct. MCU-A is using the 8080 mode (BM0 pin is set to GND). \$\endgroup\$ Commented Aug 20, 2017 at 7:42
  • \$\begingroup\$ MCU-B is a Hologram Dash board [link] (hologram.io/dash/https://hologram.io/dash) which has ARM Cortex M4... which I believe is more than 10x faster than the FPGA-based MCU-A. MCU-B was able to gather 12,106 8-bit characters in just one High Pulse Width (Read). \$\endgroup\$ Commented Aug 20, 2017 at 8:12
  • \$\begingroup\$ I'm aware that WRITE pulse has "data setup" (WR0=LOW) and "data hold" time (WR0=HIGH). I set the code to get data when WR0=HIGH. For the READ pulse, I also set the code to get data while WR1=HIGH. \$\endgroup\$ Commented Aug 20, 2017 at 9:13

2 Answers 2


That LCD is using the uc1611 LCD driver in 8 bit parallel mode. The LCD driver is well documented and the datasheet available online.

You will need to duplicate the handling of the LCD controller, emulate it for all intensive purposes. You will need to dedicate 12 or more pins. This won't be a trivial project.

  • 1
    \$\begingroup\$ Yep, true dat. This, in fact, feels like nothing short of a small FPGA will do the job. Of you're lucky timing-wise, a parallel-to-serial shift register + a bit of discrete logic might do, too \$\endgroup\$ Commented Aug 20, 2017 at 8:00
  • 1
    \$\begingroup\$ all intensive purposes? :) \$\endgroup\$
    – pipe
    Commented Aug 20, 2017 at 8:16
  • \$\begingroup\$ @Passerby - This is not a trivial project as you've said. The closest I can get to understand UC1611 is via the UG82 library link. Let me know if there are other tutorial/resources to know how this driver works. \$\endgroup\$ Commented Aug 20, 2017 at 8:43

In addition to Passerby's answer: To reliably capture the communication between MCU-A and the LCD you need the MCU-B to sample the communication lines a few times faster than MCU-A changes these lines. Add to this the CPU time required to process the captured information, and you will need an MCU-B that is a few times (think at least 10 times, more would be more comfortable) faster than MCU-A.

  • \$\begingroup\$ Eh, the protocol is single enough that they can follow the "read all the lines when the clock transitions" method. \$\endgroup\$
    – Passerby
    Commented Aug 20, 2017 at 8:10
  • \$\begingroup\$ I was able to capture HIGH and LOW state of WR1 (Read Pulse) and record shows that • during LOW pulse - there are only 1 to 2 sets of 8-bit char • during HIGH pulse - 5 to 12,981 8-bit char is recorded... This is also the case when I read WR0 (Write Pulse). It's my first time to work with TFT and I wonder if this is the expected behavior... or am I doing it wrong. \$\endgroup\$ Commented Aug 20, 2017 at 8:31
  • \$\begingroup\$ @passerby what would your estimate be of the execution speed required for CPU-B relative to CPU-A? (Assuming a bit-banged approach, a hardware SPI might make things easier.) \$\endgroup\$ Commented Aug 20, 2017 at 8:35
  • \$\begingroup\$ Bit-banging... :) \$\endgroup\$ Commented Aug 20, 2017 at 9:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.