What length delays are causing the trouble? It certainly seems very odd that the length of the delay should increase as the clock speed goes down. How are you changing the speed of the internal osc?
GCBASIC has been thoroughly tested on the 16F628A, 16F819, 16F88 and 16F877A. Of these, I've tried the hardware PWM on the 819 and the 877A. The 88 and 628A appear to have an identical PWM module, so they should both be fine too.
Some more things you may wish to try for hardware PWM:
-Check the P1M1 and P1M0 bits of CCP1CON. Remember to set CCPCONCache, not CCP1CON
-Check the direction of PORTC.5 - it must be an output.
-See if the PWM is coming out on another port. I had trouble with PWM on the 16F819, until I realised that I had set it to use B2 rather than B3 for output.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Speed is set by
#16f684,8 or #16f684,1 or #16f684,.o32 (I know that seems wierd, but it made a change in delay speed!).
Code is: 'Led Chaser with multiple Leds
blah
blah
#define Blink 50 ms
#define BlinkOverLap 20 ms
blah
blah
set PortC.2 On
wait Blink
set PortC.1 On
wait BlinkOverLap
wait Blink
set PortC.0 On
wait BlinkOverLap
set PortC.2 Off
wait Blink
set PortA.2 On
wait BlinkOverLap
set PortC.1 Off
etc.
When clock speed goes down (i.e. say from 8Mhz to 1Mhz), the lights blink much faster, so the delay is smaller.
On the PWM, I had a 16f648a, which I think is similar to the 16f628a, but it is now locked up and waiting for a new arrival.
I will evaluate your suggestions on PWM later, as my eyes are going blurry looking at data sheets. On the 16f684 CCP1(PWM) is RC5.
Thanks,
Kent
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The #chip line doesn't actually change the clock speed of the chip - it merely tells GCBASIC what the clock rate of the chip is so that it can calculate delays correctly. To change the speed of the chip, you'll need to alter OSCCON according to the datasheet. The line
OSCCON = OSCCON AND 112
should set it to full speed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Finally got PWM going. Thanks for the encouragement.
The folowing observations are noted with the 16f684. These could very well be influenced by my inexperience, using only a DVM, and initializations.
The PWM module in the include file is not exactly plug and play. There seems to be some magic numbers for Mhz, PWM freq., PWM duty, and of course the system clock. Perhaps the bit resolution undercuts the maths done in the script?
Problems encountered:
1) Must start out with PWM_Freq. around 25 and lower, anything higher looks like dc.
2)Freqency out is half the value.
3)PWM_Duty doesn't like being lower than about 25%.
4)PWM_Duty out varies depending on PWM_Freq. and?
Semi magic number Mhz=8, OSCON = OSCON AND 112 (8MHZ clock), PWM_Freq = 2 (1KHZ), PWM = 25 (PWM out equals value in). Others may apply but tired of punching the program buttons.
Regards,
Kent
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As internal osc speed is reduced, delay routines speed up. Why is that so?
Thanks,
Kent
P.S. Still no luck with PWM on 16f684, maybe I should just get an 16f877a where most everything has already been debugged?
What length delays are causing the trouble? It certainly seems very odd that the length of the delay should increase as the clock speed goes down. How are you changing the speed of the internal osc?
GCBASIC has been thoroughly tested on the 16F628A, 16F819, 16F88 and 16F877A. Of these, I've tried the hardware PWM on the 819 and the 877A. The 88 and 628A appear to have an identical PWM module, so they should both be fine too.
Some more things you may wish to try for hardware PWM:
-Check the P1M1 and P1M0 bits of CCP1CON. Remember to set CCPCONCache, not CCP1CON
-Check the direction of PORTC.5 - it must be an output.
-See if the PWM is coming out on another port. I had trouble with PWM on the 16F819, until I realised that I had set it to use B2 rather than B3 for output.
Speed is set by
#16f684,8 or #16f684,1 or #16f684,.o32 (I know that seems wierd, but it made a change in delay speed!).
Code is: 'Led Chaser with multiple Leds
blah
blah
#define Blink 50 ms
#define BlinkOverLap 20 ms
blah
blah
set PortC.2 On
wait Blink
set PortC.1 On
wait BlinkOverLap
wait Blink
set PortC.0 On
wait BlinkOverLap
set PortC.2 Off
wait Blink
set PortA.2 On
wait BlinkOverLap
set PortC.1 Off
etc.
When clock speed goes down (i.e. say from 8Mhz to 1Mhz), the lights blink much faster, so the delay is smaller.
On the PWM, I had a 16f648a, which I think is similar to the 16f628a, but it is now locked up and waiting for a new arrival.
I will evaluate your suggestions on PWM later, as my eyes are going blurry looking at data sheets. On the 16f684 CCP1(PWM) is RC5.
Thanks,
Kent
The #chip line doesn't actually change the clock speed of the chip - it merely tells GCBASIC what the clock rate of the chip is so that it can calculate delays correctly. To change the speed of the chip, you'll need to alter OSCCON according to the datasheet. The line
OSCCON = OSCCON AND 112
should set it to full speed.
Finally got PWM going. Thanks for the encouragement.
The folowing observations are noted with the 16f684. These could very well be influenced by my inexperience, using only a DVM, and initializations.
The PWM module in the include file is not exactly plug and play. There seems to be some magic numbers for Mhz, PWM freq., PWM duty, and of course the system clock. Perhaps the bit resolution undercuts the maths done in the script?
Problems encountered:
1) Must start out with PWM_Freq. around 25 and lower, anything higher looks like dc.
2)Freqency out is half the value.
3)PWM_Duty doesn't like being lower than about 25%.
4)PWM_Duty out varies depending on PWM_Freq. and?
Semi magic number Mhz=8, OSCON = OSCON AND 112 (8MHZ clock), PWM_Freq = 2 (1KHZ), PWM = 25 (PWM out equals value in). Others may apply but tired of punching the program buttons.
Regards,
Kent