Advantest/ADCMT R6581 VFD to TFT conversion

[IanJ]

Vladimir,

I can only suggest you run the latest code, try press DCV on power up to get the LCD config options, and if you are not getting that and not getting anything on the LCD in normal operation.......then ship me your Pcb with the Blue Pill & LCD and I will test on my R6581T here....once my 24/7 test is completed.

If you try with the VFD fitted again, then you CAN run the VFD and my Pcb at the same time (dual display).

Or,

I can ship you a programmed Blue Pill (albeit untested because I am running 24/7......but it will be fine).

Ian.

[GRMPhD]

Hi Ian!

I finally got my display in the mail and it’s installed and working nicely!

A few things I’ll point out to anyone who wants to try it are:
1: The first blue pills I bought on Amazon that came with the programmer did not have enough flash memory to program the hex file which is ~100k. They only had 32k. So I had to buy another one. Make sure you get a real one!
2: When I first powered up the screen I just got a black screen with a few racing dots along the edge no matter what I did. This happened even with the test programs. I checked the SCL, SDA, and Reset lines with the scope and everything looked fine. However, when I did this I had not yet connected the wires to the DCV button because I was eager to see something. Once I connected them everything started working fine.

I’ve had this meter since 2019 and have barely used it since the display was so dim. I even tried rejuvenating the VFD and had no luck. Now it can actually get some use!

Thanks for making this project free and open!
Geoff

Here are some before and after pictures:

[IanJ]

Thanks GRMPhD, I have updated the instructions in post #1 to mention that the DCV switch hook-up is no longer optional.
Enjoy your R6581T and its beautiful display. I'm betting like me you turn on the DMM even though you are not necessarily using it....:-)

A 32k BluePill would certainly fail to program, Visual Studio reports:
Flash req'd = 37KB out of 64KB (58%), SRAM req'd =3688 bytes out of 20KB (18%)

I have also removed the TEST hex files from post #1, I think they were a bit more trouble than they were worth as they had a few caveats!

Ian.

[vf33184]

Thanks GRMPhD, I have updated the instructions in post #1 to mention that the DCV switch hook-up is no longer optional.
Enjoy your R6581T and its beautiful display. I'm betting like me you turn on the DMM even though you are not necessarily using it....:-)

A 32k BluePill would certainly fail to program, Visual Studio reports:
Flash req'd = 37KB out of 64KB (58%), SRAM req'd =3688 bytes out of 20KB (18%)

I have also removed the TEST hex files from post #1, I think they were a bit more trouble than they were worth as they had a few caveats!

Ian.

Hello Ian,
I can confirm finding of GRMPhD about mandatory DCV button wiring presence.

What I tested:
- firmware from December 27th (before DCV feature was introduced) and disconnected DCV - display works
- firmware from  January 26th and disconnected DCV - display doesn't work
- firmware from  January 26th and connected DCV - display works
- testing firmware (both VFD SPI enabled and disabled) and disconnected DCV - display doesn't work
- testing firmware (both VFD SPI enabled and disabled) and connected DCV - display works

Anyhow, thanks to this finding my display is working again and I can continue testing latest beta firmware potentially addressing TFT refresh issue. Will report it back.

Thank you Ian and GRMPhD.

Vladimir

[IanJ]

Hello Ian,
I can confirm finding of GRMPhD about mandatory DCV button wiring presence.

Ahhhh!......I thought you had the DCV button connected all this time......I mentioned using the DCV button on one of my posts above.
Oh well, at least you are back on track.

The latest current firmware has a lot of tweaks over the original and including the TEST versions.....so any testing please do it on the latest firmware and don't forget you can hold the DCV button in to bring up the TFT config options screen.

Ian.

[z01z]

As per Ian's request let me describe my findings about using the mod for the R6243 here as well.
The display circuit appears very similar to the one used in R6581. Using Ian's adapter PCB looks doable, there's enough space behind the front panel. For mounting the PCB some kind of adapter will be needed, unfortunately the position of the front panel mounting screws is off.
One complication for the R6243 is the DCV button, without which only 2 thin lines at the LCD edge are displayed. A 10k pullup on A11 and 1k pulldown on A12 works as a workaround.

The R6581 software and character mapping works for the R6243, though after playing around some, I've noticed a few missing characters (like the "x" character in the lower line).

[IanJ]

Nice work getting this working with the R6243, I wonder what other Advantest instruments would work!

For the "x" being incorrectly displayed on the AUX line, it's possible the mapping is wrong, i.e. not used on the R6581. If this is so, then I'd need a nice close up photo of the "x" on your VFD so I can see the pixel data that make it up.....and from there I can adjust the following in the source code:

{{0x00, 0x11, 0x0A, 0x04, 0x0A, 0x11, 0x00}, 'x'},  // 0x78, x

If you want to update the source and compile a new HEX file yourself then the hex above is the binary equivalent of each row of the character top to bottom, so 7 rows.

UPDATE: Are all the annunciators the same on the R6243, if the text is different left to right I can amend?

Ian.

[z01z]

Thanks for the tip Ian, managed to fix a few chars. I don't have VS but with a little work made the project build in the STM32CubeIDE.
The 'x' and 'q' have different bitmaps, so I duplicated the original lines  (I suppose having 2 extra bitmaps to check is not a big deal, it only takes a bit more time)
   {{0x00, 0x00, 0x0F, 0x11, 0x0F, 0x01, 0x01}, 'q'},  // 0x71, q
   {{0x00, 0x00, 0x11, 0x0A, 0x04, 0x0A, 0x11}, 'x'},  // 0x78, x
The '[' and ']' were empty, so I simply entered the bitmap there
   {{0x0E, 0x08, 0x08, 0x08, 0x08, 0x08, 0x0E}, '['},  // 0x5B, [
   {{0x0E, 0x02, 0x02, 0x02, 0x02, 0x02, 0x0E}, ']'},  // 0x5D, ]

There are 2 chars still to go, any idea what to do with them? At the worst case they could be mapped to an existing char, like the right arrow for the aux char.
   {{0x10, 0x10, 0x14, 0x12, 0x1F, 0x02, 0x04}, '??'},  // 0x??, ??
   {{0x00, 0x04, 0x0E, 0x1F, 0x0E, 0x04, 0x00}, '??'},  // 0x??, ??

I believe the same VFD is used in the R6243, see for yourself.

[IanJ]

For the oddball characters, if you look at how I generated the ‘test’ characters I just called on existing characters from the LT7680 built in character map…….so if you download the manual for the IC you’ll be able to choose an existing character that’s closest.

If you want to generate an exact copy of the character from the VFD then you’ll have to generate it in the same way I generated the OHMS symbol…….which was a big pain to do and has a lot of pitfalls. See my code, it’s not straight forward!

Ian

[z01z]

Again, thanks for the tip, didn't notice the char tables in the pdf until now.
I'd say these are close enough for substitutes:
   {{0x10, 0x10, 0x14, 0x12, 0x1F, 0x02, 0x04}, '\x1A' },   // arrow right for R6243 menu char
   {{0x00, 0x04, 0x0E, 0x1F, 0x0E, 0x04, 0x00}, '\x04' },   // diamond for R6243 main menu char