Possible to have both USB Serial and UART active?

[GTF]

I would like to use both the USB serial (PC<>MCU) and UART(MCU<>MCU) but it appears that once the USB is initialized/connected, a RS232 send or receive macro call causes a MCU lockup. Should I be able to use both?

Thanks,
Grant

[Benj]

Hello Grant,

This should work fine, I often use both components to create a bridge between my PC and a UART based device.

Can you post your program so we can have a look into what might be going wrong.

[GTF]

Hi Benj,

Here is a pared down version of the program that acts as the bridge. I can transmit data back and forth on the UART fine until the USB is active. It seems to hang once it gets to the RS232 macros at the end of the Update_Current_Limit macro.

[Benj]

Hello,

I wonder if the USB interrupt is somehow interfering with your UART receive data and therefore you are getting stuck in the loop inside the Wait_for_ready macro. The UART receive buffer is very small on a PIC so it could be you are maybe missing a byte.

Here is a slightly modified version of the program which uses an interrupt to receive the UART data as it arrives and load it into a circular buffer. We can then scan the buffer for the "Ready" message using the WaitForValue component macro.

UART_Test.fcfx

(25.35 KiB) Downloaded 315 times

Let us know how you get on.

[GTF]

Thanks Benj, that seemed to do the trick. I am actually using the circular buffer approach on the other MCU, which leads to the next question I will post.

[GTF]

I guess I spoke to soon. The first time I tried the modified test program, it seemed to work, but I cannot get it to work again. Looking at a scope I do not even see the RS232 Send String macro transmitting anything. (this is just before the Wait_for_Ready macro). On many tries, only once did I observe any activity on the UART line. The scope does show constant activity on the USB lines.

[Benj]

Hello,

What happens if you change the timeout parameter for the WaitForValue component macro from 0 to say 100. This should wait 100ms for the response before timing out but should avoid any blocking type lock ups.

[GTF]

I think I tried that yesterday, but will give it another try to be sure.

Not familiar with USB. Is it normal that I should see activity on the USB lines when not sending or receiving? It appears that there is a packet every 10usec (packets sent at at 100kHz).

[Benj]

USB is a whole other ball game and is automatically multiplexed and time spliced by the host to allow hubs from hubs from hubs etc. I think each USB connection can connect to up to 128 devices.

A packet could simply be a NAK so I wouldn't worry that there is a lot of periodic data.

My guess is it is the blocking code that is causing problems having played a lot with both USB and UARTs though of course I could be wrong .

[GTF]

Hello,

What happens if you change the timeout parameter for the WaitForValue component macro from 0 to say 100. This should wait 100ms for the response before timing out but should avoid any blocking type lock ups.

This skips the "Wait_for_Ready" and allows the data to be sent, preventing a waitforever lockup. But it appears that the data is not received on the other end...so the receiving MCU never responds with "Ready". It appears that it is the LookforValue "NewAmps" macro where it gets stuck. Neither of the LookforValues tests proceeds if the "NewAmps" is first in the sequence. While the "CalData" works fine if it is first.

[GTF]

I think I have this resolved...again. It appears that the receiving MCU was attempting to intialize/connect to USB while the other MCU had control of the switched lines. USB would not usually be connected while receiving new CalData, so that explains why there was never an issue receiving that. Too many comms to keep track of in my code! USB, UART and I2C.