chipKIT® Development Platform

Inspired by Arduino™

"loop()" question on timing

Created Fri, 10 May 2013 18:39:29 +0000 by jim_hahn


jim_hahn

Fri, 10 May 2013 18:39:29 +0000

My hobby project was working nicely (almost) with the Arduino kit. But we found that the Arduino was just not fast enough for one function. So we moved to the PIC24E. It's fast and has enough "extra hardware" inside itself to handle our job. (We needed 12 input capture registers for our timing problem. We need something like 250 to 500 ns accuracy. Better would be better.)

In the Arduino there is obviously a function named loop(). Once we get into our time critical point inside loop(), we turn off interrupts and go into a tight "while(1)" polling six input pins to wait for 6 events to occur. As each event happens, we snapshot a timer into a variable. On the Arduino, just not fast enough. Sorry.

OK, so here's the question: I see that there's a chipKit running a) real fast at 80MHz and b) pretty much identical language constructs as the Arduino.

==> Is it legal in the chipKit software world to sit in a polling routine that causes the high level function named loop() to NOT return for seconds or even minutes? Will this totally screw up other functionality? (USB serial prints, wifi, ethernet, whatever.)

==> Is it legal to turn off interrupts in this situation?

Overall I am not real happy with the MicroChip development environment and their documentation. Maybe it makes sense to try chipKit instead.

Thanks, --jim


Jacob Christ

Sat, 11 May 2013 20:04:20 +0000

==> Is it legal in the chipKit software world to sit in a polling routine that causes the high level function named loop() to NOT return for seconds or even minutes? Will this totally screw up other functionality? (USB serial prints, wifi, ethernet, whatever.) ==> Is it legal to turn off interrupts in this situation?

If your using a Max32 or Uno32 the USB is handled by the FTDI. You screw anything up but you will also not be able to received any data. I don't know much about WiFi but Ethernet will have similar problems if you starve the processor. That is you may not break it, but you may drop data.

Overall I am not real happy with the MicroChip development environment and their documentation. Maybe it makes sense to try chipKit instead. Thanks, --jim

Six of one half dozen of the other? For me the best documentation for the PIC's is the datasheets. There are things that frustrate me about both tools.

Jacob


jmlynesjr

Sun, 12 May 2013 19:35:58 +0000

Have you looked at Pin Change Notification Interrupts? Any pin can generate an interrupt. You could try pin interrupts instead of polling.

From Majenko: "AFAIK there is no core support for change notification. Someone patched the core themselves to add it, which I thought was rather hacky, so I created the library to remove the hackyness.

Using the library is incredibly simple - instructions are on the wiki: https://sourceforge.net/p/chipkitcn/wiki/Home/ - you just use it like the normal interrupts, just with CN_x instead of an interrupt number."

I used the library above to read a rotary encoder. Search for Spark Fun Rotary Encoder for an example.

James


jim_hahn

Mon, 13 May 2013 16:36:07 +0000

Help me understand if pin chang interrupts would work.

Obviously interrupts must be ON for it to work.

Initial reading of the documentation is a bit sparse. If, let's say, MY ISR is running, can another function's interrupt interrupt ME? That could be bad as it would introduce random delays occasionally to my ISR's reading of the timer. Similarly, if my pin changed - thus signalling it wanted its ISR to run - would my ISR calling be delayed if another ISR was already running? I assume one or both of these could happen.

But maybe that's ok. If the "other" ISR was known to only take a small amount of servicing time, I could live with that. I think my own pin change ISR could process in ten instructions or so, which I think would translate into about 100ns or so. I could live with that. But I probably cannot live with 500ns.

I don't see an obvious place in the documentation which describes how many interrupts one can have with the chipKit. With Arduino it's 2, 4, or 6 depending on the processor type. Six would be nice with chipKit so I could attach each of my external events to a separate interrupt. If I have to share, things get a bit messy with some hardware needing to be added externally.

This leads back to my original post: If I do polling and turn interrupts OFF, will that completely screw up some other task? I could live with dropped messages but could not live with that other task not being able to recover. --jim


jmlynesjr

Tue, 14 May 2013 19:03:01 +0000

With Pin Change Interrupts you can have as many as you want. See the referenced library and examples above.

James


Jacob Christ

Thu, 16 May 2013 16:34:36 +0000

Help me understand if pin chang interrupts would work. Obviously interrupts must be ON for it to work. Initial reading of the documentation is a bit sparse. If, let's say, MY ISR is running, can another function's interrupt interrupt ME? That could be bad as it would introduce random delays occasionally to my ISR's reading of the timer. Similarly, if my pin changed - thus signalling it wanted its ISR to run - would my ISR calling be delayed if another ISR was already running? I assume one or both of these could happen. But maybe that's ok. If the "other" ISR was known to only take a small amount of servicing time, I could live with that. I think my own pin change ISR could process in ten instructions or so, which I think would translate into about 100ns or so. I could live with that. But I probably cannot live with 500ns. --jim

We are doing RC servo pulse timing at about 60ns resolution CN interrupts on eight inputs. RC servo receivers stagger the pulses so we don't have to worry about pulses coming in at the same time. If they did then I don't think our resolution would be as great. Also, since the processor runs at 80MHz you will never get better than 12.5ns using this method.

If you need better than this, you might consider using your signal to gate a high frequency free running clock to a timer input. But here you would be limited by the number of timers on the chip but you maybe able to get sub 60ns resolution (I'm not sure the BW limit on a timer input).

This is all done by passing the Wiring abstraction layer and talking directly to PIC32 SFR's

The code is on github here:

https://github.com/pontech/uav100

Jacob