Help with stopping a loop with a serial receive on 16F876.

[Ceetee]

Thanks to both of you.

I will be trying both methods as soon as I can and report back.

Thanks for your quick response's

[Ceetee]

Hi

As a follow up I have used a combination of both suggestions.

I have to say that watching PIR1.5 (RCIF suggested by cncmachineguy)for a change is my preferred method of checking for a character received in the USART buffer. This seems to cause me less problems with my CCPx capture i.e. less time delay. Unfortunately the down side is that it is read only and I have not found a way (yet!) to reset/clear the USART buffer by using the registers. So I have utilised the HSERIN, with a small timeout, command as aratti suggested. Using this then clears the USART buffer and appears to work fine.

if PIR1.5 = 1 then 
Hserin 1,jump,[MI]           ' 1mS timeout then read the character and clear buffer
jump:                        ' Character is any because it is only used as an interupt
gosub gratio
endif

Thanks again much appreciated......

[cncmachineguy]

Unfortunately the down side is that it is read only and I have not found a way (yet!) to reset/clear the USART buffer by using the registers.

From datasheet:

Flag bit RCIF is a read-only bit which is
cleared by the hardware. It is cleared when the RCREG
register has been read and is empty

[Ceetee]

Hi cncmachineguy

OOOps !. I have been reading that section of the datasheet over and over again but it didn't click until you highlighted it so I have removed the:-

if PIR1.5 = 1 then 
Hserin 1,jump,[MI]                                      ' Read a character and clear buffer
jump:                  
gosub gratio
endif

and replaced by using a "dummi" variable to read RCREG as follows

if PIR1.5 = 1 then 
dummi = RCREG                              ' Read a character and clear buffer
gosub gratio
endif

That seems to work ok.

Thanks again

[aratti]

Very likely this is what you need! But I thought you should have control on the direction of your program flow. In this way any byte received will direct you to the gosub indicated and this could also happen out of your control. I personally would have identified the byte received and if the byte was the correct jump_byte then the program could proceed with the jump, any other bytes would be ignored.

But as I just said above, if this is what you need and you are happy with it, why changing it.

Al.

[cncmachineguy]

Al, I like your way. But I guess it really depends on what you want to do with the byte. In my upcoming app, I will need something simular to what you have suggested. Just one more reason to LOVE this place. Multiple ways to solve a problem, some better then others depending on the app.

[Ceetee]

Hi all

I agree that identifying the byte received is beneficial and I have considered using that feature, but I only need (at the moment) to identify when the CCP1 capture has reached a specific point determined by my PC program. When this point is reached I have a requirement for both CCP1 and CCP2 to be sampled for a short period after which it should return to the original gosub measuring CCP1 only. When I have a need to stop and return to my small menu then I currently do that with a button press at PortA.5.

This is at the moment though because both PIC and PC programs will evolve, I dare say in the future I will allow my PC program to have more control over what the PIC does. I am currently learning lots of new things so I tend to go slowly.

Anyway thanks for the suggestions and I agree its a good job there are guys like yourselves around to help..... Keep up the good work.

Chris...........