(Caveat: I'm a programmer, not an electronics engineer.)

Edit: Fixed a misunderstanding, added better smallest possible sample code.

I'm in the process of repurposing an old device containing a 2x40 character NEC FC40X2EA-AB vacuum flourescent display, but the WR signal seems to work differently than documented.

The VFD has a driver board so power, control, and data input should be taken care of, but:

  • Serial data input works, but is limited to 9600 baud which is too slow for the intended usage.
  • Parellel data input seems to be documented, but following the instructions yield incorrect results. This is what I request help on.

I could not find a datasheet specifically for the one in my device:
FC40X2EA (2x40 characters), but I found datasheets for:
FC20X2JA (1x20 characters, very brief) and
FC20X1SA (1x20 characters, thorough) which I assume are compatible.

I have hooked up a Teensy 3.5 to the VFD controller board and I can operate most functions, but I am still having problems with parallel data input, specifically the WR signal. Here are the relevant parts from the datasheet:

FC20X1SA datasheet functions overview
FC20X1SA pg. 28

FC20X1SA datasheet data write section
FC20X1SA pg. 29

FC20X1SA timing chart
FC20X1SA pg. 36

FC20X2JA datasheet timing
FC20X2JA pg. 1

Critically, pin WR should be set "0→1" for writing data. I assume this means that I should be setting A0 to LOW to indicate I'm sending a character as opposed to a command, and I should be setting D0-D7 according to the character I intend to send. Then, I would toggle WR to LOW for a brief moment to instruct the controller board to accept this character.

What I am seeing is that, regardless of what else is going on, the display keeps continuously resetting for as long as WR is active (LOW).


// Data pins, configured to send an 'A' character
pinMode(0, OUTPUT); // Active HIGH
pinMode(1, OUTPUT); // Active HIGH
pinMode(2, OUTPUT); // Active HIGH
pinMode(3, OUTPUT); // Active HIGH
pinMode(4, OUTPUT); // Active HIGH
pinMode(5, OUTPUT); // Active HIGH
pinMode(6, OUTPUT); // Active HIGH
pinMode(7, OUTPUT); // Active HIGH
digitalWriteFast(0, HIGH);
digitalWriteFast(1, LOW);
digitalWriteFast(2, LOW);
digitalWriteFast(3, LOW);
digitalWriteFast(4, LOW);
digitalWriteFast(5, LOW);
digitalWriteFast(6, HIGH);
digitalWriteFast(7, LOW);

// Configure to send data, not command
const int pinA0 = 12;
pinMode(pinA0, OUTPUT); // Active LOW
digitalWriteFast(pinA0, HIGH);

// Briefly set WR to instruct VFD to read data
const int pinWR = 26;
pinMode(pinWR, OUTPUT); // Active LOW
digitalWriteFast(pinWR, LOW);
digitalWriteFast(pinWR, HIGH);

Here, in the 2nd to last line, I am pausing for 0.2 seconds. This is long enough to visually determine that the VFD is actually resetting -- although the datasheet says that the signal needn't be active for more than 100 nanoseconds.

I can wiggle a temporary jumper wire on the serial input pin to simulate serial data input (this creates random charactes on the display) and this also confirms that the entire display is cleared when WR is set. I am utterly confounded.

What gives? How am I misreading the datasheet; how am I supposed to send parallel data to this display?

  • \$\begingroup\$ Show us a snippet of your code where you're trying to write data to the display. Your description seems a little confused. \$\endgroup\$
    – brhans
    Commented Jan 22, 2023 at 14:46
  • \$\begingroup\$ @brhans yes of course, I have amended my post. Apologies if it seems confused; I have tried to keep it short. \$\endgroup\$
    – noughtnaut
    Commented Jan 22, 2023 at 14:59

1 Answer 1


You have your WR pin logic inverted. It should be initialized HIGH by default when you're doing nothing with it. When you want to write data to the device you should toggle it LOW and then toggle it back HIGH again almost straight away.

There are 2 sequences of operations which will work:

  1. toggle WR LOW, set the data, toggle it HIGH
  2. set the data, toggle WR LOW, then toggle it back HIGH

You need to satisfy the timing conditions in the datasheet and since you don't have one for your specific device then you should probably assume the worst-case and use the longest time periods from the datasheets you do have.

So make sure that:

  • WR stays low for no less than 100ms (from the FC20X2JA)
  • your data is valid at least 20ns before you toggle WR from LOW to HIGH (FC20X1AS)
  • your data remains valid for at least25ns after you toggle WR from LOW to HIGH (FC20X2JA)
  • \$\begingroup\$ Thank you. You're right, I had the WR signal the wrong way around. But now that I've fixed that, it merely means that the display does the flickering reset thing for the short while that the WR signal is active ... and still doesn't write the incoming text. \$\endgroup\$
    – noughtnaut
    Commented Jan 23, 2023 at 13:06
  • \$\begingroup\$ Could it be that both WR and CS should be toggled high? There is a discrepancy between the function table and the timing chart; one says CS should always be low, the other says it can be toggled ... but why would it? \$\endgroup\$
    – noughtnaut
    Commented Jan 23, 2023 at 13:09
  • \$\begingroup\$ Usually you would only need to use CS and toggle it low/high if you're sharing your parallel data bus with other devices. Each one has its own CS line tied to the MCU, and they share all the rest (A0-Ax, D0-Dx, RD, WR), so each individual CS selects the particular device you want to talk to. In your case you only have the single device, so tying CS low so permanently select it should be fine. \$\endgroup\$
    – brhans
    Commented Jan 23, 2023 at 15:23
  • \$\begingroup\$ That tracks with my understanding. But still doesn't explain the behaviour of the VFD resetting as long as WR is active (low). I've triple-checked everything else, and I know it works (slowly) using serial so I doubt the thing is broken. \$\endgroup\$
    – noughtnaut
    Commented Jan 24, 2023 at 16:34
  • \$\begingroup\$ FYI, I have reworked my solution (see edited post), but don't see any change. \$\endgroup\$
    – noughtnaut
    Commented Jan 26, 2023 at 13:08

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.