[sdiy] IIR Shift Filter problem - help with bug spotting in PIC ASM
rburnett at richieburnett.co.uk
Fri Mar 10 16:14:27 CET 2017
> And yeah, Richie, you're right…I suppose I have to use the simulator and
> see what it can tell me. It's a drag but sometimes an unavoidable
At least it's a purely algorithmic issue, so you don't have to worry about
running it on the target hardware or setting up a stimulus file. And you
know it works for positive numbers but fails for some reason on negative
ones, so shouldn't be too hard to single-step through with the simulator and
see where a wheel falls off.
I must confess I haven't had time to examine your two code examples, but
when I mess up using shifts/rotates for maths, it's usually one of the
1. Used rotate where should have used a shift operation
2. Used rotate through carry, when should have been rotate without carry.
3. Used rotate through carry with unknown previous carry flag status
(probably should have BCF STATUS,#C first to clear carry flag)
4. Used a logical right shift where it should have been an arithmetic shift
to sign-extend a negative number.
Those are the things that have bitten me in the past.
Re writing to the PIC status register the issue is this:
If for instance you were to use a logic instruction like "IORWF" to modify
the STATUS register so that the ZERO flag bit is *SET* this causes a
1.ORing a number with the STATUS register results in a value that has a one
in the ZERO flag position, so the ZERO flag should be set by this operation.
2. ORing this number with the STATUS register results in a new value that
has at least one bit set, which clearly isn't a result that equals zero, so
the result of the IORWF operation should clear the ZERO flag!
One or other will take priority, and I can't remember which one. You can
modify to the STATUS register safely. The way to do this is to use BCF and
BSF, SWAPF or MOVWF, because they don't implicitly modify the STATUS flags
based on their result.
More information about the Synth-diy