Written by Ian and Tom on Tuesday 09/01/07
So you have made a digital product of some sort, tested the power supply and basic hardware, and now it time to put some code into it. The easiest and most standard method to get debug information from a digital board is via the RS232 serial port. For an in-depth look at this try here or here. Any micro worth it salt will have a serial port, but if not it is an easy task to bit bash a couple of IO pins. Most of our digital boards had an FPGA on them so we even implemented serial functionality with them using a 9-bit shift register. There are such designs you can download from the web.
Note the RS232 standard uses a +12v and -12v signaling scheme (logic 1 is -12v and logic 0 is +12v). You can buy single chips for a dollar or so to convert 3.3v logic to these levels (you just add 5 small capacitors). Most of these chips use the "232" designator. One example is the MAX2323.
However if you are just going to send data to the PC and not receive it, you can write a 3.3v logic pin direct to the PC serial port Rx pin. The PC will pick up the signaling - but remember to reverse the logic in the micro/FPGA. Most important is NOT to wire to the PC Tx pin to the micro/FPGA in any way: the 12 volt drive voltage can easily burn out I/O pins on a 3.3v device.
To convey the information to the PC is achieved via a null modem cable and a terminal application on the PC monitoring
the digital board.
A null modem cable has the Tx/Rx lines crossed over and you don't need to worry about flow control, but the data carry detect and so on most probably must be looped back on the PC end.
To build a null modem is child's play follow these step by step instructions.
Our favorite terminal application for Windows is Teraterm. It can be downloaded from here. It has all the common features send/receive files, select modem types etc. It has one big bug which we discovered the hard way. While testing a USB to serial chip we wanted to crank the throughput up to 460.8kbits/s but the data was only trickling through. All was revealed when we probed the Tx line the 8 bit word would be transmitted at the set baud rate but the time between words was huge. We could not fix it. In the end we plugged the digital board into a Linux box and used Minicom.... no worries. Still a very useful application.
Minicom on Linux has absolutely everything you need - but the user interface is a little outdated. It's wrong to say "no frills" because it really can do everything, as long as you are happy with the command line.
Windows hyperterminal is definitely something to be avoided. It has given us no end of trouble over the years. One of the worst "features" is the delay in asserting the flow control CTS (clear to send). Given a multi-gigaHertz processor you would expect it can toggle this line fast enough, but the layers of bloatware operating system slow it down so much that at 115.2kbits/s (and above) it just can't keep up.
Bit bashing I/O pins.
A full description can be found here. But the essences is that you use a small code fragment to take an I/O pin high or low as per the data to be sent.
A handy subroutine takes in characters, and toggles the I/O pins just right to output the correct serial data.
We found it very useful for our digital boards upon power up and after POST to spit out the software version number, this made it easy to ensure that all digital boards were singing from the same book!