Code:

If led = "0" Then send$ = Chr$(3) + Chr$(0) + Chr$(0) + Chr$(3): GoTo prikaz
If led = "1" Then send$ = Chr$(3) + Chr$(1) + Chr$(1) + Chr$(3): GoTo prikaz
If led = "2" Then send$ = Chr$(3) + Chr$(1) + Chr$(2) + Chr$(0): GoTo prikaz
If led = "3" Then send$ = Chr$(3) + Chr$(1) + Chr$(4) + Chr$(6): GoTo prikaz
If led = "4" Then send$ = Chr$(3) + Chr$(1) + Chr$(8) + Chr$(10): GoTo prikaz
If led = "5" Then send$ = Chr$(3) + Chr$(1) + Chr$(16) + Chr$(18): GoTo prikaz
If led = "6" Then send$ = Chr$(3) + Chr$(1) + Chr$(32) + Chr$(34): GoTo prikaz
If led = "7" Then send$ = Chr$(3) + Chr$(1) + Chr$(64) + Chr$(66): GoTo prikaz
If led = "8" Then send$ = Chr$(3) + Chr$(1) + Chr$(128) + Chr$(130): GoTo prikaz
prikaz:
MSComm1.Output = send$

Code:


CLS: CLEAR
DIM inbuf(800)
DIM outbuf(8)
OPEN "com2:19200,n,8,1,bin,cs,ds" FOR RANDOM AS #1

'----- INTERRUPT SERIAL INTERFACE ON -----
COM(2) ON
ON ERROR GOTO BADCOM
ON COM(2) GOSUB GETFRAME

'----- INITIALIZE RELAIS BOARD -----
PRINT "INITIALIZE BOARD"
outbuf(0) = 1: outbuf(1) = 1: outbuf(2) = 0: GOSUB sendframe
FOR delay = 1 TO 1000000: NEXT: CLS

'----- SWITCH RELAIS -----
teststart:
r = 1
rt:
outbuf(0) = 3: outbuf(1) = 1: outbuf(2) = r: GOSUB sendframe
FOR delay = 1 TO 1000000: NEXT: CLS
r = r * 2: IF r < 256 THEN GOTO rt
GOTO teststart

'||||| SERIAL COMMUNICATION |||||
'---------------------------------
'----- READ 4 BYTE DATAFRAME -----
'---------------------------------
GETFRAME:
inbuf(bz) = ASC(INPUT$(1,#1))
bz = bz + 1
IF bz = 4 THEN GOTO checkframe
RETURN
'----- CHECK VALIDITY -----
checkframe:
ERROR$ = "ERROR"
IF inbuf(0) XOR inbuf(1) XOR inbuf(2) = inbuf(3) THEN
ERROR$ = "OK"
bz = 0: PRINT "RECEIVED:"; "  "; inbuf(0); "  "; inbuf(1); "  "; inbuf(2); "  "; inbuf(3); "  "; ERROR$
PRINT "-----------------------------------------------------------------": RETURN
END IF
'---------------------------------
'----- SEND 4 BYTE DATAFRAME -----
'---------------------------------
sendframe:
outbuf(3) = outbuf(0) XOR outbuf(1) XOR outbuf(2)
send$ = CHR$(outbuf(0)) + CHR$(outbuf(1)) + CHR$(outbuf(2)) + CHR$(outbuf(3))
PRINT #1, send$
PRINT "TRANSMITTED: "; "  "; outbuf(0); "  "; outbuf(1); "  "; outbuf(2); "  "; outbuf(3)
RETURN

'***** ERROR HANDLER *****
BADCOM:
PRINT "----- DATA ERROR -----"
RESUME
RETURN

ende:
END

Code:

send$ = Chr$(3) + Chr$(1) + Chr$(1) + Chr$(3) -----> pali 1. diodu
send1$ = Chr$(3) + Chr$(1) + Chr$(128) + Chr$(130) -----> pali 8. diodu
MSComm1.Output = send$
MSComm1.Output = send1$

Code:

send$ = Chr$(3) + Chr$(1) + Chr$(1) + Chr$(3)
MSComm1.Output = send$

For i = 1 To 100000000
Next i

send1$ = Chr$(3) + Chr$(1) + Chr$(128) + Chr$(130)
MSComm1.Output = send1$

Code:

send$ = Chr$(3) + Chr$(1)
MSComm1.Output = send$

Code:

send$ = Chr$(3) + Chr$(1) + Chr$(3) + Chr$(1)

---------> moze biti i send$ = Chr$(3) + Chr$(0) + Chr$(3) + Chr$(0)

Code:

send$ = "0"
MSComm1.Output = send$

Code:

128  64  32  16  8   4   2   1
 o   o   o   o   o   o   o   o

128  64  32  16  8   4   2   1
 x   o   o   o   o   o   o   x = 129

128  64  32  16  8   4   2   1
 x   x   x   x   x   x   x   x = 255

Code:

For i = 0 to 1000000
Next i

Code:

' U globalnim deklaracijama
Private Declare Function SleepEx Lib "kernel32" (ByVal dwMilliseconds As Long, ByVal bAlertable As Long) As Long
' i u programu
SleepEx 1000, False ' gde je 1000 = vreme za koje hoces da stopiras izvrsenje u milisekundama

Code:
If led = "5" Then send$ = Chr$(3) + Chr$(1) + Chr$(16) + Chr$(18): GoTo prikaz

Code:

Dim upali as byte
upali = 2 Or 4 Or 64

Code:

upali = upali XOR 4

Code:

128  64  32  16  8   4   2   1
 x   x   x   x   x   x   x   x

Code:
Communicating - the basics 

Serial communication is a heart quite a simple idea. There are three pins that are important. Data is transmitted over one pin (Transmit Data or TXD for short) and received over another pin (Receive Data or RXD). The data is sent sequentially as a series of on-off pulses down the wire, so a byte will take eight bits or pulses to transmit. In fact, there are one or two other bits needed as well for synchronisation and error checking, but that’s the basics. The third wire that’s needed is the Ground wire (GND) – these are electrical signals and so need a return path. While you can get away with just three wires, it’s often useful to have other control signals to make things easier for the software. There are six other signals: Ring Indicator (RI) is set by a modem when it detects an incoming call. Carrier Detect (CD) is again set by the modem when it detects another modem as the originator of the incoming call. For a null-modem, RI and CD can are ignored.

This leaves four other signals which come in pairs. Request To Send (RTS) and Clear To Send (CTS) are used by the PC to signal that it is ready to write or read data respectively. Data Terminal Ready (DTR) and Data Set Ready (DSR) do a similar sort of job (there are actually finer details of what these signals should be used for – but that needn’t bother us here). So for our null-modem purposes there are three pairs of wires – and these need to be ‘crossed over’ for the two ports to communicate. That is, the RCD pin of one port must be connected to the TXD pin of the second and so on. This means that when COM1 transmits data (on TXD) COM2 will receive data on RCD. The complete wiring between the two connectors looks like:COM1     COM2
RCD     2     TXD     3 
TXD     3     RCD     2 
DTR     4     DSR     6 
GND     5     GND     5 
DSR     6     DTR     4 
RTS     7     CTS     8 
CTS     8     RTS     7 


If you’re confident with a soldering iron you can get the parts separately and wire them up or if you’d rather leave it to an expert, get a ready made cable – though check out the type of ports of the back of your PC first. Older PCs tend to have one 25 pin port and one 9 pin port – all of the above wiring refers to the more modern 9-pin varieties.

OK, so assuming you’re equipped with a suitable null-modem cable and you’ve plugged it into the two ports what next? One way to check that everything is working OK is to use two HyperTerminal sessions, one connected to COM1 the other to COM2 with exactly the same speed settings. You should be able to type from one screen to the other with no trouble. Another way (more interesting, of course!) is to use a Visual Basic program.

I’ve written a simple program using mostly the default settings of the two communication ports to illustrate how events are communicated back to Visual Basic. In the program COMMS.VBP, there are two text boxes that display the input received on the respective port and two sets of buttons that toggle DTR and RTS. There’s also an Initialize button that opens the ports and sets off a polling loop. The code initially sets COM1 and COM2 up in a similar manner with both RTS and DTR off:
With MSComm1
    .DTREnable = False
    .RTSEnable = False
    .CommPort = 1
    .PortOpen = True
End With

Once set up the program just polls for input:
Do While MSComm1.PortOpen And MSComm2.PortOpen
    s1 = MSComm1.Input
    s2 = MSComm2.Input
    If s1 <> "" Then
        Port2.Text = Port2.Text & s1
    ElseIf s2 <> "" Then
        Port1.Text = Port1.Text & s2
    Else
        DoEvents
    End If
Loop

There are two things to notice about this simple loop. First, the loop condition tests to see if the ports are still open. If you don’t do this, you will get an annoying error when you close the program. For some reason, Visual Basic seems to close the ports before unloading the form. Secondly, the DoEvents keyword ‘releases’ the program to look for other things – such as a button click or a communication event. 

In the DTR (and RTS) toggle code, you’ll see this:
With MSComm1
    .PortOpen = False
    If .DTREnable = False Then
        .DTREnable = True
    Else
        .DTREnable = False
    End If
    .PortOpen = True
End With 

These communication events (DSR corresponding to DTR and CTS corresponding to RTS) events are detected in the OnComm event code:
Private Sub MSComm1_OnComm()
   EventLog.Text = EventLog.Text & "Port1: " _
       & CommEventText(MSComm1.CommEvent) & vbCrLf
End Sub 

and just written to the EventLog window.

All this looks pretty neat and simple but there’s a ‘gotcha’: to set a control signal (say, RTS) you have to close the port, set RTS and then reopen it. This is disastrous if you are communicating with some hardware that isn’t really a modem – you can lose data in the small interval while the port is closed.

The problem is that the operating system uses these control wires to signal to the modem that your program is ready (that’s the main use of DTR) and it uses the RTS/CTS wires to implement hardware flow control. Normally, you’d be quite happy with this – but not if you want to control your patent dog-walker (or train set) directly. I’ll look at this next month.