Using two different sets of pins at runtime with one UART

[billpa]

Hi,

I'm working on a project with a PIC24HJ12GP202 where I need to use the single UART with multiple Rx/Tx pins, switching between them in real time.

I have two questions:

1) does anyone know whether #use RS232() generates different code, depending on which pins are selected in the #pin_select directive? If so, I assume I will need to precede each set of routines that use a particular set of pins with:
#pin_select U1RX=X
#pin_select U1TX=Y
#use rs232(baud=9600,bits=8, parity=N, stop=1)

where X and Y will vary depending on the set of routines. If #use RS232() does not generate different code for the UART depending on the selected pins (I assume it does not) I would only need one #use.

2) presumably I will need to write code that manually does the "pin_select" whenever I switch between functions that use different Tx and Rx pins. Any better suggestions?

Sorry to be lazy - I should just verify #1 by looking at the disassembly listings and comparing them.
_________________
Bill

[FvM]

As most other CCS C preprocessor statements, #pin_select generates fixed code. It's executed at the begin
of main() and doesn't offer an option to be varied at runtime. You have to write to the RPINRxx and RPORxx SFRs
directly to achieve variable pin selects.

[mbge5amw]

Hi Bill,

If you want to be able to communicate with multiple ports you can use the 'stream' option within the #use rs232

You will only be able to use the built in hardware UART with the 2 pins that are connected to the UART (I think normally C6 and C7)
However you can use a software UART to talk to any other ports you like.

The limitations of the software UART are that you have to have an interrupt when the rx pin changes, the micro will then stay in the interrupt until the whole byte has been received.
Similarly, when transmitting to the software port your micro will stay in the transmit routine until all the data has gone, costing you approx 1ms at 9600 baud.
When you are using the hardware UART you simply collect the received byte in one swift move once the interrupt flag tells you that it is there, and with transmit you just put the data in the transmit buffer and get on with your other code.

here is a link to a thread where an example is given to clarify my ramblings.
http://www.ccsinfo.com/forum/viewtopic.php?t=25564&highlight=stream

Andy

[Ttelmah]

This could be quite an interesting question for the future!.

#use RS232, has two different modes of operation. The first is where it is generating a 'software' UART, and it will then generate unique code to talk to the specific pins. The second, is where it talks to UART hardware, and it then doesn't talk to the 'pins' at all (one exception... later), but talks just to the UART hardware. The 'exception', is that it will generate the initialisation code to correctly set the TRIS for the pins involved.

So, the question arises, whether on chips that allow a hardware UART to be routed to different pins, it would be possible to setup #use RS232, using (say) hardware UART1, on a particular pair of pins, and then change the pin routing later.
Two things apply:
1) Obviously, the TRIS setting for the second pin pair, would then be down to 'you'.
2) Can the pin selections be changed 'on the fly'.

The chip mentioned (24HJ12GP202 - I presume 24HJ128GP202?), does support pin remapping, so I'd definately say this can be done.

I'd suggest setting up the TX, and RX pins using select statements to the first pair wanted. Setting up the #use RS232 using these pins to ensure that the hardware UART is enabled and used. Then setting the TRIS for the second pair of pins to match the settings needed for RS232, then trying:
1) Using another set of select staments for the pins and see what happens.
2) Manually setting the RPINR18, and RPINR19 registers. You'd obviously need to setup the 'unlock' sequence before doing this.

I'd say the second, would definately work. The first may be 'dubious', depends how CCS codes the select statements.

As far as the use RS232 statement is conccerned, it should happily carry on talking to the hardware for UART1.

Obviousl question though, why not use UART2?.

Best Wishes

[FvM]

[Ttelmah]

Agree, except for the TRIS. If you check the data sheet, it is overriden for outputs, but not for inputs. So if the TRIS forthe input pin was set as output, U1RX wouldn't work. You need to make sure the input pin has the TRIS set to 1, and also, for a separate reason, you should set the output pin high, and it's TRIS to 0, to ensure the line is set to the UART 'idle' state, when it isn't connected to the UART hardware. hence you do need to control the TRIS's involved.
I was posting really, because other poster's after you, seemed to be 'missing the point', that the question was being asked about a chip with remappable I/O.

Best Wishes

[LostInSpace]

The pin remapping idea is really good.

On a project where I used the single hardware UART I had, and needed to connect to a Modem or a RS232 port for communication I switched the pins to both devices with a CMOS switch (CD4053). A single pin controlled whether I was talking to the RS232 or the MODEM.
_________________
HTH - Steve H.

[FvM]

Ttelmah, thank you for clarifying the TRIS function. I have TRIS set according to the pin function in my
applications, so I'm no necessary aware who's actually setting the correct TRIS state.