'Scale error in AN616 digital filter code?'
|To any digital signal processor types out there:
I'm replacing my PID module with a more general IIR filter-based
module for a digital control system. The algorithm and code in AN616
seems usable if a little sparse on documentation. There seems to be a
discrepency in the definitions for where the LSB's and MSB's are
stored in the IIR code module, IIRfilt.c.
The filter() function documentation states that the
"output is in MSB of y_n (y_n=MSB, y_n+1
yet the code inside the function uses the reverse definition, ie:,
y_n+1=MSB. For example, the following code:
I assume here that the MSB of any result would be stored in a variable
called xxxxHI. This is rectified in the last two lines of code, where
the MSB stored in y_n+1 is moved to y_n so it looks like an 8-bit
result for the main calling program to use. Okay, I can deal with
However, the scale_y_n routine called _just previously_ to this seems
to require that the LSB _is_ in y_n+1, but only in the start_scale
segment of code. The scale by 8 should left shift the LSB into the
MSB but the code is actually the reverse:
bcf status,c ; clear carry
rlf y_n+1 ; and rotate y(n) left
which seems to rotate the MSbit into the LSbit, while 0's are rotated
into the right side of the MSB. Hmmm, this doesn't seem right. But
it might not have been too noticable in testing since the LSB is
thrown away anyway.
Can anyone shed some public light on this?
While you're here, is anyone interested in trading a reasonably well
documented IIR canonical form filter software module similar to that
in AN616 for my pretty well documented PID control software module?
Please reply privately.
Paul Bjork wrote...
>To any digital signal processor types out there:
>I'm replacing my PID module with a more general IIR filter-based
>module for a digital control system. The algorithm and code in AN616
>seems usable if a little sparse on documentation. There seems to be a
>discrepency in the definitions for where the LSB's and MSB's are
>stored in the IIR code module, IIRfilt.c.
I'm not a DSP type, but I can comment on 16 Bit numbers and ApNotes.
I always put my 16 Bit numbers in "Intel" format (Least Significant Byte at
the First (Lowest) Address, Most Significant Byte at the Next (Least
Significant Byte Address + 1) Address) as opposed to the "Motorola" format
(Most Significant Byte at the First address, Least Significant Byte at the
Next Address). For just this reason. I realize it makes the numbers a bit
harder to read when you're looking at a dump of the file registers, but I've
got too much history with Intel Processors to change.
I've found the same problem (as well as a few others) in the ApNotes.
If I'm using the ApNotes for reference, I always read thru them line by line
and make sure that I understand them inside and out before using them. I
have found that you have to be very careful when you use sections of them.
I'm not saying their of poor quality and are unusable, just that some errors
have crept in and the code, which is specified for certain PICs, may not be
usuable in others because of different register addresses and functions.
Do you ever feel like an XT Clone caught in the Pentium Pro Zone?
More... (looser matching)
- Last day of these posts
- In 1996
, 1997 only
- New search...