attachCoreTimerService() on WiFire

Created Mon, 16 Jan 2017 04:49:59 +0000 by photomankc

photomankc

Mon, 16 Jan 2017 04:49:59 +0000

Curious if there are known gotcha's in the use of this function? Is there something that my standard loop code must not do if this is used? I was hoping that I could write pretty straight forward loop code using this but so far in my existing project I have no luck at all using this function. After anywhere from 1 to 5 minutes the whole board locks up if I so much as register the callback and return the ticks for the next call. I don't even perform any activity in the ISR and it will still lock up. Not sure where to go with it now. In my implementation I just called to register the ISR and then the only line in the ISR was:

uint32_t sensorISR(uint32_t currentTime)
{
  return (currentTime + CORE_TICK_RATE*10)
}

With only that code in place the board locked up after about 3 minutes. If I called any functions from within the ISR it would lockup in about 50 or 60 seconds.

The project is fairly complex so there is a lot of stuff happening in the loop. The project is a behavior-based robot on the PIC32MZ since it has the RAM and program size resources to do it. Right now it's just getting started, I'm porting over from BeagleBoard. This was an attempt to update the sensors in the background to keep a slow process from hanging up sensor updates. On the BeagleBone those ran in a separate thread. Right now my loop is only taking 4us so even if that is increased 4000 times with more code I can still run the sensors in the pseudo-threads I'm using for the rest of the system. it seemed more clean to insure their operation using interrupt on a timer to simulate the way it was done on the Beagle.

majenko

Mon, 16 Jan 2017 10:36:16 +0000

I can't see that just defining a callback like that is going to cause any problems. All you are doing is setting the address of your function in an array of functions to call, and when the CT triggers it iterates that list calling the functions that are due. All you are doing is updating the "next due" time in that list.

You may be drifting slightly away from precise 10ms ticks, though, which would increase the number of times the CT triggers - sometimes maybe with a very short time between them. That may be an issue, I can't say.

You should really calculate your time in the same way that the milliseconCoreTimerService does - that is, keep track of your call time and add 10*CORE_TICK_RATE to it each time, instead of adding it to the time the function was called.

uint32_t sensorISR(uint32_t currentTime)
{
  static uint32_t myCallTime = currentTime; // Remember the first time called
  
  myCallTime += CORE_TICK_RATE * 10; // Regular 10ms slots from the first call time onwards
  return myCallTime;
}

photomankc

Mon, 16 Jan 2017 17:53:01 +0000

Well,

Interesting.... that construct seems to have fixed this. Cautiously optimistic since it's been running now for 15 minutes without locking up without content in the ISR. Thanks for the tip on that.

Any gotchas on calling another function within the ISR? I realize things have to be kept short. No complex timed stuff in there.

majenko

Mon, 16 Jan 2017 20:58:05 +0000

The only thing to watch is that the CT interrupt runs at the absolute highest priority. That means you cannot use anything in there that would rely on another interrupt occurring for it to complete. That means no access to a changing millis() within the ISR - it will be static at the value it was at the start of the ISR. Also it will interrupt everything else, even other interrupt routines.

And as always don't do things with peripherals both inside and outside the interrupt routine, or you end up with the possibility of trying to use the same peripheral for two things at once, which isn't nice (a problem with one of the network shields with SD card and both wanting SPI, one in an interrupt routine and one not - very nasty...)

photomankc

Mon, 16 Jan 2017 21:58:55 +0000

Very good. I appreciate the help getting it rolling. I would not have caught that issue.

Got it running now keeping simple sensors updated and stuffing the results into a global structure that the rest of the program reads for results. Perfect!