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.
Protean Logic Inc. Copyright 05/06/04 Top of Page