Hi Mark,

1. If your program is hanging up on the "while (!RI)" line, it seems very likely that you're simply not getting all the input data that you exepct. I'm not sure that converting to an interrupt driven system is going to fix the immediate problem. Also, if your program doesn't have anything else to do while it's waiting for input, and if you can always depend on that interrupt arriving, there's nothing at all wrong with polling for each character as you're doing currently.

2. If you do decide to set up an interrupt routine, heed Erik's caution about "atomicity".

3. Global varaibles are to be avoided generally, but sometimes they make sense. Global variables get you in trouble when you allow yourself to manipulate them from many different places in your code. Before long, you'll lose track of who's doing what to which varaible and wind up with bugs that can be hard to track down.

Having said that, sometimes you need to share variables among a handful of functions. The situation you describe is one such case. A serial interrupt will typically need to plop the received characters into a buffer somewhere, and then some non-interrupt code will need access to the same buffer to retrieve the characters. So the buffer and an index or two will need to be shared between the interrupt service routine and the non-interrupt code.

One really good way to manage that is to put the interrupt routine and the "get a character from the buffer" routine together in one C source file, along with the declarations for the buffer and the indexes. Then don't put any other code in that file. That way, the two functions that need to share the buffer and the indexes can do so, but the rest of the code won't have access to them. You will know for sure that all accesses to the buffer and the indexes are confined to that one file, and that any related bugs must be likewise confined.

This is a specific example of the general idea of a "module". At least the way I think of it, a module is a single C source file that contains a group of closely related functions, along with any data that they need to share.

Although it's a fairly simple idea, it's difficult sometimes to identify exactly how to partition a program into modules, especially if you have started coding without thinking about modularity up front. But the up-front thinking and the actual partitioning into multiple source files are both worth the effort. At worst, you'll clarify your design somewhat and maybe prevent a bug or two. At best, over time you'll wind up with a collection of modules that you can actually lift from one project and plug into the next without a whole lot of rework.

-- Russ