PIC18 IO polling

interruptspic

I just recently decided to migrate an existing design which was based on Interrupt on change pins to standard IO polling due to some constraints in the part that I was using. I am trying to figure out the worst case time required to poll a GPIO for an event, process the event and exit the loop. I have seen the word "non-blocking" code thrown around various literature and my guess is that is what I would like to implement here. Any pointers or Pseudo-code would be very helpful. The part I am using is PIC18F85K22 and I am running the internal clock at 64MHz(Max).

Best Answer

A non blocking call to a portion of code usually implies the request for a resource, such as a printer, or an event in your case.

If the printer is busy, or the event has not happened, there are two possibilities:

  • wait for the resource to become available
  • carry on and check after a while

the first option is blocking: the code execution is halted in what is called busy waiting, or spooling. The processor can't do anything and that is a waste of power and time.

the second way is non blocking: the code executions continues, the processor can do something else, possibly servicing other events, then check back later. The problem is that if your event expires in some way code execution may well not come back in time.

Some pseudo c to illustrate an example of busy wait:

while(event_1_has_happened == 0); //do nothing
int result_1 = service_event_1();
while(event_2_has_happened == 0); //do nothing
int result_2 = service_event_2();
//... and so on

Non blocking wait:

int keep_servicing = 1;
while(keep_servicing == 1) {
    if(event_1_has_happened == 1) {
        int result_1 = service_event_1();
    }
    if(event_2_has_happened == 1) {
        int result_2 = service_event_2();
    }

    //... and so on
    keep_servicing = somefunctionofresults(result_1, result2, ..);
}

Please note: the above samples assume that the functions event_n_has_happened return immediately whether the event has happened or not. They might be something like checking if an input pin is high or low, or whatever.