This is my first time working with a processor that features re-mappable pins and I'm having a bit of difficulty with the CCP2 module, which I'm using in PWM mode. v5.073.

I have CCP2OUT mapped to PIN_B2 using:

Code:

#pin_select CCP2OUT=PIN_B2

What I *want* to do is to initially take manual control of PIN_B2 until I need the PWM. Initially I have the PWM turned off by explicitly calling

Code:

setup_ccp2(CCP_OFF);

The issue is that, with the #pin_select, I can't drive PIN_B2 high. Without the #pin_select, I have complete control.

I think I can get around this by initially setting up the CCP2 module to generate a PWM signal, but not clock it. That will force the pin high as though I manually set it high, but it just doesn't "feel right".

Is there a way of getting manual control with the #pin_select left in, or do I have to configure and reconfigure the pin select "on the fly" with the pin_select() function?

Last edited by newguy on Thu Jun 29, 2017 11:42 am; edited 2 times in total

gaugeguy

Joined: 05 Apr 2011Posts: 94

Posted: Thu Jun 29, 2017 8:47 am

Because LATxy is one of the pps output options and because a pin can only have one output option at a time, LATxy (which allows standard I/O control) and CCP2 cannot be configured to the same pin at the same time.

Changing on the fly is the only option if the pin needs to be under LAT control some time and CCP2 control some time.

jeremiah

Joined: 20 Jul 2010Posts: 997

Posted: Thu Jun 29, 2017 9:35 am

This actually surprises me. I don't generally work with PIC18's so they can be fundamentally different, but on PIC24's I often use I/O operations on output pins that are also mapped a peripheral via #pin_select. In particular we use a UART TX pin as I/O when the UART is turned off. In those cases, just turning off the UART is enough to release the pin back to the I/O controller.

Is this a difference in how the PIC18 is designed I wonder?

newguy

Joined: 24 Jun 2004Posts: 1519Location: Edmonton, Alberta

Posted: Thu Jun 29, 2017 10:15 am

So far nothing I've tried gives me control of that pin back once I assign it to the CCP2 module with a PPS statement. I've also tried "unassigning" it with

Code:

pin_select("NULL", PIN_B2)

but that doesn't truly "unassign" the pin either. I looked into trying to "reassign" it back to the latch but can't work that out.

So I did things the hard way - deal with it solely as a PWM and then playing with its assigned timer (starting & stopping) to trigger that line high/low "manually". ...And in so doing found a bug with the compiler: when you try to turn off timer 6 (could be other timers affected too) the compiler gives me:

Not only is that the wrong register, it's also the wrong bit. I've alerted CCS to the bug.

newguy

Joined: 24 Jun 2004Posts: 1519Location: Edmonton, Alberta

Posted: Thu Jun 29, 2017 11:33 am

There's definitely issues with v5.073 and PPS. If I take manual control of the PPS registers, I can easily switch back & forth from CCP2OUT controlling PIN_B2, and manually controlling PIN_B2.

guy

Joined: 21 Oct 2005Posts: 274

Posted: Mon Dec 18, 2017 3:56 am

When changing a PPS output using pin_select() from one pin to another is there a way to disconnect the old one? It seems the compiler leaves the old one connected.
PIC16LF18855 offers this as a feature (periph. outputs CAN BE connected to several pins) but I don't see the compiler (v. 5.075) allowing me to disconnect, either automatically or manually.

Thank you Ttelmah. Makes sense, just not mentioned in the help file...
Next question, or a pointer where to find the answer:
What is the relationship between Open-Drain, Current-Control Drive, Input Threshold etc. and PPS? Does the PPS MUX connect directly to the pin or before the fancy driving/input features?

Ttelmah

Joined: 11 Mar 2010Posts: 13674

Posted: Mon Dec 18, 2017 1:58 pm

This is a data sheet one.
For example for the PIC16LF18855 you mention.
Look at section 12-1.
See how it says "Current-Controlled mode is available
regardless of which peripheral drives the output."

However on some other chips and peripherals for example the input thresholds do depend on the peripheral selected.
Then I2C for example, selects the open collector drive.

guy

Joined: 21 Oct 2005Posts: 274

Posted: Mon Dec 18, 2017 2:14 pm

Correct, but all other I/O features I checked are not explained (OD, TTL/CMOS Input, Slew rate limit).

Ttelmah

Joined: 11 Mar 2010Posts: 13674

Posted: Mon Dec 18, 2017 2:35 pm

Most are features of the output driver or input. PPS just connects the signal to the driver.

guy

Joined: 21 Oct 2005Posts: 274

Posted: Mon Dec 18, 2017 3:09 pm

So you're saying that the features do apply to the PPS functions? Thanks.

I'm very excited with these options (although I don't suppose Microchip will maintain all of them throughout all new PICs). It allows for a single chip design (max. 50mA per output, no series resistors required for low current LEDs, no pull ups required, open drain, etc.) and much more flexibility.

Ttelmah

Joined: 11 Mar 2010Posts: 13674

Posted: Tue Dec 19, 2017 8:58 am

Quote:

no series resistors required for low current LEDs

Er. No.....

Read the data sheet. You must not use the current source without a series resistor designed to do most of the voltage dropping for you, or you risk overheating the source.

It is totally stupid, but the only uses for it are actually to give the regulation. Using it to actually deliver power will overload this part.

guy

Joined: 21 Oct 2005Posts: 274

Posted: Tue Dec 19, 2017 9:09 am

I read it. I feel totally safe using it to directly drive a 2mA SMD LED - the heat is negligible. It also means that in battery operated applications the LED has constant current throughout the battery life cycle regardless of the voltage, a great feature not easily performed with discrete parts.