Introduction

The purpose of this program

This is a testprogram for the RS232 interface.

When you connect a null modem cable to another computer or make a connection with a microcontroller-board with a RS232 connector, you can test the connection and exchange data.

When a PC is connected to a microcontroller, a robot for instance,then the big problem is: what is happening between the two? At a very basic level you can inspect the RS232-buffer in the PC to see what the robot did send to the computer. Every byte will be visible. Furthermore it is possible to send small commands - as bytelists - to the robot to let him do something like making a sound or putting a led on. These things were the reason for making this program.

It does not matter how you program the microcontroller or which language you use there - C, Bascom or whatever - if sending bytes to the microcomputer is possible, you are in business.

But perhaps the most important thing is to make it possible for Visual Prolog to communicate directly with a robot. If it is your goal to let the robot do smart things by using Visual Prolog doiing the hard work then here is your chance. For that purpose you can use the packages from this program.

Userinstructions

Setting up the hardware

For computers to be connected you need a nullmodem cable. There is no "standard" nullmodemcable. I used three wires: pin 2 and 3 crossed and pin 5 (ground ) on DB9 connectors. That's all. It will be clear that there is no hardware handshaking in such case.

For connecting to a robot a normal RS232cable is enough.

How to start up?

After compiling the program choose a communication port with Start from the menu. The program displays the comports it can find in the registry.

What you see then is the status of the communication port. At this particular moment no initialisation has taken place by this program. What you see is exactly what Windows or some communicationprogram has left behind. The reason for this will be clear in a moment.

When the program starts up it reads out all the communication parameters and preserves them in an internal database. It is this database you see. You find all facts in the tabcontrol under parameters. But it is not possible to change them there. This database can be saved and loaded. To really understand the content you have to study all about communication resources in the platformSDK for Windows.

Do not expect that you already can communicate with another apparatus.

How to make the connection work?

Let us presume that two computers are connected with a nullcable and that you started up as described above. There is no garantee that the communication parameters on both machines are the same, even if you do not see that at first glance.

There are two ways to initialize the connection:

Go to the tabcontrol and choose parameters. Press the open-button and you should find a file called "startup.dcp". Load it. Repeat this on the second computer. The parameters on both machines should now be the same. You may change baudrate, parity, stopbits and databits. Selecting another value in a listbox is enough. Now you can try to send or receive data. There is a good chance that you will succeed. If it does not work you first have to prove that the hardware connection is ok.
Find a (freeware) program that works with the connection you have. Let this program do its work and then close it. If you are lucky it did not reset its parameters. Now load this testprogram and cross you fingers. You will find what the former program left behind. Lo and behold! You will see that this program works with the data it found. Go to the tab-control and choose parameters. Save the facts under a well-chosen name. The next time you start up this testprogram, you can directly open and load this file and your computer is initialized.

If none of this methods work you are on your own.

If you connect a computer to a microcontroller-board (say a robot) then consider the computer as master and the robot as slave. Therefore you should initialize this program first. The code on the microcontroller-side is your own responsibility.

Editing data

Choose text- or decimal/hexadecimal notation.
In textnotation type a normal text.

Hello world

"Hello world"

Decimal and hexadecimal notation may be used in one rule. The hexadecimal notation follows the Visual Prolog convention.
Numbers must be separated by one ore more blanks. A number represents a bytevalue. All values from 0 to 255 (hex.: 0x00 to 0xFF) are allowed.
An example is for instance:

54 67 0 0xFF 255 0x0A

Sending data

After you have typed something in the editfield: push the sendbutton.
If you for instance wrote

 Hello world

then the messagewindow will produce in binary-hexadecimal notation

 $[48,65,6C,6C,6F,20,77,6F,72,6C,64]

You will notice that the unicodecharacters are converted to bytevalues.
If you used decimal/hexadecimal notation is and typed

54 67 0 0xFF 255 0x0A

you will read this in the messagewindow

$[36,43,00,FF,FF,0A]

Receiving data

If another device sends data to your computer you will not see anything at first. When you push the readbutton the program reads the buffer and writes a number of bytes to the messagewindow in the same binary-representation as above. You can change the number of bytes that will be read from the buffer each time you push the readbutton. If you see only zero's like

$[00,00,00,00,00,00]

then the buffer is empty.

Do not send an uninterrupted stream of bytes to this program here. Let the robot send just a block of bytes. If you send continuously, the buffer gets overloaded and you can not see anymore what is coming in. It will be clear now, that there is no protocol.

Instructions for the developer

I am happy to say that the code now works in the commercial as well as in the personal edition of Visual Prolog. The reason is that the personal edition now also has the package for multithreading, which is needed by this program.

Preparations

Depending on what you want to do, you have the following choices

If you only want to use this program-code as it is you have to consider the following: This program uses native Windows-API functions which are not included in Visual Prolog and therefore this program needs Kernel32.lib. I can not provide this Kernel32.lib here.
You will have to download the Platform SDK documentation from MSDN. The Kernel32.lib is included there. Besides: all the documentation about the API-functions can be found in the SDK. I still use the kernel32.lib from WindowsXP SP2 which also works on Windows 7 and Windows 8.1.Do not forget to include the kernel32.lib into this program.
Please copy this help file into the exe folder of this program if it is not already there.
If you want to add some code yourself then the easiest way is to leave the program as it is and add your code. This has the advantage that all the routines you need are present from the beginning.
If you want to use these routines in a new program of your own and write a userinterface yourself then you need these packages: Bits, comres_api, InternalDatabase and serialports. Copy them into you own program together with Kernel32.lib and go ahead.

Writing your own code

May be the following may help you a little.
RS232-ports are implemented as objects in this program.

In package serialports you find the needed predicates. First use serialport.cl to find the available ports with getSerialPortNames()/1 and then construct one with new()/1.

In the package Testing there is a class UserInterfaceRS232 which demonstrates how you can use the interface_predicates in serial.i.
In UserInterfaceRS232.pro comdevice contains the objectpointer for the RS232 port.If you search for comdevice in UserInterfaceRS232.pro you will quickly find a lot of examples.
Important are of course the predicates for clearing buffers, reading from and writing to a buffer, setting the parameters for baudrate, stopbits, parity and databits.

Package Examples is about using events. Waiting for an incomming character is demonstrated twice.

Testing

I sometimes use an evaluationversion of "Docklight". It can momentarily be found at Docklight. Another program I used was Tera Term. Both programs do not show the RS232-buffer, but you can at least see what they are sending.

Besides that I tested on a small microcontrollerboard build by a friend to send and receive data. In fact this last project was the reason for developping this packages. Later on I used an Atmel STK500 developmentboard without difficulties.

General remarks

stopbits 1.5 may give an runtime error. I never use it and have not considered it as a big problem.

Have fun!

Ben Hooijenga

last version 03-10-2014 15.25