Has anyone had lack of processing power?

[Anthony Kesich]

Reading through the Programming thread, I have come across many a post referring to avoiding doubles and square roots and standard Math.h functions since the PIC is an 8-bit processor. I remember this was a big thing before the start of last season too. We even tried to rewrite the Math.h to not use things like sqrts and the like. And yes, I do understand why those things were avoided since they take more power since an 8-bit processor will use software to do 64-bit math instead of hardware.

Here's my question though. Has anyone actually had problems with processing power on the PIC? I mean, have you had dropped packets due to the processing cycle taking too long or something along those lines? 26.2ms is quite a long time for a processor.

[Mark McLeod]

Most of the problems with the processor keeping up that I've run across with various teams have been due to inefficient and bloated code. They more often run out of programming space than processor time. The most common exception has been bloated interrupt handlers causing multiple interrupts to be missed. The code problems are to be expected with people learning to program for the first time and attempting to implement complex equations from their math textbook.
The cautions are more directed at the neophytes than experienced programmers.

I did some measurements last Fall on the Robovation (formerly EDU) controller and came up with:
v45% more program space than the equivalent operation using integer math is what’s roughly required for simple floating-point operations (e.g., a=10.5*2.3 vs i=105*23)
v22% more time is required for equivalent float vs. integer operations

I no longer remember the details as to what percentage of program space was due to a one time floating point library and what each additional statement demands. It just takes a minute or two to run the test though.

[Kris Verdeyen]

We had some issues keeping track of an encoder we used to close the loop around our steering control. It got to be very resource-intensive to count every edge transition, so we modified the code to only count every fourth encoder transition, which worked fine.

The problem, as Mark noted, is that the program hasn't returned from the interrupt service routine by the time that another interrupt comes along. This causes the processor to miss a count, which over time will lead to a large position error.

This will be the main type of problem that you'll see, especially if you try to close any high speed loops.

[Rickertsen2]

Originally Posted by Kris Verdeyen

We had some issues keeping track of an encoder we used to close the loop around our steering control. It got to be very resource-intensive to count every edge transition, so we modified the code to only count every fourth encoder transition, which worked fine.

The problem, as Mark noted, is that the program hasn't returned from the interrupt service routine by the time that another interrupt comes along. This causes the processor to miss a count, which over time will lead to a large position error.

This will be the main type of problem that you'll see, especially if you try to close any high speed loops.

Nested interrupts are not a problem if you take special consideration and re-enable the GIE flag. The processor has a 31 level deep hardware stack. As long as you don't overflow that you are fine. The problem is not with nested interrupts but in too many of them overflowing the stack. Note: the way the default code it setup, nested interrupts will be ignored. You will have to rewrite it to determine the source of the interrupt, clear the appropriate flag, reset the GIE flag, and then do you interrupt processing. Just be careful to avoid odd race condiditions etc. Everything I said above applies only to low priority interrupts. If you do not know the difference then you are using low priority interrupts and everything i jsut said applies.

[Rickertsen2]

Originally Posted by Mark McLeod

Most of the problems with the processor keeping up that I've run across with various teams have been due to inefficient and bloated code. They more often run out of programming space than processor time. The most common exception has been bloated interrupt handlers causing multiple interrupts to be missed. The code problems are to be expected with people learning to program for the first time and attempting to implement complex equations from their math textbook.
The cautions are more directed at the neophytes than experienced programmers.

I did some measurements last Fall on the Robovation (formerly EDU) controller and came up with:
v45% more program space than the equivalent operation using integer math is what’s roughly required for simple floating-point operations (e.g., a=10.5*2.3 vs i=105*23)
v22% more time is required for equivalent float vs. integer operations

I no longer remember the details as to what percentage of program space was due to a one time floating point library and what each additional statement demands. It just takes a minute or two to run the test though.

Where did you come up with these figures? The time difference btw float and fixed/decimal depends on the operation. For some operations its not that great. For others it is very large. Same with the instruction cycles.

[Matt Leese]

Originally Posted by Rickertsen2

Where did you come up with these figures? The time difference btw float and fixed/decimal depends on the operation. For some operations its not that great. For others it is very large. Same with the instruction cycles.

I haven't done any real investigating into this but I'm going to have to say that it is almost guaranteed that a floating point operation will take an order of magnitude longer than the corresponding integer operation. For processors with a floating point unit, floating point operations take significantly longer than integer operations. Given that the PIC has to emulate floating point operations, what may be a one cycle operation (say, adding two integers) may take many more cycles because of all the additional operations required to unpack the floating point, perform the operation, and then repeat it.

Floating point operations on this processor will take much longer than integer operations. However, this may or may not be significant depending on other factors.

Matt