[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.
Brief answers to your questions:
- 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!
Best Answer
The package is called "SOT-23" (small outline transistor), and it is used for all kinds of small-signal semiconductor devices, including BJTs, MOSFETs and diodes of all types (single and dual).
Since they are very tiny, only a small amount of information can be printed on them for identification. These tend to be manufacturer-specific strings of letters and digits, and tracing them back to a specific device is somewhat of a black art. There are websites that can help with this.
As Andy says, the reference designator on the board can offer some general clues about where to look.