0
\$\begingroup\$

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).

\$\endgroup\$
3
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ This is relevant only if the OP is running some sort of RTOS. He says he's heard of the term "non-blocking" but that doesn't mean its applicable to him. \$\endgroup\$ – tcrosley May 6 '15 at 19:09
  • \$\begingroup\$ I don't see where an OS becomes part of the game... \$\endgroup\$ – Vladimir Cravero May 6 '15 at 19:11
  • \$\begingroup\$ Generally if you need to worry about blocking, that implies multi-tasking. \$\endgroup\$ – tcrosley May 6 '15 at 19:12
  • \$\begingroup\$ @tcrosley it is a bare-metal application. No RTOS. Right now the main function has a bunch of "busy" loops that wait for various tasks to be completed. I am looking for ways to streamline this multitasking without a RTOS. \$\endgroup\$ – ultrasounder May 11 '15 at 18:39
  • \$\begingroup\$ @ultrasounder if you make a new question explaining in detail what these tasks are you can be helped better. As things are the best advice that I can give is: make your busy waits not busy. \$\endgroup\$ – Vladimir Cravero May 13 '15 at 14:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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