Disabling UART TX output on a PIC with PPS

RossJ · Joined: 25 Aug 2004 Posts: 66

I've just begun using the PIC18LF27K40 which is the first chip I've used with PPS. In my design I have a wireless module which can be powered off completely. Consequently, it's critical not to back power the module through the TX line (which of course idles high).

Previously, I simply enabled/disabled the UART using setup_uart() which controls SPEN which in turn determines whether the USART module has control of the pin.

From what I observe with PPS, whether the pin is controlled by the USART module is strictly determined by PPS regardless of whether the USART module is enabled by SPEN (which makes sense).

The catch though is that the #use_rs232 directive seems to require that the RX/TX pins already be assigned with #pin_select first (even with noinit). I can subsequently use pin_select() to remove the output for TX, but there will be at least a glitch during reset which I'd prefer to avoid.

The only solution I can see is to have #pin_select set the TX pin to another unused/unimportant pin and then change it later. This is a hack. Is there a better way?

Perhaps the noinit option really should cause the compiler check (on pin_select) to be skipped.

/Ross

Ttelmah · Joined: 11 Mar 2010 Posts: 19496

What you do, is setup select to a pin temporarily.
Then deselect it.

On output devices, the data is stored on a 'pin' basis. This is why there is a
'NULL' selection offered. So:

asmallri · Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia

You could always tell the compiler that the UART is enabled by PPS, then in your code when you want the peripheral to go to sleep you manually manipulate the PPS registers to disconnect the UART from the pin. However you will need to use fast/io mode to ensure the LAT output remains low.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

Ttelmah · Joined: 11 Mar 2010 Posts: 19496

Problem is, he is worried about the glitch at boot, when the TX signal drives the pin high, before he takes over control of the pin.

asmallri · Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia

RossJ · Joined: 25 Aug 2004 Posts: 66

Thanks everyone for your input. Looks like the best available option for me is to set the TX up on a dummy output then relocate it as required. Just seems a little clunky.

(I've been running with 5.070 which has bugs in the pin_select() function (but #pin_select is okay) for the PIC18LF27K40 (wrong SFR addresses). I've just renewed my maintenance plan so hopefully it is fixed).

Cheers, Ross

Ttelmah · Joined: 11 Mar 2010 Posts: 19496

I would honestly talk to CCS, and suggest that they either allow the hardware UART to be programmed for receive only, or offer the option to bypass the PIN_SELECT testing when NOINIT is used.