Problem with #int_RDA

[Sensor]

PIC = 16F627A
Compiler = PCWH version 3.236
Target Voltage = 5V
Oscillator = 4MHz

I am trying to get two 16F627A's to talk back and forth using their UARTS. Everything works fine until I remove the two statements from my interrupt:

[jecottrell]

Try replacing the LCD lines with a delay. I have a feeling the LCD lines are acting as a delay and allowing the full string to arrive. Once you remove them the interrupt fires on the first character and you lose the rest?

The delay is a suggestion for debugging and not the recommended solution. The experts will probably be able to give the elegant solution.

Just a WAG.

John

[rnielsen]

First, puting function calls, inside an ISR, is an extremely bad idea. ISR's should be as short as possible since nothing else can happen while it has control. Never, ever put a while() inside one either. You want the ISR to be entered, shatch the character and then get out. Don't have the program setting in there waiting for a condition to be met. If you need to, read the character, evaluate it and if it meets what you're looking for then stuff it someplace to be manipulated later in the main(), or a different routine. If it doesn't meet what you're looking for then bail out.

Inside your ISR you are evaluating 'c', inside your while(), before it's even assigned a value. Re-think what you want to do and try again. Make is as simple as possible first, then add more stuff until you have what you want to end up with.

Ronald

[Ttelmah]

If you are bothering to use interrupts, then don't waste the effort, and have the code sit inside the interrupt handler waiting for a string. When an interrupt occurs, there is _one_ character waiting to read. Read this, and let the processor get on with other things, or you might as well simply 'poll' for received data in the main loop.

I'd suspect the problem is 'c'.
You declare this in the subroutine inside the interrupt handler, _but do not initialise it_. Hence unless it is overwritten, the next time this routine is called, it'll contain the last value used. After one pass through the get_str function, it'll contain the eol character, so the while loop will never execute. Now 'local' values, can be overwritten by other routines called from the same 'master' routine. So what is happening, is that the lcd code, results in this being overwritten, and the code once more executing OK.
So, either initialise 'c' (as you do with len), or reverse the logic of the loop, and use a 'do...while', so the test is executed at the end of the loop.

Best Wishes

[Guest]

Initializing 'c' fixed the problem.

So, instead of using an interrupt, should I just constantly check kbhit(), and if kbhit() = 1 then jump into my get_str() routine?

Thanks for the help

[Mark]

[Ttelmah]

It is important to understand what an interrupt is 'for'. It allows asynchronous events, to call a routine, _but_ brings with it a significant overhead. There are about 70+ instructions of overhead associated with having an interrupt handler. Now if (for instance), you wanted the processor to be getting on with other jobs (polling a keyboard, updating I/O, and sending messages etc.), while you wait for a message, the interrupts are the way to go, but you then use the full ability of the interrupt, just transfer _one_ charater when the interrupt is called, and set a 'flag' when the terminator character is seen. The main code can then get on doing the other jobs, and just stop these when the flag is set. However as currently coded, you do nothing else while waiting for the message, hence you might as well get rid of the interrupts, and just dothe work in a polled loop. At the start of your 'while', look for a kbhit, and then when this is seen, call your get_str function. The result will be the same as your current code...
In general, interrupts using the 'per character' solution, are more likely to be the 'right' solution, since you can then have the code doing other things. As it currently stands, you are using interrupts, but ghaining nothing from them.

Best Wishes