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.
Best Answer
[This is a bit of a "brain dump", but I have limited time to try shortening it at the moment.]
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.
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.
Brief answers to your questions:
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 :-(
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.
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.
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.
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.
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. :-(
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.
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!