RS-232 interrupt fails

[temtronic]

just comments...

1) are you 100% confident the incoming stream of data WILL have a CR ? If it doesn't gets will 'hang forever'......

2) have a look at the 'timed serial' example in the manual FAQ(?) section ! It's clever code to 'escape' from receiving incoming serial data,say when the cable gets unplugged. You set a timer value,say 2x the expected time for the data to come. If data doesn't come,then the code sets a flag and exits the 'receive section',so program doesn't 'hang'.

[newguy]

I've done this before.

You'll need two processes/loops. First would be your serial ISR (RDA). For the moment, just consider it to be very simple: extract the waiting character from the UART and stick it in a circular buffer.

Second is a timer. Your reasoning in terms of time is pretty sound, but instead of the 15ms you're considering, I'd set it to 2ms. ...Bear with me.

In the RDA interrupt, other than extracting the character from the UART and sticking it in a buffer, next question should be: is my timer running?

If the timer isn't running, zero it and arm it. Set the timeout to be twice a character time. In your case, 2ms. This situation would be indicative of having received the first of probably many characters. No need for the timer to be running unless you're actively receiving a message.

If the timer is running, reset it. I just received a character, so I'm going to give myself another 2ms to receive another.

If the timer expires, it's been 2ms since the last received character so it's likely safe to assume that you received a full message. In the timer ISR, kill the timer and set a flag so that in your main loop you can now examine the buffer and extract the last received message.

[dDelage]

Thanks, all!
And also, thanks for not berating me for not reading the FAQs. I had done searches, but never noticed that FAQ link before.

I was amazed, but not surprised, to hear about gets() waiting for CR. After all, *something* has to signal gets() that the string is done. I never noticed it because gets() eats the CR and replaces it with a NULL.

I did a test and verified that all serial data coming into the PIC ends with a CR. That's not always the case for serial data out.

I had never considered that the serial cable could get unplugged. It certainly hasn't been reported by users before. So I think I'm going to implement pieces of the last three responses. First is to change the ISR from gets() to get(c) and wait for CR to signal main() for processing. Second is to have a mini watchdog timer that gets reset on each character received, so that if a CR isn't received, we don't hang the PIC.

Awesome stuff. Many thanks!

[newguy]

Glad to hear you have a path forward.

Concerning the possibility of missing the CR, the planned timer approach is one way but you can also forego the timer 'escape hatch' if you structure your parsing routine appropriately.

I've developed several bespoke systems that depend on unique start and stop characters. They cannot be found in the body of a message. Only delimit the start/stop of a message. Broadly similar to your unique case.

When the ISR detects an end of message character, assert a flag meant for your main loop. In that loop, walk through the receive buffer until you either encounter a valid stop character, or until you reach the head of the buffer (where the ISR is presently pointing in terms of filling the buffer). Once you find that stop character, walk back to the beginning of what should be a valid message start.

This approach doesn't need a timer. Mangled messages are no problem because the parsing routine will discard anything mangled/unexpected anyway.