| View previous topic :: View next topic |
| Author |
Message |
matheuslps
Joined: 29 Sep 2010
Posts: 73
Location: Brazil
|
| Why FFT.h do not compile on 18F? |
 Posted: Sat Nov 30, 2013 9:11 pm |
 |
|
I tried to do a simple test with the FFT.H and it is returning a EXPECTING AN OPCODE MNEMONIC error on the FFT.H file when the asm file begins.
I tried with the 18F4550 and the 18F25K20.
http://i.imgur.com/XtnSxSW.png
Compiler 5.013 |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sat Nov 30, 2013 10:38 pm |
|
|
fft.h is an include file in FFT_filter.c, which is an include file in:
| Quote: | | c:\program files\picc\examples\ex_fft_filter.c |
Here's the first part of that example file:
| Quote: | #include <33fj128gp706.h>
#fuses HS, PR_PLL, NOWDT
#use delay(crystal=12M, clock=80M) //40 MIPS
/* Define the FFT length and include the FFT_filter library */
#define FFT_LENGTH 256
#include "FFT_filter.c" |
The routines are designed for a dsPIC33. They are not general purpose
routines. |
|
|
matheuslps
Joined: 29 Sep 2010
Posts: 73
Location: Brazil
|
|
| Posted: Sun Dec 01, 2013 10:56 am |
|
|
HUm..... OK I got the reason.
I tried to reproduce this FFT example but I do not have a 33FJ128GP706 from the example here. I just have a 33FJ32MC202 and a 33FJ32GP202 available. But since I never worked with dsPic, I was having problems with fuses setup.
On the datasheet, it says that this chips has a FRC clock to startup and after a time it will use the external one with PLL to obtain 80Mhz. Too confusion for me. That is because I tried to use the 18F ones.
But thanks again. Problem solved.
bye |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19520
|
|
| Posted: Sun Dec 01, 2013 12:06 pm |
|
|
Generally, don't worry about the clock rates!...
If you have a crystal in the legitimate input range for the PLL (data sheet), just specify it all in the clock statement. So crystal=xxxMHz, clock=yyyMHz. The compiler will calculate the ratios needed. All of these chips start on FRC. The PLL, has programmable prescale, ratio, and postscale, allowing often dozens of permutations to give particular frequencies, hence it is much easier to let the compiler calculate these. It's one of the things that CCS 'by and large' gets right. 
Best Wishes |
|
|
matheuslps
Joined: 29 Sep 2010
Posts: 73
Location: Brazil
|
|
| Posted: Sun Dec 01, 2013 1:12 pm |
|
|
| Ttelmah wrote: | | So crystal=xxxMHz, clock=yyyMHz. The compiler will calculate the ratios needed. |
That is a good! My confusion was right there because on 18F chips we have a lot off PLL div fuses to obtain the right 48Mhz for USB operation.
When I opened the .h file for the dsPIC33 chips, I did not find the divs fuses. But now I know why. I can go back to test again.
Thanks. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19520
|
|
| Posted: Sun Dec 01, 2013 3:33 pm |
|
|
Most of this is not programmed through the fuses on these. This is one reason 'why' they have to wake up using FRC.
The PLL, is an entire huge block in it's own right. You have programmable division by 2 to 33 from the clock to the PLL. Then programmable multiplication by 2 to 513. Then /2, 4 or 8 after this. So for 80MHz out you would need 160MHz from the PLL (since it allows frequencies between 100, and 200MHz, and this is the only one that would give 80MHz). Then the multiplication could be anything from 20 to 200, so allowing input frequencies between 8MHz, and 0.8MHz, with the division in front allowing clocks going from 1.6MHz, up to the oscillator limits of the chip. Ouch!....
Best Wishes |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
