Following is a concrete example of a module that does interrupt-based input from a UART. It would be accompanied by a header file with declarations for kbhit() and getch(), and all external access would be done through those functions.

if we are to give examples, let me try one based on the original concept by Russ http://www.8052.com/forum/read.phtml?id=124517

I am giving an example of serial data being stored in various places after receipt and verification.

we have a "modular by russ" serial module to get, say 1024 bytes from serial we need to do this to load a buffer

for (index = 0; index <1024 ; index++)
{
  SpecificBuffer[index] = getCharacter();
}

if we program 'small embedded' instead of 'PC' we do this

for (index = 0; index <1024 ; index++)
{
  SpecificBuffer[index] = GlobalSerialBuffer[index];
}

and have saved something like 20*1024 instruction cycles.

Ok, the approach by Russ may be 'prettier', 'safer' or whatever, but WHY waste 20k instruction cycles in an environment that is definitely not 'resource rich'.

Yes, if you are a blabbering idiot and have to save yourself from yourself, "avoid global variables" is a must * , but if you know what you are doing, the use of global variables should be weighed against efficiency. I do believe that the "global variables are evil" mantra was originally invented by someone that thought everyone but him is a blabbering idiot.

There is nothing hindering a modular approach by using global variables i.e. I have all handling of serial in ONE module with nothing else, but to make getting a character a means of processor overload is ridiculous.

Do I argue "use global variables to your hearts delight" absolutely not, but the "global variables are evil" mantra is udderly stupid in small embedded, whether it applies to the PC I'll leave to others to debate.

Erik

* the statement say "if you are" It does not say "if you do" I am not implying that those that avoid global variables are necessarily "blabbering idiots"