Re: Fading LEDs using a PWM signal from the Edubot
 

er, what I really need is for someone to point out what timer 2 actually does in the beacon code. I can see that it counts at 40KHz, but where is the code that does something with that 40KHz count? What happens once the timer counts its 250 ticks and where is the code for that?

Re: Fading LEDs using a PWM signal from the Edubot
 

It's all done automatically in hardware. See page 154 of the data sheet. Here is example code that does what you need. It simulates a light dimmer by reading the voltage on analog input 1 and adjusts the LED brightness proportionally to the voltage read.

-Kevin

Re: Fading LEDs using a PWM signal from the Edubot
 

User_Initialization, step 5 (see previous post)

Re: Fading LEDs using a PWM signal from the Edubot
 

It occured to me that you should be able to try the code (posted above) without an external driver because IFI has built in the current limiting resistors on the PWM outputs. Just attach the LED cathode (shorter of the two leads) to the ground pin and the anode to the PWM 1 or 2 outputs. If you don't have a potentiometer to hang on analog input 1, alter the code in user_routines.c to just ramp up the value in CCPR2L (or CCPR3L) from 0 to 255 and you'll notice the LED's brightness change from off to full brightness. Hopefully someone will take this code and come up with some really cool lighting effects for their 'bot. One idea that comes to mind is to have multiple arrays of different color LEDs underneath the 'bot providing a light show during the competition.


-Kevin

Re: Fading LEDs using a PWM signal from the Edubot
 

Just got back from the Philly regional, so I can dedicate some time back to this project now. I've spent some time looking at this stuff, and lemme see if I have the basic theory right...

-------
In one of the whitepapers or the example codes about timers, I read something about each timer having being slightly different and having its own idiosyncrasies... one of timer2's idiosyncrasies is this is the only timer that controls custom PWMs - if you set an output to a user pwm timed by the internal microchip hardware (i.e. no external oscillator or something like that), timer2 is what determines the timing. One period of the PWM signal is the amount of time it takes for timer2 to reach its rollover value and can be changed by either changing the duration of one timer2 clock tick or by changing the PR2, or Timer2 Period Register, value.

The duty cycle of the PWM signal is programmed through the CCPR2L/CCPR3L byte, or the Capture/Compare/PWM Register 1/2 Low Byte. When the timer value is below this register's value, the output pin is high, and when the timer value is above this register's value, the output pin is low. Thus, to create a pwm signal with a 50% duty cycle, you set the CCPRxL value to 1/2 the PR2 value, and to create a signal with a 25% duty cycle, you set the CCPRxL value to 1/4 the PR2 value.
----

Is this basic theory explanation right, or am I missing some part of it?

Also, what is the relationship between CCPRxL and CCPRxH? I didn't really understand that part of the datasheet.

And lastly, there is only CCPR1L, CCPR2L, and CCPR3L, so that means that the pic is capable of generating only three PWM signals (each with the same period, though - timer2's period), right? If this is the case, how do you select which PWM output on the edu uses which custom PWM signal, or does each custom PWM signal control only one PWM output pin? Also, the comments in the description of Mr. Watson's Initialize_LED_PWM function read:
This kinda implies that CCPR2L is bound to PWM1 and CCPR3L is bound to PWM2. What is CCPR1L used for then, or is the CCPR1L pwm not accessable on the edu?

Re: Fading LEDs using a PWM signal from the Edubot
 

This is mostly correct. Timer 4 can also be used to generate the PWM frequency. Bits T3CCP1 and T3CCP2 of T3CON control how the timers are assigned (see the illustration on page 150 of the data sheet). I didn't bother to set these bits in my example because I knew that by default timer 2 is used to derive the PWM frequency for CCP2/3. I guess I should add this information to the example code.



Yes, this is true.


CCPRxH is a double-buffered version of CCPRxL. To prevent PWM output glitching, CCPRxL is transferred to CCPRxH only when it's safe to do so at the low to high transition of the PWM output.



No, the PIC18F8520 has five CCP modules, four of which are available for use (see below).



CCP1 doesn't seem to be available for use on the EDU-RC and FRC-RC. On the EDU-RC, CCP2 through CCP5 are available on pins PWM1-4. On the FRC-RC, CCP2 through CCP5 are available on pins PWM13-16. This is documented in IFI's latest version of ifi_aliases.h.

-Kevin

Something's wrong
 

Okay, thanks for your help so far - I've gotten it to work more or less. Some things, however, are still bugging me.

To drive my LED's, I'm using a BS107P FET. The LED lights up and 'dims' as according to the potentiometer position, but its bugging me that I can still detect the flicker. I don't think I should be detecting any flicker - I set timer2 up with a 1:1 prescaler, so each tick is 100ns (10Mhz). The period register is set at 0x40 (64), so one period of my PWM signal should be 64 * 100ns, or .0064 seconds. This means the period repeats itself 156.25 times in a second... if you think of the period as one "frame", that would be 156.25 frames per second - about 5 times faster than television's 30fps. If television seems smooth at 30fps, how come 156 flashes per second results in a flicker?

If my reasoning is wrong and 156Hz does in fact produce a noticible flicker, is there anyway I can do to reduce this flicker? For example, would adding a capacitor to smoothen the square wave work?

Re: Something's wrong
 

Actually, 64 * 100ns = 0.0000064 seconds or 156.25KHz. I'd be more inclined to say that you're seeing (literally) A/D noise. Set the duty cycle to a constant and see if the effect goes away.

Edit: Another thing to look at is your FET. The gate of a FET is generally highly capacitive. The PIC18F8520 may have trouble driving the gate at these frequencies given that there is a 330 ohm resistor between the two. Try lowering the frequency to a few hundred hertz and see what happens.

-Kevin