 |
 |
| View previous topic :: View next topic |
| Author |
Message |
soonc
Joined: 03 Dec 2013
Posts: 215
|
| Disable UART1 & UART2 and PMD5 register |
 Posted: Tue Jun 16, 2020 3:13 pm |
 |
|
Using Latest Compiler V5.093
Chip: PIC18F47K42
The code starts NOT using UART1 or UART2.
| Code: |
#pin_select U2TX = PIN_B0
#pin_select U2RX = PIN_B1
#use rs232 ( baud=9600, parity=N, xmit=PIN_B0, rcv=PIN_B1, bits=8, stream=CM2, NOINIT, errors )
#pin_select U1TX = PIN_C6
#pin_select U1RX = PIN_C7
#use rs232(baud=115200, parity=N, xmit=PIN_C6, rcv=PIN_C7, bits=8, stream=CM1, NOINIT, errors )
|
Measuring PIN_B0 and B1 also PIN_C6 and C7 all four are 0V this is what I need.
Using setup_uart(115200,CM1); Com port 1 will only work if I declare
#use fast_io(c) // that's another issue.
Now I want to Disable CM1 so I use this statement:
setup_uart(false,CM1);
and PIN_C6 remains High (about 3.3V) and PIN_C7 is low but what I really want is PIN_C6 to be low also just like when the code started.
With PIN_C6 high there is a current drain into the dead module which is what I don't need.
I tried output_low(PIN_C6) does nothing.
So I looked at the .lst file for assembly code.
| Code: |
.................... setup_uart(false,BLE);
03362: MOVLB 3D
03364: BCF xF3.7
03366: BCF xF2.4
03368: BCF xF2.5
|
If I am correct the example is clearing bits 7,4,5 at address 0X3DF3 and 0X3DF2 which should disable the Uart1 but the Rx line is still high.
I tried using the PMD5 register to disable the two UART modules but PIN_C6 still remains high.
| Code: |
#word PMD5_ = 0X39C5
#bit U2MD = PMD5_.5
#bit U1MD = PMD5_.4
U2MD = 0;
0335C: MOVLB 39
0335E: BCF xC5.5
U1MD = 0;
03360: BCF xC5.4
|
PIN_C6 still remains high.
What do I need to do to get PIN_C6 low so as to stop the current draining into a dead module ?
As usual I suspect I'm doing something wrong. |
|
 |
dluu13
Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON
|
|
| Posted: Tue Jun 16, 2020 4:14 pm |
|
|
| I'm not sure if this will work but there's a built in function called pin_select() and you could set U1TX and U1RX to null. Maybe you need to totally unmap the pins from the UART. On the road so I can't test it right now :p |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1362
|
|
| Posted: Tue Jun 16, 2020 6:44 pm |
|
|
Have you verified that you are actually using hardware UARTs? Your #use rs232() calls are setup to be potentially software UARTS instead of hardware UARTS. For software UARTS you specify the pins (which is what you did) but for hardware UARTS you are supposed to specify the module.
Some versions of the compiler can still make a hardware UART out of the call you did, but not all.
try changing your #use RS232() calls to:
| Code: |
#use rs232 (UART2, baud=9600, parity=N, bits=8, stream=CM2, NOINIT, errors )
|
and
| Code: |
#use rs232(UART1, baud=115200, parity=N, bits=8, stream=CM1, NOINIT, errors )
|
|
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
| Thanks that fixed it |
| Posted: Tue Jun 16, 2020 6:58 pm |
|
|
| dluu13 wrote: | | I'm not sure if this will work but there's a built in function called pin_select() and you could set U1TX and U1RX to null. Maybe you need to totally unmap the pins from the UART. On the road so I can't test it right now :p |
Good call..
I read the "Sticky" post about #Pin Select...
Thanks. |
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
| Thanks |
| Posted: Tue Jun 16, 2020 7:01 pm |
|
|
| jeremiah wrote: | Have you verified that you are actually using hardware UARTs? Your #use rs232() calls are setup to be potentially software UARTS instead of hardware UARTS. For software UARTS you specify the pins (which is what you did) but for hardware UARTS you are supposed to specify the module.
Some versions of the compiler can still make a hardware UART out of the call you did, but not all.
try changing your #use RS232() calls to:
| Code: |
#use rs232 (UART2, baud=9600, parity=N, bits=8, stream=CM2, NOINIT, errors )
|
and
| Code: |
#use rs232(UART1, baud=115200, parity=N, bits=8, stream=CM1, NOINIT, errors )
|
|
pin_select() fixed the I/O levels but you may have a point about the way I declared the #use RS232...
I'll check to see if that's why I have to use "#use fast_io(c) for the uart to work at all.
I removed the #use fast_io(c) and
| Code: |
#use rs232(UART1, baud=115200, stream=CM1, NOINIT, errors )
|
Uart works !
Thanks for the heads up. |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1362
|
|
| Posted: Tue Jun 16, 2020 7:19 pm |
|
|
| My general rule of thumb is that if I am finding myself using #use fast_io(), then I am probably doing something the hard way or wrong way 99% of the time. Even if I legit need to have the speed on the I/O, I usually find that #bit B1 = getenv("BIT:LATB12") or similar works better for me. I think the only time I have used #use fast_io() is for reading or writing an entire port fast (but even then I could use the #word PORTB = getenv("SFR:LATB") or similar). |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19613
|
|
| Posted: Wed Jun 17, 2020 2:55 am |
|
|
This is a data sheet one:
| Quote: |
(section 31.1)
When the TRIS control for the pin corresponding
to the TX output is cleared, then the UART will maintain
control and the logic level on the TX pin. Changing the
TXPOL bit in UxCON2 will immediately change the TX
pin logic level regardless of the value of EN or TXEN
|
Basically once the UART TX is connected to the pin, it overrides the
pin drive, even if the UART is disabled...
As Soonc says the 'answer' is to un-map the pins from the UART,
with pin_select. You can even leave the UART enabled. Just disconnect
the pins from it. 
See you have found this to work. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
