# Vacuum Fluorescent Display (VFD) serial connection ~ Debugging Questions

I am attempting to display information on a Futaba Vacuum Fluorescent Display (VFD) (apologies for the google-drive link to the datasheet. I lost the original and couldn't find it again). I'm intending on using a MSP430 to do so (though I'm not so far ahead yet).

My intent was to test the device using a serial-connection from my PC, firstly via a COM port, now via a Platronix USB RX/TX thing. However, despite having the correct baud-rate (and trying others to be sure), I keep getting garbled text on the display. Of course I've no doubt some of the experienced people here could tell me the correct way to archive this, what I'd like to know is "how can I figure out what's wrong?"

I've a tiny hobby budget of tools and not even enough for a second-hand oscilloscope, I've two (barely) decent multimeters, a Very Cheap Nonspecific USB logic-analyser from China, as well as a surprisingly decent stock of PIC, ATTiny, and MSP430 chips, opamps, etc (that I got as a "job lot") from a friend.

Every thread/tutorial/etc I see recommends either using a oscilloscope (that I don't have, and I will buy when I can afford to) or just "a logic analyser will help". Worse I can find very little information on the "SBUSY Handshake" serial communication this device uses.

Thus my question is:

• How, given my limited resources, how should I go about debugging the connection to control this device?
• Should I consider trying to build other circuits to debug this one?
• I considered trying to use the ADC of the MSP to make a "ghetto" USB oscilloscope
• Can my PC (with several RS232 ports, that is very powerful by enthusiast standards) be of any help to me?
• Should I give up without better tools?
• What should I look for with my logic analyser?
• Is watching the RX and TX line enough? Should I look on the VFD module itself?
• Is there anything "obvious" in the "SBUSY handshake" the datasheet describes that I have missed?
• Am I trying to do particle physics using a stone-club and a burning twig?

Apologies if this is somehow a duplicate ~ All the similar questions seem to be more along the lines of "show me how to do this thing." Which doesn't sit well with myself, I would much rather a "show me how best to approach debugging".

I've years in hardware-level C/C++ development, but mostly though PC architecture (rarely does one need to set their own registers and such). And for the last year I've been broadening my horizons with EE - I'm not afraid of hard work, or hard learning (you don't spend years programming C++ if you are). I want to understand what I'm doing properly, and I do appreciate not having the best tools isn't going to do me any favours, however giving up until some point down the road doesn't do it for me. Nor does plug & play shield-things.

I apologise for the generality of this question, unfortunately I don't know where else to go, or how better to phrase it.

• Isn't the SBUSY handshaking equivalent to "hardware" handshaking? Also, do you ever get valid text, or is it always garbled? Have you ensured your parity bit, start/stop bits, and data length are set correctly also? You know, it might be easier to bit-bang this protocol through a hobby mcu (i.e. Arduino) which will allow you to output exactly the waveforms specified, and also watch for the SBUSY flag, unless you can use the SBUSY pin as hardware handshaking or busy pin in standard serial interface. – Ryan Griggs May 13 '16 at 2:20
• Funny: when I first read the question title, I was thinking VFD = Variable Frequency Drive. LOL – Ryan Griggs May 13 '16 at 2:20
• @RyanGriggs There is indeed a start and stop bit, according to the datasheet 8bit data in-between. I'm going to take a moment to google "bit-bang", learning is fun! – John Bargman May 13 '16 at 12:18
• Bit-banging = using software to simulate a protocol which is normally done in hardware or dedicated subsystems. – Ryan Griggs May 13 '16 at 13:59

[This is a bit of a "brain dump", but I have limited time to try shortening it at the moment.]

My intent was to test the device using a serial-connection from my PC, firstly via a COM port

Go back to that. The VFD datasheet clearly shows it is designed for an RS-232 (or for younger readers, TIA/EIA-232 :-) ) $\small{SIN}$ signal. Standard 8-N-1 format, so you can set that on Hyperterm / Putty or whatever terminal software you want to use on the PC.

now via a Platronix USB RX/TX thing

I couldn't find anything with that name via a quick Google search (so please provide a link). However few of the typical USB-to-serial adapters have an RS-232 output; instead they are usually some kind of logic level output (sometimes called TTL output). Don't use that now, for reasons I'll try to explain briefly.

The VFD datasheet is potentially confusing:

It shows $\small{SIN}$ signal with $\small0$ and $\small1$ opposite to how we typically expect them. I think they are showing the RS-232 signals how you would see them on an oscilloscope, where the idle state of RS-232 data line is low in voltage (measured at the receiver, that's usually between -3 and -15 volts), but this voltage indicates a logic 1 for each bit in that state within the byte.

I can explain more about the $\small{SIN}$ signal shown on the datasheet, if needed. However in short, everything is telling me to use RS-232 for that input.

You also need to have a common 0V reference (i.e. connection) between your PC and the VFD power supply.

The $\small{SBUSY}$ signal is different:

It can only switch between the VFD module V$\small_{CC}$ (nominal +5V) and Gnd (i.e. 0V). However 0V is not a valid RS-232 voltage. So to use that as a hardware handshake signal back to the PC would require you to add a suitable interface IC. Instead, just for your testing with the PC, I would use some other indicator for the $\small{SBUSY}$ signal.

I remember reading that some of those cheap logic analysers can have unexpected problems with 5V input signals. Therefore, at least to start, I would use one of your multimeters to measure the idle voltage of $\small{SBUSY}$. Since that isn't a valid RS-232 output, I don't want to guess what the datasheet diagram is showing for the idle $\small{SBUSY}$ voltage, but for this discussion. let's assume it is 0V when idle.

As each character is sent from your PC to $\small{SIN}$, you would expect to see a small "blip" on your multimeter (the measured voltage is not important - we know it is 5V, if it stayed stable for long enough for your meter to display that). You can only send 1 character at a time to the VFD, expect to see a small "blip" on the meter, then you can send another character.

It will be interesting to verify that you see a "blip" on the meter, the approximate duration of that "blip", and the idle voltage on $\small{SBUSY}$.

Of course you could replace the multimeter in that experiment with an LED+resistor combination. However for short pulses, I suspect that the meter may give a more visible indication than a very short pulse on an LED. If your logic analyser was known to be usable on 5V signals without an excessive loading, then of course, you would use that - but I can't confirm anything about your analyser.

• How, given my limited resources, how should I go about debugging the connection to control this device?

I vote for - get it working via the PC, then move forwards, given that the VFD is intended to receive an RS-232 signal on $\small{SIN}$. For your final project using an MSP430, you will either need to generate an RS-232 output or else use the VFD's parallel interface.

The non RS-232 $\small{SBUSY}$ is a fly in the ointment, when connecting to a PC, however :-(

• Should I consider trying to build other circuits to debug this one?
• I considered trying to use the ADC of the MSP to make a "ghetto" USB oscilloscope

You could do that, but I am not convinced that doing so, and then having to debug that, will be a "net win" overall. However do keep an oscilloscope on your "to buy" list. It was the first piece of equipment that I bought as a teenager, and I still have it in storage - can't bear to give it away (an old 10MHz Hameg). As you are seeing, without one, troubleshooting gets harder.

• Can my PC (with several RS232 ports, that is very powerful by enthusiast standards) be of any help to me?

As I explained, the RS-232 port can be useful, I believe. I have read about software to make a PC soundcard into a (very limited) oscilloscope, but it's AC-coupled only and would be of limited use here.

• Should I give up without better tools?

It depends how you get on with some initial troubleshooting, as I have suggested e.g. using your PC to send the commands to the VFD. I would not give up yet, but as I mentioned, the lack of a 'scope, is making this much harder.

• What should I look for with my logic analyser?

First, you have to get confident in that logic analyser, and (as with any test equipment) find its limitations. The lack of documentation will hamper your efforts here too :-( If you know that it can be used for 5V signals without excessive loading (which was my memory of an article I read some time ago), then by all means use it to monitor $\small{SBUSY}$. However the multimeter will be better to confirm the idle voltage of that signal.

• Is watching the RX and TX line enough? Should I look on the VFD module itself?

There is no data signal out of the VFD, so (depending on whether you meant Rx/Tx from or to the VFD module) you only need to consider one of those two signals - PC-to-VFD. Do you need to monitor it? If you had a 'scope, then yes. You must not connect an RS-232 signal directly to that analyser.

So without a 'scope, you could construct an RS-232 to logic level interface (e.g. based on one of the new members of the MAX232 family like the MAX3232) and feed that to the analyser.

It is impossible to predict whether it is worth you building that now, or waiting until you have specific test results where you can only get the answer with that. And again, after building that, you need to test it and get confidence in that home-brew test equipment, otherwise it just adds extra variables and potential sources of bugs. :-(

• Is there anything "obvious" in the "SBUSY handshake" the datasheet describes that I have missed?

The $\small{SBUSY}$ handshake looks very simple. If that signal were at RS-232 levels, it would be connected to the $\small{CTS}$ pin on the PC's serial port, and you would then enable "hardware handshaking" in your terminal software but that then creates other tasks e.g. you will likely need to also connect DTR to DSR on the PC, when you enable hardware handshaking.

Since your final objective is to use an MSP430 and not a PC to drive the VFD module, I didn't suggest putting too much effort into the PC-related testing and hence I didn't detail all the steps to interface $\small{SBUSY}$ to the PC. However this is certainly possible.

• Am I trying to do particle physics using a stone-club and a burning twig?

A little :-) There are many steps ahead of you, and the troubleshooting plan may need to be adapted at any step, depending on what happens in the previous step. Therefore it is not possible to produce a full "troubleshooting tree" at the beginning, which takes account of all possible results which could occur.

The lack of the 'scope adds uncertainty, and the logic analyser does not replace some of the facilities that a 'scope provides. You might be able to do this project without having a 'scope, depending on what results you get at each stage - although I wouldn't want to do this without a 'scope, as troubleshooting would be so inefficient for some types of problems.

Hope that helps - good luck!

• This is exactly the kind of comprehensive answer I was hoping for, you've given me lots of information (and things to learn about). Thank you so much :) – John Bargman May 14 '16 at 14:41
• @JohnBargman - You're very welcome :) I just noticed that there is a related EE.SE topic which seems relevant: electronics.stackexchange.com/questions/203394/… It's a similar VFD model number & some details are unclear (e.g. they seem to have been trying a logic-level serial connection, which may explain their failure with that). However they apparently succeeded when using the parallel interface to the VFD - that could be your "plan B", although the VFD would need logic-level conversion from your MSP430's 3.3V I/Os. HTH :) – SamGibson May 14 '16 at 22:02
• I managed to get the device working with my RS232 port yesterday thanks to your advice. I'll take an in depth look at that topic as well. Thank you again :) – John Bargman May 16 '16 at 13:04