Multiple UART Comport Behavior Confirmation

[Jeff Weinmann]

Hello,

I've Setup My PIC18F16Q40 just like Evan's video example, with an additional hardware UART:

Sub InitPPS

            'Module: I2C1
            RB6PPS = 0x0021    'SCL1 > RB6
            I2C1SCLPPS = 0x000E    'RB6 > SCL1 (bi-directional)
            RB4PPS = 0x0022    'SDA1 > RB4
            I2C1SDAPPS = 0x000C    'RB4 > SDA1 (bi-directional)

            'Module: UART pin directions
            Dir PORTC.6 Out    ' Make TX1 pin an output
            Dir PORTC.7 In    ' Make RX1 pin an input
            Dir PORTC.0 Out    ' Make TX2 pin an output
            Dir PORTC.1 In    ' Make RX2 pin an input
            'Module: UART1
            RC6PPS = 0x0010    'TX1 > RC6
            U1RXPPS = 0x0017    'RC7 > RX1
            'Module: UART2
            RC0PPS = 0x0013    'TX2 > RC0
            U2RXPPS = 0x0011    'RC1 > RX2
End Sub


'USART settings for UART1 and UART2
#define USART_BAUD_RATE 9600
#define USART_BLOCKING
#define USART_TX_BLOCKING

#define USART2_BAUD_RATE 9600
#define USART2_BLOCKING
#define USART2_TX_BLOCKING

Everything works except when I call the following:

'Does the following switch EVERYTHING to comport 2?
'UART2 Send test
HSerPrint "TEST", 2
HSerSend 13,2
HSerSend 10,2

Any HSerReceive calls on UART1 seem to fail unless I modify the above code:

HSerPrint "TEST", 2
HSerSend 13,2
HSerSend 10,2

'Forcing back to comport one makes everything work
comport = 1

Everything starts to work. So in summary, any time I call a hardware send or (received I'm guessing) forces the whole PIC to comport 2, unless I call comport = 1?

I have a whole lot of HSertPrint HSerReceive and HSerSend code that does not have the comport explicitly referenced

I have it working and before I can confirm that if I explicitly reference the comport EVERYWHERE IN CODE, I want to confirm this is how it should be working.

Example

'Print TEST on UART2
HSerPrint "TEST", 2
HSerSend 13,2
HSerSend 10,2

'Receive data on UART1
 HSerReceive temp, 1          'Look for $ start of message
If temp <> 0x24 then  goto Look
HSerReceive temp, 1           'Look for G - every msg
If temp <> 0x47 then  goto Look

'Put GPS in standby mode on UART1
 HSerPrint "$PMTK161,0*28" ,1 
 HSerSend 13,1
 HSerSend 10,1   

thanks!

Jeff

[Anobium]

HSerPrint "TEST", 2 .. the second parameter set up USART2. All subsequent USART calls will now use USART2 until you change the variable ComPort or use HSerPrint "TEST", 1 where the second parameter changes usage to USART1.

Many of the USART commands have the second parameter as an optional parameter. So, you can use this to control which USART to use.

[Jeff Weinmann]

Thanks for the confirmation Anobium. I see the matching behavior now

[Terry Platt]

Hi Anobium, I have a somewhat similar problem with dual COM ports. I have the FT2232 dual USB to serial device, feeding a single PIC18F16Q40 that has two command sets. One command set is controlled by input from USART1 and the second set from USART2. If I turn off blocking on both USARTs, the program works OK, but I get randomised data returns to the control software. Turning on blocking for one USART makes that channel work fine, but the other channel now fails to connect. Turning on blocking for both channels stops everything. I don't see an easy way around this, but can you advise please?

[kent_twt4]

One could try the UsartRXxReady interrupts and perhaps UsartTXxSent too for some sort of Usart data flow? Next option would be to poll the individual register bits, and handle it that way.

[Anobium]

@Terry

Can you put together a really simple program to show what is happening? Then, we can look at the ASM.

---

I agree with Kent with the use of interrupts. The Q40s have a huge number of serial interrupts but I would be using a Ring Buffer on both USART to handle incoming data. The Ring Buffer code is in the Help. Reading two USARTs with blocking (therefore without a Ring Buffer) would exhibit the issues you describe.

[Terry Platt]

Hi Anobium & Kent, I've gone ahead and used the example code to create ring buffer inputs. This is looking promising, but I get a continuous stream of repeating characters, rather than single ones. For example, if I use a Terminal and connect the board, there is a continuous run of '0x80' characters as soon as it is connected. If I send a new input (say 'R') it then becomes a stream of 'R'. I get the impression that the buffer isn't clearing the characters after reading them. Any thoughts?

[Anobium]

We would need to see the buffer code.

I often just copy the code direct from the Help. But, you will need two buffer, with two sets of Constants and variables. Did you create two copies of the code?

[Terry Platt]

Yes, I created duplicate ring buffers with unique variables etc. I can try to extract the important parts into a new program.

[Terry Platt]

Here is the ring buffer code.

[Anobium]

Thanks. All looks Ok.

I would retionalise the call to HSerReceiven(). See the attachment. As the interrupt handler already checks for U1RXIF and U2RXIF (and interrupt handler clears these bits) you can get the data direct from the register.

This will be faster.

---

Can you test one channel ? Comment out the other interrupt. Add a loop to return the incoming char. Then, do the same ofr the other channel. Does these two scenerios work?

[Terry Platt]

I commented out the 'InitBufferRing2' statement, but the terminal still shows a stream of repeating characters from USART1.

[Anobium]

Can you upload the actual program? I can then put in a chip here on my Tuesday am.

[Terry Platt]

Hi Anobium, After your previous replies, I had a look at the code for setting up the USART ports. Can you check if these are correct please?

'Module: UART pin directions
Dir PORTB.7 In ' Make RX1 pin an input (UART1)
Dir PORTB.6 Out ' Make TX1 pin an output (UART1)

Dir PORTB.5 In     ' Make RX1 pin an input (UART2)
DIR PORTB.4 Out    ' Make TX1 pin an output (UART2)

'Module: UART1
U1RXPPS = 0x000F   'RB7 > RX1 Pin 10
RB6PPS = 0x0010    'TX1 > RB6 Pin 11

'Module: UART2
U2RXPPS = 0x000D   'RB5 > RX2 Pin 12
RB4PPS = 0x0013    'TX2 > RB4 Pin 13

[Anobium]

PPS looks good.

[Terry Platt]

Thanks for the confirmation. The reason I ask is that there is a data stream out of port RB4 as soon as I power up the board. I thought that the PPS settings could be wrong, but there must be another firmware error somewhere.