Using the RSB509B to Receive RS232 in Background

Submitted by:

Glenn Clark
VersaTech Electronics

The programs and drawings shown below are taken from the examples section of the manual.

In the previous example, you may notice that there are times when data sent to the TICkit from the PC is lost or garbled. This is not caused by a driver problem like transmission in the other direction. The cause for this problem is rooted in the fact that the rs_receive() and rs_recblock() functions are RS232 emulations. This means that there is no internal hardware dedicated to monitoring the input. The only time the pin is being monitored for RS232 input is while the function(s) is executing. Therefore, for the time that the program is dealing with a received byte, it is not listening for the next byte from the sender.

This problem can be solved in one of three ways. The first is to establish a special protocol so that the PC, or whatever device is sending to the TICkit, transmits only when the TICkit is ready. An example of such a protocol is used by the console functions and the debug program. This works well, but is often not possible when using existing designs for transmitting. Another example is to use the handshake lines in conjunction with the TICkit's receive functions. Unfortunately, very few RS232 sending devices monitor the handshake lines on a byte by byte basis. They typically assume that the receiver can take a byte or two more even after the handshake line indicates busy. The only sure way to receive an asynchronous data stream is to use dedicated receiving hardware.

Protean Logic has created the RSB509 for this purpose. This 8 pin IC works with the TICkit's receive functions, but buffers received data and only sends to the TICkit when signaled. The circuit for interfacing to the RSB509 follows. Notice that only one general purpose I/O line is used to connect to the RSB509. The TICkit sends a quick pulse out the interface pin to signal the RSB509 its readiness. The RSB509 then sends one byte if it has buffered data to send.

The program fragment for this is shown below. This is similar to the previous example except that the pulse protocol has been included for controlling the RSB509.

LIB rsb509b.lib

FUNC none main
    LOCAL byte in_count
    LOCAL byte temp_chr
    LOCAL byte in_array[ 10b ]
    LOCAL byte in_err
BEGIN
    delay( 500 )     ; delay 1/2 second
    lcd_init()
    rs_param_set( rs_invert | rs_9600 | pin_a3 )
    pin_high( pin_a3 )
    delay( 10 )
    =( temp_chr, pin_in( pin_a3 ))  ; end command pulse
    rs_send( 'A' )                  ; program RSB509 for an A
    rs_send( rsb509_baud1 )         ; program for 9600
    delay( 100 )                    ; give RSB509 0.1 sec to reset

    =( in_count, 0b )
    REP
        pin_high( pin_a3 )          ; ask RSB509 for data
        =( temp_chr, rs_receive( 0b, 0b, in_err ))
        IF in_err
            ; no RSB data
        ELSE
            lcd_data_wr( temp_chr )
            ++( in_count )
        ENDIF
    UNTIL ==( in_count, 20b )

    pin_high( pin_a3 )
    delay( 10 )
    =( temp_chr, pin_in( pin_a3 ))  ; end command pulse
    rs_send( 'A' )                  ; program RSB509 for an A
    rs_send( rsb509_baud1 | rsb509_addr )  ; program for 9600
    delay( 100 )                    ; give RSB509 0.1 sec to reset
    rs_param_set( rs_invert | rs_9600 | pin_a1 )
    rs_string( "Send a block beginning with 'A'" )
    rs_param_set( rs_invert | rs_9600 | pin_a3 )
    =( in_count, 0b )
    REP
        pin_high( pin_a3 )                ; ask RSB509 for data
        =( in_array[ in_count ], rs_receive( 0b, 0b, in_err ))
        IF in_err
            ; no RSB data
        ELSE
            ++( in_count )
        ENDIF
    UNTIL ==( in_count, 10b )

    rs_param_set( rs_invert | rs_9600 | pin_a1 )
    rs_string( "Block was: " )
    =( in_count, 0b )
    REP
        rs_send( in_array[ in_count ] )
        ++( in_count )
    UNTIL ==( in_count, 10b )

    reset()
ENDFUN

Notice that the rs_recblock function is eliminated and rs_receive() is used in the loop instead. This is because the RSB509 performs the address detection and is, therefore, easier to interface using the byte by byte method.