| View previous topic :: View next topic |
| Author |
Message |
newguy
Joined: 24 Jun 2004
Posts: 1924
|
| Update: PPS and the 18F24K40 - fixed in next release |
 Posted: Thu Jun 29, 2017 8:35 am |
 |
|
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 2011
Posts: 350
|
|
| 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 2010
Posts: 1401
|
|
| 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 2004
Posts: 1924
|
|
| 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:
| Code: | .................... setup_timer_6(T6_DISABLED, 0, 1);
0B78: MOVLB 1
0B7A: BCF xF7.0
|
Not only is that the wrong register, it's also the wrong bit. I've alerted CCS to the bug. |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1924
|
|
| 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 2005
Posts: 297
|
|
| 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.
| Code: |
.................... pin_select("U1TX",TX_UUT,TRUE,TRUE);
0B72: CLRF 77
0B73: BTFSC 0B.7
0B74: BSF 77.0
0B75: BCF 0B.7
0B76: MOVLW 55
0B77: MOVLB 1D
0B78: MOVWF 0F
0B79: MOVLW AA
0B7A: MOVWF 0F
0B7B: BCF 0F.0
0B7C: BTFSC 77.0
0B7D: BSF 0B.7
0B7E: MOVLW 10
0B7F: MOVLB 1E
0B80: MOVWF 23
0B81: CLRF 77
0B82: BTFSC 0B.7
0B83: BSF 77.0
0B84: BCF 0B.7
0B85: MOVLW 55
0B86: MOVLB 1D
0B87: MOVWF 0F
0B88: MOVLW AA
0B89: MOVWF 0F
0B8A: BSF 0F.0
0B8B: BTFSC 77.0
0B8C: BSF 0B.7 |
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19967
|
|
| Posted: Mon Dec 18, 2017 9:48 am |
|
|
The default is to leave it attached. Removal is what NULL is for.
| Code: |
pin_select("U1TX",TX_UUT,TRUE,FALSE);
pin_select("U2TX",TX_UUT,FALSE,TRUE);
|
Connects both peripherals to the single pin.
| Code: |
pin_select("NULL",TX_UUT,TRUE,FALSE);
pin_select("U1TX",TX_UUT,FALSE,TRUE);
|
Deselects the existing selections, then connects U1tX. |
|
|
guy
Joined: 21 Oct 2005
Posts: 297
|
|
| Posted: Mon Dec 18, 2017 1:24 pm |
|
|
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 2010
Posts: 19967
|
|
| 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 2005
Posts: 297
|
|
| 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 2010
Posts: 19967
|
|
| 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 2005
Posts: 297
|
|
| 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 2010
Posts: 19967
|
|
| 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 2005
Posts: 297
|
|
| 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. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
