Remote Control by cellphone...

[emufambirwi]

I have this problem of maintaining the 9600 baud rate when receiving the bytes. Will this not have a bearing on the baud rate

 

[Nigel Goodwin]

I have this problem of maintaining the 9600 baud rate when receiving the bytes. Will this not have a bearing on the baud rate

What do you mean you have a 'problem'?.

The tutorial routines are very old and very well tested.

 

[emufambirwi]

You are right that the routines do work. What I am worried about is the time spent doing the comparison of the received byte and the byte in the table, because what happens is I receive a byte then compare it with another before receiving the next and that's where my worry is.

Maybe we could receive the whole message first then do the comparison?

 

[Nigel Goodwin]

You are right that the routines do work. What I am worried about is the time spent doing the comparison of the received byte and the byte in the table, because what happens is I receive a byte then compare it with another before receiving the next and that's where my worry is.

Maybe we could receive the whole message first then do the comparison?

You could do it either way, but bear in mind you've got all the time of a stop bit to do the comparison anyway - and in PIC terms that's lot's and lot's of time!.

 

[emufambirwi]

As a method of testing my rs232 communication, I connected my pic16f84 to the max232 and pc. In Hyperterminal, I saw ascii characters way different from the Hex files i was transmitting like ¶°ïüĂ●∑

 

[Nigel Goodwin]

Are you sure the polarity of the data was correct?, remember the MAX232 inverts it - and are you sure the baud rate was set correctly?. Both of these will give weird characters.

 

[emufambirwi]

Yes, the baud rate was set correctly as follows in software.

TXBYTE MOVWF BYTE ;save table value to BYTE
MOVLW 0x08
MOVWF BITCNT ;do eight times
BCF TXPIN ;SEND START BIT
CALL Bit_Delay ;delay 104 instruction cycles
;assuming 4MHz clock, that's 1us per instruction cycle
;so delaying 104us
TXLOOP RRF BYTE,F ;move BYTE bit0 into carry
BTFSS STATUS, C ;a Low ?
BCF TXPIN ;yes, send it
BTFSC STATUS, C ;a High?
BSF TXPIN ;yes, send it
CALL Bit_Delay
DECFSZ BITCNT
GOTO TXLOOP ;loop for 7 more times
BSF TXPIN ;SEND STOP BIT
CALL Bit_Delay
RETURN

 

[emufambirwi]

sorry about the above post, the 104us delay is generated as follows, I have simulated the program using mplab and the timing is correct.
Bit_Delay
MOVLW 0x21
MOVWF DELAYCNT

DELAYLOOP
DECFSZ DELAYCNT ;one cycle if DELAYCNT
GOTO DELAYLOOP ;two cycles
RETURN

 

[emufambirwi]

My code snippets are not coming out clearly, what do I do?

 

[Nigel Goodwin]

My code snippets are not coming out clearly, what do I do?

Surround them with the 'Code' tags, click on the 'Advanced' button where it's an option.

 

[emufambirwi]

I did not receive a comment on my delay, is it ok

 

[Nigel Goodwin]

I did not receive a comment on my delay, is it ok

I didn't check it, just use the one from my tutorial which is known to work (uses a 4MHz clock).

 

[emufambirwi]

Are you sure the polarity of the data was correct?, remember the MAX232 inverts it

How do I invert the data again in software?

 

[Nigel Goodwin]

How do I invert the data again in software?

Switch the BCF's and BSF's in the transmit routine - don't forget the start and stop bits as well.

 

[emufambirwi]

ok thanks, feedback later