| View previous topic :: View next topic |
| Author |
Message |
Killer_te
Joined: 19 Jul 2010
Posts: 1
|
| Help me how to config PIC24FJ128GB110 run on 32Mhz |
 Posted: Mon Jul 19, 2010 6:55 am |
 |
|
Hello
Please tell me how to config PIC24FJ128GB110 run on 32Mhz by CCS C with internal crystal is 8Mhz? and config #fuses? for uart
| Code: |
#include <24FJ128GB110.H>
#include <stdio.h>
#fuses ...?
#use delay (...?)
#use rs232(baud=9600,...)
void main()
{
while(1)
{
printf("HELLO WORLD \n\r");
delay_ms(1000);
printf("TEST");
}
}
|
Thank you very much. |
|
 |
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Mon Jul 19, 2010 10:17 am |
|
|
You can try below settings. Please consider, that the internal fast RC oscillator isn't crystal accurate. UART baudrates may be critical for extended temperature or power supply range without oscillator calibration. FRC doesn't work for USB in any case.
| Code: | #fuses FRC_PLL,PLL2
#use delay(clock=32M,internal) |
|
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA
|
|
| Posted: Mon Jul 19, 2010 1:10 pm |
|
|
| FvM wrote: | You can try below settings. Please consider, that the internal fast RC oscillator isn't crystal accurate. UART baudrates may be critical for extended temperature or power supply range without oscillator calibration. FRC doesn't work for USB in any case.
| Code: | #fuses FRC_PLL,PLL2
#use delay(clock=32M,internal) |
|
If he uses #use delay (clock=32M, internal)
He may not need the #fuses FRC_PLL, PLL2
But I would definitely test it -- and then keep an eye.
-- but otherwise, yes. What FvM said.
;)
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
Cityboy
Joined: 09 Jul 2010
Posts: 3
|
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Wed Jul 21, 2010 8:46 am |
|
|
It will mostly cause confusion because dsPIC PLL operation is different from PIC24FJxxGB.
The settings can be basically derived from PIC24 datasheet. The only surprizing point is which #fuse setting will automatically set from #use delay() statement and which won't. Although bkamen's assumption, that the PLL fuses should be automatically set isn't wrong, they actually won't. |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA
|
|
| Posted: Wed Jul 21, 2010 11:44 am |
|
|
| FvM wrote: | It will mostly cause confusion because dsPIC PLL operation is different from PIC24FJxxGB.
The settings can be basically derived from PIC24 datasheet. The only surprizing point is which #fuse setting will automatically set from #use delay() statement and which won't. Although bkamen's assumption, that the PLL fuses should be automatically set isn't wrong, they actually won't. |
But I said to double check it and watch it.
It's worked on some things for me in the past...
But considering all the other issues I have with CCS with code that works today, is to assume it may not tomorrow.
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Wed Jul 21, 2010 12:55 pm |
|
|
| Quote: | | It's worked on some things for me in the past... |
Right, I also remember a case, when I was surprised about the "intelligence" of the CCS compiler in setting meaningul #fuse parameters from a #use delay() statement. The problem is however, that there's no documented functionality in this regard, as far as I see.
In the present case, without specifying FRC_PLL, no PLL mode was activated, and then, the PLL divider was set to PLL12 by default, which had to be corrected to PLL2. |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA
|
|
| Posted: Wed Jul 21, 2010 12:57 pm |
|
|
| FvM wrote: | | Quote: | | It's worked on some things for me in the past... |
Right, I also remember a case, when I was surprised about the "intelligence" of the CCS compiler in setting meaningul #fuse parameters from a #use delay() statement. The problem is however, that there's no documented functionality in this regard, as far as I see.
In the present case, without specifying FRC_PLL, no PLL mode was activated, and then, the PLL divider was set to PLL12 by default, which had to be corrected to PLL2. |
Blah.
3 cheers for consistency.
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
