PIC 16F628A UART Coding Problem

[Gayan Soyza]

I'm building a project through PIC 16F628A which is containing UART.the recieving part codings works fine as well as the transmiting part.But I'm having a problem when transmitting from the PC to PIC.

I'm using COMPORT TOOLKIT Software for TX & RX.I have attached the codings.It works like this,

Think my passward is "ON".When you Type "ON" & press enter in the software,the recieving section in the softawre it displays letter "C".
You can notice in my codings....The code works fine.

But if I type "ONON" or "ONNO" or "ONABCDEFGH...." It displays the letter "C" as well & the PIC is getting stucked.In this case My passward gets false.

How to prevent this??? Why the PIC is getting stucked??? any other unwanted charactors must reject.How the code comes???

Many Thankx......Hoping a reply soon

 

[Nigel Goodwin]

Why are you using interrupts?, it's making it overcomplicated (and more prone to errors) for no good reason. Then you're calling delay subroutines from within an interrupt routine, which is really bad practice - but worst of all, you're not resting the interrupt before you RETFIE.

I won't even mention that you're not saving and restoring context at all!.

 

[Pommie]

Can I suggest a different approach. Disable interrupts because, as Nigel states above, they make it overcomplicated. Use a subroutine to wait and read from the port. Do your tests in your main loop.

Something like,

Loop		call	GetByte
		xorlw	'O'
		btfss	STATUS,Z
		goto	Loop
		call	GetByte
		xorlw	'N'
		btfss	STATUS,Z
		goto	Loop
		movlw	'C'
		call	PutByte
		goto	Loop

GetByte		btfss	PIR1,RCIF
		goto	GetByte
		bcf	PIR1,RCIF
		movfw	RCREG
		return

PutByte		btfss	PIR1,TXIF
		goto	PutByte
		movwf	TXREG
		return

If you want it to reject ONABC etc then check for carriage return as well.

Mike.

 

[donniedj]

Pommie got in just as I was typing:
1. Your special function register definitions already exist in the .INC file. No need to redefine them because their hex values are not negotiable.

2. Since STATUS has been defined 3-times, 1 in .INC and 2 in definitions, why not make use of it. Instead of using "btfss 03H" use "btfss STATUS, Z".

3. The reason why the PIC returns C for ascii input pass the first two characters "ON" is because you did not tell to PIC to stop responding once "ON" condition is satisfied. You did not tell the PIC to evaluate the entire packet, therefore its behaving in serial fashion. PIC do what you tell them not what you intend for them to do.

4. Totally agree on not using the interrupt correctly.

Add code to detect an end of packet. Use CR or LF or time domain. With time domain, disqualify a passing password if PIC continues to receive input within a few milliseconds after valid password is entered. Why am I mentioning a technique that if could be correctly done it would not need my explaination in the first place.

Yeah, just use the CR terminator.

 

[Gayan Soyza]

Oh...thanks for the instant reply but sorry for the late viewing.

A little more about this.....I did transmitting part from PC to PIC in the INTERRUPTS because my recieving part from PIC to PC its in the Main Loop.Here in my codings I mentioned only the INTERRUPTS,Main Loop I kept free.Either you can do that also in the Main Loop.

Using delay routines in the interrupts its a bad habbit of me,I must get rid of with it as Nigel Said.

Pommie's subroutine method very usefull in this case when you entering long passwords it does a great job by reducing space.Your code worked well.

I tried my best to stop extra charactors coming after the "ON" but still PIC returns "C" for ascii input pass the first two characters as Donniedj said.I have never used CR and LF I dont know how to do that.So I tried to stop in another way Like...

Loop1		bsf 	RCSTA,CREN	;start continuous recieve

Loop		call	GetByte
		xorlw	'O'
		btfss	STATUS,Z
		goto	Loop
		call	GetByte
		xorlw	'N'
		btfss	STATUS,Z
		goto	Loop
		
		;*****Experiment***********************************

		btfss	PIR1,RCIF	;check for anyother letters
		goto	Display	
		bcf	PIR1,RCIF
		bcf 	RCSTA,CREN	;stop continuous recieve
		goto	Loop1

		;***************************************************

Display		movlw	'C'
		call	PutByte
		goto	Loop

GetByte		btfss	PIR1,RCIF
		goto	GetByte
		bcf	PIR1,RCIF
		movfw	RCREG
		return

PutByte		btfss	PIR1,TXIF
		goto	PutByte
		movwf	TXREG
		return

I checked with different ways in the "experiment" section by Formatting my chip over 100 times but it didn't give a result.So again I need some help from you experts.....

Thankx.

 

[Pommie]

To check for carriage return you check for character 13.

So you check for character "O" then "N" then 13.
I.E.

		goto	Loop
		call	GetByte
		xorlw	'N'
		btfss	STATUS,Z
		goto	Loop
		call	GetByte
		xorlw	13 ;         < check for carriage return
		btfss	STATUS,Z
		goto	Loop

HTH

Mike.

 

[Gayan Soyza]

I'm getting a problem when checking carriage return.

In a string like "ON" what is best way to check the CR with every letter or after "ON" condition is satisfied.B'cuz I checked CR in end of the string but not displaying any output.

        call	GetByte
	xorlw	'O'
	btfss	STATUS,z
	goto	Loop
	call	GetByte
	xorlw	'N'
	btfss	STATUS,Z
	goto	Loop
	call	GetByte
	xorlw	13
	btfss	STATUS,Z
	goto	Loop

Here after pressing "ON" its moving to call GetByte line.So its looping inside the GetByte subroutine until a charachtor pressed.It cannot move to check 13 (0x0D).

I reduced to a one letter like "O" & checked with CR...Like this

        call	GetByte
	xorlw	'O'
	btfss	STATUS,Z
	goto	Loop
	xorlw	13
	btfss	STATUS,Z
	goto 	Loop
	call	PutByte

But still output is blind......any suggessions ...........

 

[Pommie]

The "character pressed" should be character 13 which is the carriage return key. Try typing ON<Enter> and see if that works.

Mike.

 

[TKS]

i would do it different

First wait for the first character if that isn´t correct then

wait for the CR then show password is wrong.

in case the first sign is correct then wait for the second.. etc..

you cant show directly that the password is wrong because it would be easy to determine sow you have to wait till byte 13 is recieved

Tks

 

[Pommie]

Or, never report that the password is wrong.

Mike.

 

[TKS]

yeah but i mean with that that it starts the reset process in that you can show or hide a message but you will need to the place where you compare the first letter (if you make type error)

Tks

 

[Pommie]

Ah, I see what you mean now. You are correct, entries like "BEGON<cr>" will be counted as correct. The simplest way to implement what you are saying is to test for "<cr>ON<cr>" or "<lf>ON<cr>" dependant on the sending system.

Mike.