PIC18F4550 and two UART's

[defoxe]

First I was trying to use my PIC18F4550 with UART and USB cdc, it's working but sometimes
UART rx is hanging up. Its working nice after PIC reset.

A6 GSM --(115200bps UART)-- PIC --(115200bps USB CDC)-- PC

So now I am trying one hardware UART and one software.
Ok, its working nice:

[temtronic]

With every HW UART you must always have 'errors' in the use rs232(...options...)

Whenever you use 2 UARTs buy a PIC with two HW UARTs unless the ONLY thing the SW UART has to to is TRANSMIT, never ever receive data

also whenever you have serio I/O you should( must?) use 'buffers'. CCS supplies an example ( ex_sisr.c) for an interrupt driven serial buffer. I know it works for 2 HW UARTS at 115K200 all dy long without any missed data.

I gave up on the 4550 years ago, went to the 18F46K22 as it has 2 HW UARTS, lost of mem, etc. You can buy TTL<>USB modules for $1 and eliminate 100% of the problems that the 4550 has.

Jay

[defoxe]

[Ttelmah]

It's worth understanding.

The fault is happening, because when you transmit "OK\r\n", this takes four character times.

The hardware buffering on ual, can handle just under two characters. You have already not serviced 'ua1' for a character time (while you send the character out on uapc), so by the time you get to the end of all this, the hardware receive buffer overflows.

If this happens, the UART goes into an 'error' state, and will stop receiving.

The 'ERRORS' keyword, tells the compiler to add code to the UART handler, to automatically clear errors when they occur. It should always be used with the hardware UART, unless you are adding your own error handler code.

So, with ERRORS, the UART won't get hung. However you will still have lost the characters that are received to cause the overrun.

Provided there are gaps in the data (so the UART can catch up sometimes), adding the RECEIVE_BUFFER increases how many characters can be received before this happens.