digital integrator algo for bipolar sigs?

[pwhitt]

I am using an 18F4520 in a PI control loop and am having problems with the integrator code that I suspect may have been more elegantly dealt with by others. I'd love to see examples or suggestions from those with more experience.

Currently I am able to generate the error signal and was previously using an external analog integrator. To move the integration into the PIC I have to overcome several things - mainly that the integrator doesn't just sum, it subtracts when the new value is below zero (in this case my signals going into the PIC are between 00 and FF, with 7F corresponding to zero in the analog portions). There must also be checks so that values below 00 or above FF saturate, not roll over.

I cannot imagine that I am the only person to do this in this way, and there must be a simpler way to approach it rather than to use a separate PIC to integrate - or use a series of nested IF/THEN statements that slows things dramatically.

[Darrel Taylor]

Hi pwhitt,

Although it was written for the Basic Stamp, you may find this usefull.

http://www.parallax.com/dl/docs/books/edu/ic.pdf

Look at experiment #6<br><br>

[pwhitt]

Thanks Darrel,

This is actually a slower approach than what I am doing. It is more nicely coded - but the branching would greatly reduce the speed. I'm trying to run a loop that will iterate at over 100kHz, and I am not concerned with regular periodicity, ie if it runs a few times at 125kHz and a few periods are at 110kHz all is well.

i have proportional control running at 800kHz. However when i add the integral calculation, check for saturation and sum the result, it's at nearly 50kHz. I've managed to get the calculations as clean as possible, but the IF/THENs are killing me.

I was really hoping a CE out there would have a suggestion as to how to deal with this. For instance, the first condition in my current loop checks to see if the result is between 00 and FF, then writes it, then immediately returns to the sample. It only checks for saturation if that condition fails, resulting in an aperiodic signal, but it is only slow when the output is saturated - so I'm not worried about that.

Even if it requires raw assembly I'll be happy to implement it. I'm also trying to come up with a very long routine that would branch only once or twice while continusously resampling and writing when not saturated.