Re: Problem with PSECT in assembly file
I am amazed to get so many replies and so much advice.
1/- I must admit that I have only tried the assembler routine on the simulator.
2/- The filter that I am trying to program is a 4th order elliptic lowpass made with two biquad sections. The filter has a cutoff frequency of 3uHz, and is only updated once every 20.48 seconds. The cut off normalised to the sampling frequency is 61E-6fs. This is a very narrow band filter and is very sensitive to quantization errors in the calculations.
My first attempt used 32 bit float for all the coefficients and registers, This was the direct form type 2. This filter works on the hardware, however the quantization noise is very high. This was the reason why I am trying a fixed point version. I have not yet got this to work, even with the simulator.( The software I am using for the filter design is Iowa Hills IIR filter designer. This is free on the Internet, and I highly recommend it.)
I think that the type 2 implementation will have less quantization noise, so my next step is to try this using floating point. If this is OK, I will thankfully move on to other parts of the algorithm.
3/- When speed is unimportant, I spend no time on optimizing a routine. My fixed point filter version only takes 511us, at 10MIPS. Even code space is unimportant as if I run out on the 18F46K42, I can always use the 18F47K42.
4/- Looking at the disassembly listing, the linker has converted all the MOVFFs into MOVFFLs.
5/- PRODL and PRODH are definitely in the access bank. I have had problems before with special function registers not in the access bank. Happily the C compiler takes care of the addressing.
6/- I used to program pretty much exclusively in assembler, but now work in C 99.9% of the time. Where speed really is important, I prefer assembler, as one can optimise better. An earlier post I made referred to a 64 by 64 divide routine which used the hardware divide instructions on the dsPIC33E.
As an aside, I think there is a hardware bug in the SPI on the 46K42. I get occasional data errors if interrupts are running when using the receive FIFO. This is the subject of a current ticket with Microchip.