How to tell there is a serial request

[cncmachineguy]

The voices in my head keep telling me there is something I don't get. How does the PIC know the PC wants to talk? Heres my situation: Using hardware USART, I want to be able to query the PIC from time to time. But the app is time sensitive, so it won't always be a good time to stop and talk to the PC. I would like to be able to see the request from the PC, then respond with a single character that the PC would know means no time to talk right now.

I can picture this if HSERIN were a command to say start a background type process and when a byte is received an int is generated. then I would jump to the int handler, check a flag to see if its a good time to talk. If not, send the no message back and return. If it is a good time, maybe set a flag to be polled in the main routine.

The main routine would then see the flag and gosub to the chat routine.

[Darrel Taylor]

PIR1.5 is the RCIF (Receive Interrupt Flag).
If a byte has been received, RCIF will be set.

The USART has a 2-byte buffer, so the byte received can just sit there until the main program has time to respond.

You don't really need interrupts for the case you described, as long as the PC only sends 1-byte and waits for the PIC to reply. Then somewhere in your main loop, when the program has time ... check RCIF and respond to the request as needed.

[cncmachineguy]

Thanks Darrel, so to be clear in my mind, I would do this:
poll pir1.5 in the main loop
If set, jump to serial routine

serial routine:
check time to talk flag
If set, HSEROUT an ack and then HSERIN waiting for whatever
Else HSEROUT no time
return

Now how did I get the info in the buffer? Does HSERIN grab whats in the buffer, or look for new received bytes?

[Darrel Taylor]

Yes, HSERIN gets it's data from the USART's buffer.

In the main loop you could ...

    IF HaveTime AND RCIF THEN GOSUB Serial

The PC will wait until the PIC sends it.
Don't see a reason to tell it there's no time to talk now. But maybe your app needs that.

[cncmachineguy]

Thanks again Darrel for the explaination.

The reason to send back a busy byte is for the user. Being me if I try to talk to the card and get nothing, I will likely forget its because my drives are enabled and assume there is something wrong. Then go and spend as much time as possible just to find out all is working as it should.