To test serial communication you need to run both a transmitter and a receiver. For the project, I recommend that you develop and debug your code using two VirtualBoxes (VBoxes): one executing the driver in receiver mode and the other running the driver in transmitter mode. This is possible because the VBox allows to connect the (virtual) serial port of a VM to the (virtual) serial port of another VM executing on the same computer.
Assuming that you already have a VM on your laptop/PC you need only execute the following steps:
The easiest way to create a new VBox VM with Minix 3.1.8 from an existing VBox VM with Minix 3.1.8 is to first export the existing VM, and then to import it. To complete this step, you will have to change the network settings more specifically the port forwarding settings.
To export an existing VBox VM just start VBox. After that select the File->Export Appliance menu option. A window with the existing VM will pop up.
Choose the VM you want to export and press the Next button.
On the new window in the popup, select the name of the file to be created with the exported VM and press the Next button again.
Finally, before clicking on the Export button I suggest that you change the name of the VM.
The export of the appliance may take several tens of seconds, as it has to read and to write from/to disk several hundreds of MBs.
The procedure to import the appliance just created is similar. First, select the File->Import Appliance menu option. A window with the existing VM will pop up.
Click on the folder icon and select the file with the VM you have exported in the previous section and press the Next button.
Finally, before clicking on the Import button I suggest that you change the name of the VM.
Like the export, the import of an applicance may take several tens of seconds. Once the import completes, the new VM will appear on the list of VMs available.
To complete the creation you need to change the port forwarding settings, as the new VM will have the same settings as the original. So, select the new VM:
and choose the Machine->Settings menu option. A new window will be displayed:
Next select the Network option on the left list:
Press the Advanced "button" and then the Port Forwarding button. A new window with the settings of the original VM is shown:
On this window, change the Host Port field to a different value, e.g. 3022 (on Unix-like OSs you must type a value larger than 1024) and then press the OK button. Finally, press the OK button of the Network Settings window, to complete this step.
The second and last step is to configure the serial ports of the two VMs, so that they become connected to one another via the serial ports. The process is essentially the same for both VMs.
Again, select the VM you want to configure and then select the Machine->Settings menu option. The following window will be displayed:
This time, choose the Serial Ports entry on the left list, and the window should change to:
In this window, check the Enable Serial Port box and in the Port Mode: list choose the Host Pipe option. Next, in the the Path/Address box type a file name in the /tmp directory, e.g. /tmp/vm_com (this is specific to Unix-like OSs)
and press the OK button.
To configure the serial port of the second VM you should follow the same steps as above, however in the window for configuration of the serial port you should also check the Connect to existing pipe/socket box:
IMP- Note that the file name typed in the Path/Address box should be the one you typed when you configured the serial port of the first VM.
These steps will add the first serial port to both VMs, i.e. COM1, and virtually connect these serial ports through the configured pipe (actually, a FIFO in Unix-parlance). Your code will be able to access its UART as described in the lectures.
IMP.- Note that the second VM will fail to start, if the first VM is not running already. This is because the pipe to which it should connect the virtual serial port is created/destroyed by the first VM, and therefore exists only while that VM is running.
Testing applications that consist of more than one process is always hard. In this case, you have to develop and test both the receiver and the transmitter functionality. However, to test the receiver you need a transmitter, preferably debugged. Likewise, to test the transmitter you need a receiver, preferably debugged.
The real problem is to have one side of the communication debugged. After that, you can test and debug the other side of the communication, independently of whether it uses polling, interrupts or any of these with FIFOs. The implementations on the two ends do not need to be equal to inter-operate. In principle, all you need is to use the same communication parameters on both sides.
In many operating systems, there are small utility programs that are able to use the serial port for basic tasks and they can be used to test each of the communication sides, one at a time. Unfortunately, I do not know of any Minix 3 utility with that capability. Therefore, to make your task easier I provide one. By executing it without any arguments you'll get a "usage message", as follows:
lab7: Usage: one of the following:
service run /home/lcom/lab7/lab7 -args "conf 1|2"
service run /home/lcom/lab7/lab7 -args "set 1|2 <bits> <stop> even|odd|none <rate>"
service run /home/lcom/lab7/lab7 -args "com 1|2 tx|rx <bits> <stop> even|odd|none <rate> <string>*"
Where the arguments have the following meaning:
conf|set|com, specifies what the program should do: show the configuration, change the configuration or send/receive data, respectively.1|2 specifies the serial port, 1 for COM1 and 2 for COM2, on which to operate<bits> and <stop> specify the number of bits per char and the number of stop bits, respectivelyeven|odd|none specifies the kind of parity<rate> specifies the bit rate (please use one of the "standard" values: 1200, 2400, 4800, 9600, 19200, 38400, 57600 or 115200)tx|rx is used only for communication, and specifies whether the program should send or receive chars, respectively<string>* is a sequence of strings to be sent, it need be provided only when the program is invoked to play the role of sender. Please note that the implementation of service imposes a limit on the number of strings that you can provide. (The total number of args passed to service must be less than 15.)If you wish, you can play with this program. Make sure that the VMs are properly set, as described above, and that both serial ports are enabled. For testing communication, please start the receiver on one VM, and only afterwards start the transmitter on the other.
IMP lab7 sends a dot ('.') as a message terminator. Therefore, your strings should not include that character, otherwise the receiver will ignore the characters that follow the first dot.