How To Use Virtual Terminal in Proteus ISIS

Hello friends! In this tutorial, we will learn how to use Virtual Terminal in Proteus ISIS to inspect serial data and send simple commands to a simulated circuit. It is particularly useful when working with microcontrollers, GSM modules, GPS receivers, and other devices whose behavior can be understood through a serial interface.

We will begin with the simplest arrangement: a simulated microcontroller communicating directly with Virtual Terminal. Then we will return to the original article's COMPIM example, which connects a simulation to a real computer serial port. Keeping those two arrangements separate will help you choose the correct components and avoid unnecessary COM-port problems.

The aim is to make serial communication visible before building a larger application around it. We will cover connections, terminal settings, a small PIC example, baud-rate calculations, and a practical debugging sequence. If you need background first, read What Is a Serial Port?.

What Is Virtual Terminal?

Virtual Terminal is a Proteus instrument that displays received serial characters and can transmit keyboard input. It lets us observe the data exchanged by a simulated circuit without first writing a desktop user interface. The terminal window is therefore a debugging tool as well as a convenient output display.

A serial interface is not necessarily a nine-pin connector. A microcontroller's UART commonly appears as logic-level transmit and receive signals, while a traditional PC RS-232 port uses a different electrical interface. A USB-to-UART adapter is another possibility. The data format and the electrical connection must both be appropriate for the devices involved.

For a purely simulated UART connection, you do not need a physical COM port or a USB adapter. Proteus calculates the signals inside the circuit and the virtual instrument displays the result. Labcenter includes this instrument in its virtual-instrument collection.

Virtual Terminal and COMPIM Have Different Jobs

The original tutorial concentrated on the third row. That is useful, but it can make beginners think that COMPIM is mandatory whenever they need text output. Start with the first arrangement when both the processor and terminal are simulated. Add the host-port connection only when the project actually needs to cross that boundary.

A successful terminal message proves that the tested communication path delivered that message under those conditions. It does not prove that every part of the hardware or firmware is correct. Use it as evidence for one stage of the system, then test the remaining stages separately.

Add Virtual Terminal to the Schematic

Open the virtual-instruments mode in the schematic editor and select Virtual Terminal. Place it near the UART signals you want to observe. The preserved screenshot shows the original instrument-selection workflow; icon positions can differ between Proteus versions.

Open the terminal's properties and establish a simple initial format. For the examples here, use 9600 baud, eight data bits, no parity, and one stop bit, commonly written as 9600 8N1. Use the normal, non-inverted signal convention for a direct logic-level UART connection.

If the selected component has optional flow-control signals, do not connect them arbitrarily. Our basic microcontroller example uses transmit, receive, and the circuit's common reference without hardware handshaking. A different protocol may require additional signals, but that requirement should come from the connected device's documentation.

Connect a Simulated PIC to the Terminal

We will use PIC18F452 to continue the earlier LCD tutorial's device choice. Its hardware USART transmit signal is RC6/TX, and its receive signal is RC7/RX. Check the selected device's datasheet when using another PIC rather than assuming every family has the same pin assignment.

For a transmit-only test, the first signal connection is sufficient for data display. Add the return connection when you want to test reception. The general principle is that an output drives an input. Two transmit outputs connected together do not form a normal two-way UART link.

Provide the PIC's supply, reset, and clock configuration as required by its simulation model. Select the same device and clock in the compiler. A correctly wired terminal cannot display a startup message if the microcontroller never begins executing its program.

A Small mikroC Serial Example

Create a mikroC PRO for PIC project for PIC18F452 with a 16 MHz clock. Enable its UART library, configure the device for the intended oscillator, and disable the watchdog for this basic demonstration. The following program sends one startup line and then echoes received characters.

char received;

void main()
{
    UART1_Init(9600);
    Delay_ms(100);
    UART1_Write_Text("TEP serial test\r\n");

    while (1) {
        if (UART1_Data_Ready()) {
            received = UART1_Read();
            UART1_Write(received);
        }
    }
}

The mikroC UART library reference documents these routines. Initialization precedes all communication, and the program checks for a received byte before reading it. The example is deliberately small so that its observed behavior can be explained without a larger application.

Build the project, load the resulting HEX file into the simulated PIC, and set its clock to 16 MHz. Start the simulation. The terminal should show the startup line. Click inside the terminal input area and type a character; the PIC should send that character back.

If local echo is enabled in the terminal, a typed character may appear before the PIC returns it, and it may appear twice when the echo comes back. Disable local echo while testing the firmware echo path. Seeing a locally displayed character alone does not prove that the receiving program processed it.

Understand the Serial Settings

Both ends of the link must agree on the frame format and operate at compatible bit rates. A setting such as 9600 8N1 means 9600 bits per second, eight data bits, no parity bit, and one stop bit. The start bit is part of the frame even though it is not included in that shorthand.

For this format, each data byte occupies ten transmitted bits: one start bit, eight data bits, and one stop bit. The approximate time per character is:

character time = 10 / 9600 = 0.0010417 s ≈ 1.04 ms

The theoretical data-byte rate is therefore 9600 / 10 = 960 bytes per second, before considering application pauses and other overhead. Baud rate is not the same thing as useful characters per second. A forty-character message requires roughly 41.7 ms of serial line time in this format.

Check the Microcontroller Clock

The UART rate is derived from the processor clock and a divider. For the PIC18F452's asynchronous high-speed mode, the relevant relationship is baud = Fosc / (16 × (SPBRG + 1)). At 16 MHz with SPBRG equal to 103, the actual rate is approximately 9615.4 baud.

The error relative to a 9600-baud target is approximately (9615.4 − 9600) / 9600 × 100 = 0.16 percent. This is an example calculation for that device and mode; other devices use different divider arrangements. The compiler library chooses its configuration from the target and clock settings, which is why those settings must agree with Proteus.

Text and Binary Data Are Not Interchangeable

Sending the text “123” transmits three character codes. Sending a raw byte whose numeric value is 123 transmits one byte, which a text terminal may display as a character rather than as the digits 1, 2, and 3. Decide whether your protocol carries human-readable text or binary values before interpreting the screen.

Line endings matter too. Carriage return and line feed are control characters with different functions. The example's \r\n supplies both. A receiving program that waits for a newline can appear unresponsive if the sender never transmits the delimiter it expects.

Use COMPIM for a Real Computer Serial Port

Now let us return to the original setup. Search for COMPIM in the device picker and place it in the schematic. This interface represents the connection between the simulation and a serial port available to the host computer. It is relevant when data must reach an external device or arrive from one.

The original diagram joins COMPIM to Virtual Terminal as shown below. Its connector-style TXD and RXD naming should not be copied as a universal microcontroller wiring rule. Inspect the pin directions and the component help for the installed version: the signal emerging from the host interface must reach the terminal's receive input, and terminal output must reach the host interface's transmit path.

Open COMPIM properties and select the actual Windows serial port connected to your external hardware. The original screenshot uses COM1 at 9600 baud. Your adapter may appear as COM3, COM7, or another port, and that number can change when hardware is reconnected.

Where the COMPIM version exposes separate physical and virtual serial settings, configure each side deliberately. Physical settings must match the external serial connection, and virtual settings must match the simulated circuit. For a straightforward first test, keep both sides at the same 9600 8N1 format instead of introducing conversion at the same time.

1. Confirm that Windows detects the external serial interface.
2. Identify its assigned COM port.
3. Close other applications holding that port.
4. Configure COMPIM for the correct port and serial format.
5. Check the simulated signal directions and terminal settings.
6. Start the simulation and send a short known message.

The preserved terminal screenshot shows output from the original hardware-connected demonstration. It illustrates the display workflow, not a guarantee that any adapter or device will work with those exact settings. Start with a known source of a repeated short message so that a quiet terminal has a clear meaning.

Respect the Electrical Interface

A logic-level UART and an RS-232 connector are not electrically interchangeable. Use a suitable transceiver or correctly rated USB-to-UART adapter for the physical hardware. Check the device's operating voltage and signal tolerance before connecting it. A USB adapter's ability to provide 5 V power does not necessarily mean its logic outputs use the same voltage.

Establish the required signal reference and use the cable arrangement appropriate to the endpoints. Do not connect a raw microcontroller pin to an RS-232 signal merely because both are described as serial. The simulator's internal wires do not remove the electrical requirements of the real equipment outside it.

Debug One Direction at a Time

Begin with a transmitter that sends a fixed message. If the terminal receives it correctly, you have evidence for the transmit path, format, and receiver configuration. Then enable the return direction and send one known character. This isolates the direction that fails instead of treating a two-way link as a single unexplained problem.

For the simulated PIC example, a startup line followed by a successful character echo is a useful first check. If the startup line appears but typed characters never return, inspect the terminal TXD connection and PIC receive code. Rewriting the transmit message is unlikely to fix a missing receive wire.

If no startup line appears, verify program execution, the loaded HEX file, clock settings, and the PIC transmit signal. Use an oscilloscope or logic analyzer to see whether the line changes at all. A completely inactive line suggests a different problem from a line carrying incorrectly timed bits.

Reopen a Hidden Terminal Window

If the simulation is running but the terminal window is hidden, use the instrument's context menu or the version's instrument/debug-window controls to show it again. The original version offered a Virtual Terminal entry from the component's context menu. Closing the display window is not the same as deleting the instrument from the circuit.

Check whether the simulation is paused before interpreting a lack of new output. Simulated time and real computer time are different concepts, particularly when a demanding circuit runs slowly. Host-connected communication introduces real external timing as well, so verify that your chosen simulation setup can handle the intended data rate.

Use the Terminal Before Building a Larger Application

The original purpose of this tutorial was to separate communication debugging from desktop application debugging. That remains a useful approach. Establish a simple message exchange first, then add parsing, graphs, database storage, or a custom user interface.

Our guides to serial communication in MATLAB and serial communication in Visual Studio 2010 show related software workflows. When adapting them, keep the same message format and line-ending rules that you tested at the terminal.

The technique also applies to other PIC projects and 8051 projects. For a specific example, see 8051 serial communication in Proteus. The pin names and baud-rate configuration change, but the method of checking one link at a time remains useful across embedded-system projects.

Review and Frequently Asked Questions

When replacing the byte-echo example with a command parser, define a maximum message length and a clear delimiter. Reject an overlong message instead of continuing to write beyond its buffer. Also define what happens when only half a message arrives. A terminal can send a command slowly, but firmware must still distinguish an incomplete command from a complete one. Test empty lines, unknown commands, and repeated delimiters before connecting the parser to an output that changes the circuit's behavior.

We have used Virtual Terminal as a direct simulated UART endpoint and explained the separate COMPIM workflow for a host serial port. The next useful instrument is the Proteus oscilloscope, which lets us inspect the waveform behind the displayed characters.

Do I need a physical serial cable for the PIC example?

No. Both the PIC and terminal are simulated. A cable or adapter is needed only when your test includes physical hardware outside the simulation.

Why does the terminal not display a number I sent?

Check whether the firmware sent decimal text or a raw binary byte. A text terminal displays character codes; it does not automatically format every received byte as a decimal number.

Can I use a different baud rate?

Yes, if the selected device, clock, model, and endpoints support it. Configure both ends consistently and assess the actual generated baud rate instead of assuming every requested rate is exact.

Does a correct received message prove that my full project works?

It confirms that particular data exchange under the tested conditions. Power behavior, sensor accuracy, application parsing, and other functions still need their own checks.

Why does closing Serial Monitor help COMPIM connect?

The host serial port may already be open in that application. Release it before allowing another program to use it, and check that both applications were referring to the intended device.