Hardware USART Receive Difficulties

[H2TECH]

I have searched the forums to a solution to a possibly simple question, but with little luck. I need to design a program to receive serial data and display it with the USARTRX1READY interrupt and hserreceive feature. However, the display never displays the correct sent data (which is sent from a 16f688 transmitter sending simple numbers to the receiver). Here is the example code of the receiver:

#chip 16f628a,4
#config OSC = INT

;Defines (Constants)
#define LCD_IO 4
#define LCD_DB7 PORTA.1
#define LCD_DB6 PORTA.0
#define LCD_DB5 PORTA.7
#define LCD_DB4 PORTA.6
#define LCD_Enable PORTB.7
#define LCD_RW PORTB.4
#define LCD_RS PORTB.5
#define USART_BAUD_RATE 9600

;Variables
Dim temp As word

;Interrupt Handlers
On Interrupt UsartRX1Ready Call rx

dir portb.1 in

initusart
MAIN:
cls
print "waiting"
wait 100 ms
goto MAIN

Sub rx
hserreceive temp
cls
locate 1,0
print temp
wait 10 ms
End Sub

When I use software serial communication it works, but I need the convenience of interrupts in hardware communication. Any help?

[BoomStick]

Can you use/get a CS line? eg when the signal starts it triggers the recieve code?

(That how I just solved my problem in the last thread!)

[H2TECH]

Are you referring to a clock signal line? If so, I don't believe there is a separate clock line, and for simplicity, I would not prefer to use one unless necessary.

Also, I noticed the TX line on the transmitter is normally on, but drops to zero when serial is sent. (Its inverted). I'm not sure if this is a problem or not.

[H2TECH]

I continued to explore the problem associated with the above program and found that the interrupt and hserreceive command works, but stores the wrong number in the variable temp. Usually 65535 is displayed as temp when temp should actually be 123, 2, 145, etc.Is this a bug with GC BASIC. I have the 2/14/2010 version. Is this a problem. Please help and thanks for any helpful responses in advance.

[kent_twt4]

The tricky part is getting the lcd printing routine to play nice with USART routines.   The USART rates are measured in microseconds, while the lcd routines like the cls can go into the millisecond range.  That's the challenge.

Since I envision streaming some data in from a PC someday, I took a closer look.  By buffering the ascii input bytes, and checking for a "CR" from the terminal, the timing aspects can be alleviated somewhat.  The 18f2320 is a pile, don't buy one, the MCLR can not be made a digital input!!!!!

'This program can receive a variable
'number of bytes followed by a CR.
'After the whole packet has been received,
'the buffer is then displayed on a chr lcd.
'KS 2/7/12
'Chip model 
#chip 18f2320,8
#config PBAD=DIG , MCLRE=ON, OSC=INTIO2
'Setup 4 bit LCD 
#define LCD_IO 4
#define LCD_DB4 PORTB.4
#define LCD_DB5 PORTB.5
#define LCD_DB6 PORTB.6
#define LCD_DB7 PORTB.7
#define LCD_RS PORTC.5
#define LCD_RW PORTA.2
#define LCD_Enable PORTC.3
#define led0 PORTB.0
dir PORTB.0 Out
dir PortC.7 In
#define USART_BAUD_RATE 9600
On Interrupt UsartRX1Ready Call getdata
'As a demo, send "0123456789CR" from a terminal
dim fish(10)    'leave room for CR
Set led0 On     'check for heartbeat
wait 1 s
Set led0 Off
wait 1 s
stream = 0
streamlength = 0
cls
MAIN:
'Other stuff here'
goto MAIN
Sub getdata
stream += 1                 'increment the buffer count
fish(stream) = hserreceive  'RCREG
If fish(stream) = 13 Then   'end of current data
    streamlenth = stream - 1    'bufferlength
    stream = 0
    goto nextdata       'clear lcd and print
End if
fish(stream) -= 48      'change ascii to decimal
return                  'still collecting data till CR
nextdata:
cls
for chunk = 1 to streamlenth    'print out to bufferlength
    Print fish(chunk)
next
streamlength = 0    'reset byte counter
End Sub