Was hoping to change PWM_Duty on the fly. But, running into a problem on trying to stuff a variable from main program into the PWM include file. Shifted the #scriptend to exclude the DutyCycle calc's, to no avail, although it did compile.
This is what I was trying to do in main program:
PWM_Duty =25
n = 1
For n = 1 to 75
PWM_Duty = PWM_Duty + 1
PWMOn
next n
Basically trying to ramp up/down led, motor, etc.
Thanks,
Kent
P.S. Commented out the #define PWM_Duty 25 in include file
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
DutyCycle, DutyCycleH and DutyCycleL are all constants in the current version of GCBASIC. They can only be set using #defines, or a script.
The reason for the script is that when I wrote the PWM routines, GCBASIC could not support large integers. This would have made it difficult to work with 10-bit values on the PIC, so I added the script to have the compiler do the calculations instead.
Now that 16-bit variables are supported, it shouldn't be too hard to perform the calculations in the program on the PIC. I'll implement this in the next version of GCBASIC.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks on PWM. Yes, I saw that word variables now supported, excellent.
PWM was a real slog for sure, probably because of using slower internal OSC, rather than a 20 Mhz crystal, more than anything? Also some influence had by external circuitry. Get this, the PWM Duty cycle changed, when exiting the PicKit1/Classic Compiler, to lower duty cycle values. Tried a .1uf from Port pin to ground, no good, then .oo1uf cap, which seemed to help some. This phenomenom is a mystery! Perhaps some capacitance built up in the DVM?
The idea that some defined constant or variable for that matter, will not work in a Do Loop, or For n = x to y next n type Loop is worrisome. I can think of many instances where I would like to use such syntanx. Hopefully this is a isolated instance?
Regards,
Kent
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Whenever I try and measure PWM output, I tend to get a reading of 5 volts that occasionally drops to 3 or so. DVMs don't seem to handle rapidly changing voltages too well!
I've found that the hardware PWM on the PIC can be a little hard to get on with myself, so I only use it if I absolutely need to. It's generally easier to write a 5 or so line software PWM routine.
What do you mean when you say that a defined constant or variable will not work in a Do or For loop?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here, here on going the software PWM route, will try next. Although the 16f684 is supposed be configurable as an h-bridge, its probably easier to feed a few dollar external h-bridge.
"What do you mean when you say that a defined constant or variable will not work in a Do or For loop?"
Well, I am sure this was my mis-understanding of the GCBasic command guide. The statement from the compiler directives which include commands such as, #define Const value:
"Important: Compiler directives should not be in subs or functions! (Except #IFDEF, #ENDIF, #SCRIPT, and #ENDSCRIPT):"
I took the above statement at face value, especially when I couldn't get the PWM_Duty to do its thing in aforementiond Do Loop. And as you have stated, this is quite another problem.
Regards,
Kent
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Compiler directives" refers to things that start with # - #include, #define, #mem, etc. That rule will be gone completely in the next version of GCBASIC.
It means that code like this will not work:
sub Test
#define Threshold 40
set PORTB.0 on
end sub
but this will:
#define Threshold 40
sub Test
set PORTB.0 on
end sub
That rule should have gone when I re-wrote the preprocessor back in version 0.7! Thanks for reminding me of it, and sorry for the confusion!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Whenever I try and measure PWM output, I tend to get a reading of 5 volts that occasionally drops to 3 or so. DVMs don't seem to handle rapidly changing voltages too well!
Russ says:
It is really nice to have a scope. But if you do not you can make a low pass filter and measure the output from it. Say a 1 meg resistor into a .5 uF cap. ( output pin to res, res to cap, cap to ground ) This has rc = .5 sec which should give a pretty constant output ( across the cap ) for the dvm ( drawn down a bit by the input res of the dvm ). The fraction of 5 volts that you get is the duty cycle: 3 volts = 60%. Better value might be chosen for r and c depending on what you have around, the frequency of the pwm, and your dvm. russ_henesel at yahoo.com
Russ
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Was hoping to change PWM_Duty on the fly. But, running into a problem on trying to stuff a variable from main program into the PWM include file. Shifted the #scriptend to exclude the DutyCycle calc's, to no avail, although it did compile.
This is what I was trying to do in main program:
PWM_Duty =25
n = 1
For n = 1 to 75
PWM_Duty = PWM_Duty + 1
PWMOn
next n
Basically trying to ramp up/down led, motor, etc.
Thanks,
Kent
P.S. Commented out the #define PWM_Duty 25 in include file
Glad to hear that you got PWM working!
DutyCycle, DutyCycleH and DutyCycleL are all constants in the current version of GCBASIC. They can only be set using #defines, or a script.
The reason for the script is that when I wrote the PWM routines, GCBASIC could not support large integers. This would have made it difficult to work with 10-bit values on the PIC, so I added the script to have the compiler do the calculations instead.
Now that 16-bit variables are supported, it shouldn't be too hard to perform the calculations in the program on the PIC. I'll implement this in the next version of GCBASIC.
Thanks on PWM. Yes, I saw that word variables now supported, excellent.
PWM was a real slog for sure, probably because of using slower internal OSC, rather than a 20 Mhz crystal, more than anything? Also some influence had by external circuitry. Get this, the PWM Duty cycle changed, when exiting the PicKit1/Classic Compiler, to lower duty cycle values. Tried a .1uf from Port pin to ground, no good, then .oo1uf cap, which seemed to help some. This phenomenom is a mystery! Perhaps some capacitance built up in the DVM?
The idea that some defined constant or variable for that matter, will not work in a Do Loop, or For n = x to y next n type Loop is worrisome. I can think of many instances where I would like to use such syntanx. Hopefully this is a isolated instance?
Regards,
Kent
Whenever I try and measure PWM output, I tend to get a reading of 5 volts that occasionally drops to 3 or so. DVMs don't seem to handle rapidly changing voltages too well!
I've found that the hardware PWM on the PIC can be a little hard to get on with myself, so I only use it if I absolutely need to. It's generally easier to write a 5 or so line software PWM routine.
What do you mean when you say that a defined constant or variable will not work in a Do or For loop?
Here, here on going the software PWM route, will try next. Although the 16f684 is supposed be configurable as an h-bridge, its probably easier to feed a few dollar external h-bridge.
"What do you mean when you say that a defined constant or variable will not work in a Do or For loop?"
Well, I am sure this was my mis-understanding of the GCBasic command guide. The statement from the compiler directives which include commands such as, #define Const value:
"Important: Compiler directives should not be in subs or functions! (Except #IFDEF, #ENDIF, #SCRIPT, and #ENDSCRIPT):"
I took the above statement at face value, especially when I couldn't get the PWM_Duty to do its thing in aforementiond Do Loop. And as you have stated, this is quite another problem.
Regards,
Kent
"Compiler directives" refers to things that start with # - #include, #define, #mem, etc. That rule will be gone completely in the next version of GCBASIC.
It means that code like this will not work:
sub Test
#define Threshold 40
set PORTB.0 on
end sub
but this will:
#define Threshold 40
sub Test
set PORTB.0 on
end sub
That rule should have gone when I re-wrote the preprocessor back in version 0.7! Thanks for reminding me of it, and sorry for the confusion!
Hugh Considine said:
Whenever I try and measure PWM output, I tend to get a reading of 5 volts that occasionally drops to 3 or so. DVMs don't seem to handle rapidly changing voltages too well!
Russ says:
It is really nice to have a scope. But if you do not you can make a low pass filter and measure the output from it. Say a 1 meg resistor into a .5 uF cap. ( output pin to res, res to cap, cap to ground ) This has rc = .5 sec which should give a pretty constant output ( across the cap ) for the dvm ( drawn down a bit by the input res of the dvm ). The fraction of 5 volts that you get is the duty cycle: 3 volts = 60%. Better value might be chosen for r and c depending on what you have around, the frequency of the pwm, and your dvm. russ_henesel at yahoo.com
Russ