PWM control of RGB LEDs with PIC16F1574

starfire151 · Joined: 01 Apr 2007 Posts: 195

Hi to everyone. I hope you're getting through these Covid times OK...

I'm trying to set up a PIC16F1574 with three independent 16-bit PWM outputs to drive three N-Channel MOSFETs and the associated R, G, and B LEDs. The thought was to control the color mix with either analog inputs directly or by an externally provided serial input.

Are there any examples of setting up multiple PWM outputs on a device?
Does this concept sound feasible? The chip data seems to imply it could be done.

Thanks for any help.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

See the code I posted at the end of this thread:
http://www.ccsinfo.com/forum/viewtopic.php?t=52931

starfire151 · Joined: 01 Apr 2007 Posts: 195

Thanks, very much, for that. I'll check it out.

starfire151 · Joined: 01 Apr 2007 Posts: 195

I tried the sample program using the PIC12LF1572 chip. I started with the code listed at the end of the referenced thread. I'm still a little confused on how I would implement this in my specific case, though.

I'm trying to use the #use pwm() pre-processor directive to be able to specify a stream ID. I tried the following:

#use pwm(OUTPUT=PIN_A5, STREAM=CH_1)
#use pwm(OUTPUT=PIN_A4, STREAM=CH_2)
#use pwm(OUTPUT=PIN_A2, STREAM=CH_3)

The compiler says Timer 2 is already used after the first line. According to the datasheet, there are 4 16-bit timers. I tried to specify an alternate timer (TIMER=3) for the CH_2 instance but the compiler said there was no timer 3.

How do I specify different stream IDs for the PWM1, PWM2, and PWM3?

When I tried to implement a line with pwm_on(), it states it's looking for a number, presumably the stream ID. pwm_set_duty(stream ID, duty) is similar in that it needs a stream ID.

I didn't see a way to specify a stream ID in the setup_pwm1(), setup_pwm2(), or setup_PWM3() options.

Where is the set_pwm1_period() command documented (or pwm2 or pwm3)? I don't see it in my manual...

Thanks for any help.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

You said you were using 16F1574 so that's what I used below.

The following code compiles with no errors.

starfire151 · Joined: 01 Apr 2007 Posts: 195

Great! I got it to compile correctly using the PIC16F1574.

Why doesn't this work with the PIC12LF1572, though? Isn't it just the little brother to the 1574... It's supposed to have 3 PWMs in it...

Is there a way to do the same thing with the 12LF1572?

When I just changed the chip type from 16F1574 to 12LF1572, I get the following errors:

*** Error 99 "D:\projects\PicC\projects\templates\12LF1572\multiple_pwm_12F1572_v1_0.h" Line 33(5,63): Option invalid Software PWM frequency is not achievable with Timer 2
*** Error 99 "D:\projects\PicC\projects\templates\12LF1572\multiple_pwm_12F1572_v1_0.h" Line 34(5,63): Option invalid Timer2 already being used for another PWM
--- Info 300 "D:\projects\PicC\projects\templates\12LF1572\multiple_pwm_12F1572_v1_0.h" Line 35(1,1): More info: PWM Resolution: 10.60 bits
*** Error 44 "multiple_pwm_12F1572_v1_0.c" Line 119(23,30): Internal Error - Contact CCS Built in call fail, pwm_set_duty
3 Errors, 0 Warnings.
Build Failed.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

I get the same error.

I have to go to an appt right now. Maybe someone else can help you with
the 12F1572.

temtronic · Posted: Mon Feb 15, 2021 3:48 pm

I don't have either but looked at the datasheets, the PWM sections look the same to my old eyes.
while waiting other replies....

I suspect a compiler bug. Maybe compile the 16F code and dump the listing. Then use that to manually' configure the PWM registers for the 12F part. That shouldn't be toooooo difficult to do.

Jay

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

It didn't compile because it didn't like the pin assignments.
Changing the pins to fit this table in the 12F1572 datasheet,
allows it to compile.

Ttelmah · Joined: 11 Mar 2010 Posts: 19503

Key here is 'Table1' in the datasheet.

Column one from the right.

The PIC16(L)F1574,5,8 & 9, have 'Y' for PPS. The PIC12(L)F1571 & 2
have 'N' for this. The PWM pins cannot be moved on this 'little brother'
chip.

starfire151 · Joined: 01 Apr 2007 Posts: 195

Excellent! Works like a charm!

I guess I was confused by the Table 1 entries implying the PWM1 and PWM2 functions could be reassigned to the alternate pins. I had the com port assigned to the A0 and A1 pins but moved them to the A4 and A5 pins and everything is good.

Thanks, very much, for your help!

Ttelmah · Joined: 11 Mar 2010 Posts: 19503

You can move them to the alternate pins. However this is not a PPS function.
The movements have to be done in the setup_pwm function, with the
PWM_PWM1_A5 option and the PWM_PWM2_A4 option.
Blame Microchip!.
They have implemented so many different ways of moving pins that it
is a nightmare.
You have 'fixed pins'.
Pins moved only by fuses.
Pins moved to one alternate with APFCON.
Pins moved by PPS.
CCS tries to allow them all to be used, but the syntax for the movement
is different, and #use pwm can't handle the APFCON one.

temtronic · Posted: Wed Feb 17, 2021 6:07 am

Aw, it's not a 'nightmare'...just the logical progression of getting every function to every pin.
In the beginning an I/O pin did ONE function(well 2) it was either a digital input OR a digital output..rats, really THREE..forgot 'tristate'(TM), er, high impedance.
Then people demanded more 'features' so internal peripherals were added, usually with no logical attachment to the outside world.
APF was an early way to allow users a choice in which pin did what
PPS is the 4th 'generation' of 'flexible architecture' for a micro.

OPS (Omni Pin Select) should be the ultimate, where any pin can have any peripheral and can be changed 'on the fly'. THIS would be a nightmare, especially during the debugging phase !!!

My 'nightmare' is it's bittercold(7*C), have 1.5ft of snow to deal with AND the snowblower's busted (again....)
APFCON seems easier to me........
Jay
Rolling Eyes

Ttelmah · Joined: 11 Mar 2010 Posts: 19503

I think it is a nightmare, because of having so many different ways of actually
doing it. They could have designed the the AFPCON method to
potentially support multiple pins from the start, and it could then have
evolved into a multi pin route, and then the handling could have evolved as
well. Lack of foresight....

temtronic · Posted: Wed Feb 17, 2021 9:09 am

Programmable I/O pins just seems like a 'comittee decision' with no real 'final solution'...try this..it works, try that...it works better...maybe, sortof.

Like the UART... it's 'evolved' over the years.
However just because it can be 'upgraded' doesn't mean it SHOULD be upgraded.
and I still miss the REAL comports in a PC....sniff, sniff.

Jay