| View previous topic :: View next topic |
| Author |
Message |
mfeinstein
Joined: 05 Jul 2012
Posts: 35
|
|
 Posted: Tue Sep 04, 2012 6:36 pm |
 |
|
jeremiah,
That's exactly what I understood! But by this explanation the Timer0 interrupt will be disabled until the delay_ms(1000) stops running, right? So, since the Timer0 is setup to interrupt at every 500us I will expect to get instead an interrupt at every 1000ms...right? But I am getting an interrupt at every 250ms...and not at every 1000ms as expected by the interrups disable made by the compiler...see...that's my question..."why?" |
|
 |
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Tue Sep 04, 2012 6:46 pm |
|
|
i don't agree about anything much. ask my wife 
by SIMPLE i mean THIS first:
| Code: |
#include <18F2550.h>
#FUSES PLL5 //Divide By 5(20MHz oscillator input)
#FUSES CPUDIV1 //Configurado errado pelo wizard... CPUDIV
#FUSES HSPLL //High Speed Crystal/Resonator with PLL led
#use delay(clock=48000000)
#define LED PIN_B3
#bit T0IF = 0xFF2.2 // getenv("BIT:TMR0IF");
void main(void){
setup_timer_1(T1_INTERNAL|T1_DIV_BY_2); // DUH irrelevant
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_256);
T0IF=0; //init
while(1) {
// will be 1.4 second ON/off cycle if REALLY 48mhz
if (T0if){ output_toggle(LED); T0IF=0;}
}
}
|
do you see the correct rollover rate or NOT ???
if NOT you don't have the clock you think you do
that would explain a lot
i meant REALLY basic to PROVE w/o INTS that timer0 has the proper delay statement for the actual FREQ you are spinning at,
which i very much doubt.
and i have 2 say - that awful delay statement in your fast timer1 ISR is STILL a disaster that nobody in their right mind should EVER do.......
the bad timing there makes my head spin. |
|
|
mfeinstein
Joined: 05 Jul 2012
Posts: 35
|
|
| Posted: Tue Sep 04, 2012 6:54 pm |
|
|
asmboy, as far I can see in your code, you arent using any interrupts, just polling them right? Why?
In any case, I am 100% sure my clock is ok...I already made many many tests (that's why I had a "output_toggle(LED); return;" in my original code...just to check the interrupt rates...and it is interrupting fine for values from 500 microsencons to 5 seconds (there are at least some 13 different values I tested...e.g. 100ms, 250ms, 500ms etc..), so clock isnt the problem...remember to test the interrupt I just have to comment the delays ;) |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1362
|
|
| Posted: Tue Sep 04, 2012 7:01 pm |
|
|
| I may have missed it in an earlier post, but what actual oscillator are you using physically for the PIC? Your setup looks funky. You specify a divide by 5 PLL with a 20MHz input in the fuses, then say the clock is 48MHz in the #use delay() statement, which doesn't make sense to me. I would expect a 4MHz there instead. |
|
|
mfeinstein
Joined: 05 Jul 2012
Posts: 35
|
|
| Posted: Tue Sep 04, 2012 7:07 pm |
|
|
| jeremiah...48MHz for sure...go to the datasheet and look at the oscillator part...in order to use the PLL to achieve 48MHz you have to assure 4MHz before ;) |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1362
|
|
| Posted: Tue Sep 04, 2012 8:35 pm |
|
|
| mfeinstein wrote: | | jeremiah...48MHz for sure...go to the datasheet and look at the oscillator part...in order to use the PLL to achieve 48MHz you have to assure 4MHz before ;) |
Yes, but you are not using the FUSES for the 48MHz. You are using the FUSES for the 20MHz crystal. You should be using PLL12 instead of the PLL5 you are using. Take a look at the datasheet for the different PLL settings.
Theoretically, using a smaller divisor would give you an overall faster clock, which would explain your issue (since you are delaying shorter than expected), but I don't know how the PLL actually handles inputs higher than 4MHz (you are feeding it 9.6 MHz).
Also, for the PLL divider part at the end, it might be more worthwhile to specify your #use delay() statement a bit more detailed. Something like:
| Code: | | #use delay(crystal=48000000,clock=48000000) |
that way the "divide by 2" option will be selected by the compiler rather than the "divide by 6" option for example
EDIT: Also, if you aren't using USB, you can just pipe the 48MHz crystal straight through and bypass the PLL altogether. |
|
|
mfeinstein
Joined: 05 Jul 2012
Posts: 35
|
|
| Posted: Tue Sep 04, 2012 9:09 pm |
|
|
jeremiah,
I am sure my FUSES are all right...the delays work fine, so does the timers (when there are no reentracy functions of course)...and I am using USB.
I get the 20MHz and divide it by 5 getting 4MHz and then I use the PLL configuration to jump it to 48MHz...CPUDIV makes the magic... (be aware CPUDIV have a trick in this model, since there are ambigous values.....look at the datasheet and you will see it) |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1362
|
|
| Posted: Tue Sep 04, 2012 9:20 pm |
|
|
| mfeinstein wrote: | jeremiah,
I am sure my FUSES are all right...the delays work fine, so does the timers (when there are no reentracy functions of course)...and I am using USB.
I get the 20MHz and divide it by 5 getting 4MHz and then I use the PLL configuration to jump it to 48MHz...CPUDIV makes the magic... (be aware CPUDIV have a trick in this model, since there are ambigous values.....look at the datasheet and you will see it) |
That's fine, but it was opposite what you told me in your previous post. When I asked you what oscillator you were using, you replied with 48MHz. Now you say 20MHz. It's hard to keep track unless you supply the correct information. |
|
|
mfeinstein
Joined: 05 Jul 2012
Posts: 35
|
|
| Posted: Tue Sep 04, 2012 9:31 pm |
|
|
Sorry...I was in a hurry and thought about clock instead...
in any case, the crystal is written in the code as "20MHz oscillator input"...and I am sorry to be rude but "keeping track" also means reading the previous posts ;) |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1362
|
|
| Posted: Tue Sep 04, 2012 9:50 pm |
|
|
| mfeinstein wrote: | Sorry...I was in a hurry and thought about clock instead...
in any case, the crystal is written in the code as "20MHz oscillator input"...and I am sorry to be rude but "keeping track" also means reading the previous posts ;) |
Since you wish to intentionally be rude, I will stop trying to help. I don't have time for that. I was honestly trying to figure out why you had issues. I bid you good luck on figuring it out and hope you find out why it isn't working. I know such problems can be exasperating sometimes. |
|
|
mfeinstein
Joined: 05 Jul 2012
Posts: 35
|
|
| Posted: Tue Sep 04, 2012 10:01 pm |
|
|
jeremiah, I dont "wish" to be rude, but it is kind of offensive to read stuff as "unless you supply the correct information.", " Your setup looks funky", "You're not understanding what they are saying", specially when most of this stuff already were covered in previous posts. I thank you for your time and help, but your language was kinda offensive for me....
(english is not my main language so I might have understood you wrongly, its hard to know on the web sometimes...) |
|
|
mfeinstein
Joined: 05 Jul 2012
Posts: 35
|
|
| Posted: Thu Sep 06, 2012 11:25 am |
|
|
Guys, problem solved! Ttelmah was completely right and FvM gave me the final answer: The answer why you see a 250 ms interrupt lock instead of 1000 ms in your code. It's due to the fact that the compiler splits the delay into 4 repeated calls of the basic delay function, as you can see in the assembly listing.
I want to thank you all for the help and patience! Especially Ttelmah and FvM for helping me one more time! |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
