0

Consider an USB device that is receiving data over a wireless network and an application running on the PC is reading this data. Now, on many languages (consider C# DataReceived), we have event handling mechanisms to detect if Data has arrived or not.

My question is, how is this event detecting mechanism implemented?

Is it like, a running timer which periodically checks to inspect arrival of data, or is this something the hardware has to support?

In general, how are these changes in hardware state events implemented?

4
  • This question is offtopic. Please ask at stackoverflow.com
    – FUZxxl
    Commented Nov 29, 2011 at 14:27
  • 3
    It is off topic on stackoverflow as well.
    – mouviciel
    Commented Nov 29, 2011 at 14:28
  • Perhaps this would be the appropriate place for this question: electronics.stackexchange.com
    – user7007
    Commented Nov 29, 2011 at 14:31
  • 2
    @GlennNelson: I guess, being off-topic on Software means the solution is Hardware based, right? Commented Nov 29, 2011 at 16:35

2 Answers 2

5

Interrupts are a hardware mechanism similar to events.

Whenever a specific condition arises in the physical world (e.g. data arriving on USB), a line switches from one level to the other. This is an interrupt request.

The CPU is built to detect this change and to respond by jumping to an Interrupt Service Routine. This routine in turn generates a software event.

1
  • Thanks, just the answer I needed. Though, I still see some "Esoteric Software Element" in the question and your answer. So, it's not that bad a question for here :). Commented Nov 29, 2011 at 16:38
4

USB is quite complicated because various parts of the protocol may be implemented in hardware depending upon the platform being used. It might be easier to consider something a little simpler, perhaps a serial port controller.

The precise series of actions that are performed will depend upon the processor interrupt handling mechanism (some processors are more automated in servicing interrupts than others). The description below is typical for the processors that I have used over the years.

Normally the serial controller receives a character it is programmed to raise an interrupt signal to the processor. This is a physical signal that indicates to the CPU that there is some external event needing to be serviced. This signal causes the processor to complete the current instruction and then to place its current execution address and processor status registers onto the stack.

The processing address is changed to the interrupt service routine. There may be one service routine for all interrupts, or a number of interrupt routines one for each of the interrupt sources that the processor supports. These interrupt functions have to poll the interrupting device to determine he reason for the interrupt and then perform the appropriate actions, in this case to read the character from the serial port and move it to the input serial data buffer to be used by the processor main application.

Once the interrupt processing has been completed the processor status and execution address are restored and processing then continues from the instruction after the last instruction executed before the interrupt happened. It is extremely important that all of the processor registers used by the interrupt processing are restored to exactly the same state before the routine terminates so that the only effect of the interrupt on the main code is to insert a short delay into the main line processing code.

The interrupt code has to set event indicators to the main code so that the high level application code can detect that the interrupt event has happened.

Not the answer you're looking for? Browse other questions tagged or ask your own question.