LCD or OLED retrofit for PM6690 / FCA3000 / CNT-90 frequency counter

[morris6]

For those forum members interested in the design some details here:

I used a small development board from the German firm Trenz, a Max1000. I had it available and I used it before. For me programming works using the Quartus graphical method patching modules in a schematic "board file". I am aware that this is not the preferred method but it works for the nuts and bolts guy (me). The setup has grown into several functions:

- A section to hard reset and then program the ST7701S controller of the display with the required initialisation command stream via a 9 bit serial connection. A ROM with these commands is programmed in the FPGA.
- A display controller generating the synchronisation signals and reading the pixel data out of a dual ported RAM containing one frame of display data, 16384 x 4 bits. The RAM addresses are organised such that horizontal and vertical are interchanged. This is needed because the display's long side is the vertical axis as seen by the ST7701 controller. One bit of the RAM content is displayed in a 3 x 3 area of pixels on the TFT to get the correct scaling for the required 320 x 97 dots of the original monochrome LCD. The TFT display is used in simple black / white mode.
- A signal decoder is interpreting the control and data signals coming from the CNT-90 MCU. Under control of this decoder the incoming 4 bits wide data bytes are written into the frame RAM.
- For testing a signals generator mimicking the original control signals was added. The test uses a data frame ROM with picture data extracted from the Logic Analyser file thanks to @Smile2016, Reply # 19 session6.zip. This data ROM is programmed in the FPGA.
- At the top 4 blanc lines are added and at the bottom the last dot line is repeated until the edge of the screen. This way the remaining dot lines are filled with the active frame placed in between.

The setup above was working so I removed the signals generator to free up some pins of the development board and adapted it for connecting the signals of the CNT-90.

After connecting to the CNT-90 it was noticeable that updates of the picture contents are visibly seen to build from left to right. So most likely the lcd controller stores the incoming data to one frame while displaying another. I think the LCDFRM signal that alternates between complete frame writes controls this proces. I have implemented this concept, with two frame RAMs, and indeed the resulting picture behaves more like the original LCD while refreshing the displayed data. Still some "buildup" is noticeable, the number area is probably erased before a new number is written. But this is also somewhat visible on the original LCD. The TFT's frame rate is about 60 / second while the original frame period is about 13 ms.

Attached is a Zip file of the Quartus project as it is now. You can find here also a top.pdf that gives a picture of the schematic assembly with some comments.

Interesting files:

cnt90qu3.qpf : the Quartus project file to open the project... for MAX10 10M08SAU169C89
top.bdf : the board file
trial0.mif : This is the memory initialization file for the ST7701S COG controller, for the init_rom.
test2.mif : This file contains a frame of 4 bit wide data for the test generator test_rom, not used here anymore.

Feel free to make suggestions to correct mistakes I made or misconceptions I have. And use whatever is fitting for you.

Have Fun, Morris

edit: corrected original frame period number

[Smile2016]

.... It will need a boost converter to get 12 Volt for the backlight, the original is 5 Volt fed from one of the pins. And a short FFC ribbon to the J2 connector. The design will have to use a "solderable" FPGA. ...

Some pictures...

... all necessary signals are present on J2 FPC20. The "V0" currently serves as the "backplane" voltage for the original display and is adjustable by the instrument as "contrast," generated by the TPS61045 boost converter. According to the datasheet, for a 3.3V to 12V conversion, we can theoretically achieve up to 42mA at 12V or 34mA@15.3V (so shorting or lowering R20 and R1 is needed). R8 will be adjusted to optimize the backlight current for a mid-bias setting. I'll conduct some tests to determine if the TPS61045 can handle 40mA, although 20mA might be sufficient and could also extend the backlight LED's lifespan. If so V0 could be repurposed for the retrofit LCD BKlight. Adjusting BK light intensity would be a nice free feature...

[morris6]

For now, during further trials, I have the backlight on a bench supply. At 17 mA current the brightness looks "bright" enough. Your idea to use the V0 line as source for the backlight is very clever and simple, thanks.

What I'm busy with is finding out why some of the content on the screen is still a bit flashing although the setup is using alternating RAMs. To investigate this I have programmed a function that compares the incoming data content frame per frame. It shows that updating the measured value on screen can take several, more than 4 or 5, frame periods. The page with statistics takes even longer: during a significant part of the one second period between updates new data are written. For me this explains the flashing. Untill someone presents a better idea or method.
The original LCD, I think, is so slow that updating is hardly visible.

[morris6]

Screenshot: Yellow trace is changing at every new incoming frame, cyan trace is a flag that indicates different frame content compared to previous frame, reset at every new frame. This is of the display that shows in "Value" mode.

[Smile2016]

LCD adapter plate... here are a few pictures... any ideas or suggestions are welcome!

[morris6]

The FPGA setup now registers differences in frame content between incoming data frames. A difference holds the alternating of the display RAMs so the last unchanged data remains displayed. When at least 3 (this could be made 2, or 1) unchanged data frames have passed the display is updated and alternating resumes. The resulting display is really nice, no more visible erase and buildup of the measured results on the screen. Only the characters that need updating are doing so, the rest of the screen is static.

Downside of the present setup is that more block RAM in the FPGA is needed.

[morris6]

A different setup is working as well. The comparison of frame content can also be done by simply adding all data bytes in a frame. Results are stored in two registers that are updated one by one. When different the display memory stops alternating and stays on the before last frame, waiting until frames are equal again.

This new setup saves the block RAM needed for the previous compare scheme. The new scheme is, of course, not 100% reliable since accumulating byte results can be equal while the frame content is different. But it works quite well and an occasional "foul" is not fatal. It saves 128kb Block RAM and a few bucks for the FPGA chip.

[morris6]

Attached is a Zip file of the Quartus project as it is now. To save space in the zip the project is "cleaned", you will have to recompile. And anyway you'll have to adapt the project with your pin assignment. The compilation report gives that this design uses 226 logic elements, 163 registers and 133.376 memory bits in block RAM.

This version has an INVERT pin, when this pin is connected to GND the display is black on white, like original. When connected to VCC it does white on black.
This version has the display oriented so that the connecting FPC is on the left of the TFT. In fact the display is upside down here. Or, more precisely, rotated 90 degrees right considering that the long side is vertical according to the datasheet.
To have the connecting FPC on the right side there have to be made some changes to the IP Parameters of inst34 src_hor_count. These are noted in comments shown in top.bdf. Also command C7 in the initialisation .mif file must be set to "reverse" in this case. And the order of the data lines must be reversed.

Interesting files:

top.pdf: for your convienience, it gives a picture of the schematic assembly with comments.
cnt90qu5.qpf : the Quartus project file to open the project... for a Trenz MAX1000 development board with 10M08SAU169C89.
top.bdf : the board file.
trial0.mif : This is the memory initialisation file for the ST7701S COG controller, for the init_rom.

[Smile2016]

A preliminary PCB real-estate study using BGA169 variant. PCB size 50*40mm

[Smile2016]

https://microtipsusa.com/mu_product/awl-400960t40n01/
this is another compatible display available at major distributors. higher $$