RS-232 interrupt fails

[dDelage]

This is code (simplified) that has worked previously with PIC16F876A, now being used with PIC16F18855. I know that the WIN11 and Prolific USB/Serial adapter work because they work with the previous revision. Here's the code with two choices, neither of them work. Ideas?

[Ttelmah]

The problem is you are not using the UART!......
Hence no INT_RDA....

Look at the sticky at the top of the forum about PIN_SELECT.

The new chip is a PPS chip. The peripherals are relocatable to different
pins.
The syntax you need to use is:

[dDelage]

Thank you, thank you. I woke up this morning to a message that makes me feel so dumb, but happy! You made my day. On to the next!

[Ttelmah]

It is one of those things that until you have 'met it', is not immediately
obvious. So don't feel too bad.
Just add it to your internal knowledge-base, to check if a chip has
PPS.

Have a great day.

[dyeatman]

I find it interesting it is working previously using gets() for a single char input
unless it spends a loooong time in the ISR and has the potential to hang.....
_________________
Google and Forum Search are some of your best tools!!!!

[PrinceNai]

[Ttelmah]

Yes.
Using gets in an RDA interrupt, will 'work', but completely wastes the
actual point of the interrupt. It means that nothing else happens in the
code all the time serial is being received. The whole 'point' of having
interrupt driven serial is so that other things can be done while serial data
is being handled....

Generally, except when working with very fast serials, as PrinceNai says
it is really worth getting your head round just how slow normal serial 'is'
in processor terms, and so how easy it is to handle data between packets.

[PrinceNai]

To illustrate the point of Mr. Ttelmah. With a clock of 32MHz each machine instruction cycle takes 0,000125ms. With a serial set to 19.200 each byte (10 bits) comes in every 0,52083ms. That means you have 4.177 (4177, not four point 177) instruction cycles available for each byte received. Messages are seldom (never) 1byte long. + Carriage return and Newline take the same time. An eternity.

[PCM programmer]

Note that you are using a decimal point as a thousands separator, and a
comma as a decimal point. Some countries do this, some do the opposite.
So you mean 4177 instruction cycles.

[PrinceNai]

Dear PCM, 4177 cycles it is. Please don't hold it against me for using European way of writing numbers, since I'm from there. It has already caused me no end of grief with SQL. But the point is well taken. How could people know? I edited the response, leaving the original there.

[PCM programmer]

My intention was to indicate it to others if they weren't aware of it,
not to chastise you.

[PrinceNai]

It was never ever taken that way :-). You pointed out how numbers can be interpreted in a totally different way, based on how one is trained to see them. A very good point, in fact, that can save someone a lot of time scratching his head and wondering about the result.

As I mentioned, I already had problems with precisely the same thing and lost days with an SQL database where the same client program spitted out different results on different computers. Different locale, different way of interpreting the numbers and dates. So once again, your comment was very well taken and I hope I'll remember it next time.

[Ttelmah]

Yes.
I must admit when I read the original post, it took me perhaps half a
second to suddenly reaiise that the decimal here was the thousands
separator. However I've dealt with so many variants of this over the years
that it is very much second nature (the apostrophe in Switzerland was one
that drove me mad!). Remembering when programming to make sure that
you have the 'national' options selected to deal with this has become
standard practice in databases, spreadsheets etc., that remembering
standard text does not deal with this, is important. I think PriceNai's
change to point it out in his post was the brilliant way to handle this.

[dDelage]

Greetings, all. I am resurrecting this thread from a year and a half ago. I am the son of the OP. I'm picking this project up where he left off.

I see that after Dad got his answer and left the conversation, that a lot of good points were brought up.

Regarding the serial interrupt: in this particular application, when we get serial messages, there isn't a lot of other stuff going on, so waiting for the full string seems to work.

However, I have taken the advice about not wasting CPU cycles to heart, and am looking to improve the serial interrupt handler. Unfortunately, in this case, our serial messages do not have a specific end character, so we can't wait for, say, a CRLF and then signal main() to process the serial data buffer.

I'm considering using one of the 8-bit timers on the PIC to do a timer-based serial capture. Serial strings into the PIC are never more than 10 characters long and are always sent in one stream from the computer. We're running at 9600 baud, which tells me that each character arrives in just under 1mS, putting us at ~10mS for the worst-case string.

The plan is to start the timer when we receive the first serial character, and then signal main() to process the serial data buffer 15mS or so later, giving plenty of time for the remainder of the characters to arrive.

So now here's the question: has anyone here done anything like this before, and if so, does this approach make sense? I'm leaving lots of details out--like incrementing indices and clearing out the serial buffer--in the interest of brevity. When I get this coded, I'll be sure to post the source, but in the meantime, I'm hoping to see if anyone has any tips.

And the best solution is probably to put a message terminator at the end of the serial messages, but we have thousands of devices in the wild that can't be updated, so we'll probably have to deal with this issue for the foreseeable future.

Thanks!

[Ttelmah]

Whoa a second.

gets, waits for a carriage return.

If gets works, then you can simply have the ISR set a flag when the
carriage return arrives.

The original approach, won't work unless there _is_ a carriage return...