[PIC] Is PIC18 UART reliable?

Hey
I don't know if this question should be in-general related to UART, or if it should be PIC18-specific, but....
I am making a simple system which will require a reliable UART communication. I mean, one PIC will be sending UART commands to second PIC. The UART will not be busy all the time, but it will have to transfer very important information.
Each data will be formed into a packet, no more that 32 bytes or so.
I can't lose any of the UART packets, because the next packet will be dependent on the previous one.
My question is: can I rely on UART as-is (I am using mikroC for PIC), or do I have to add some kind of "resend if packet missing" mechanism?
Is there any good alternative for the UART in this purpose? Maybe some other PIC18 peripheral will do better?
Thanks in advance!

Hi,

How reliable can a UART be?

I'd say the microcontroller built in UART is at least the same reliable as any other interface.

But how reliable is the microcontroller, your software, the transmission line....

UART is just one small part of a communication. You need a physical interface also. Single TTL line maybe is the worst, then shielded TTL, then RS232, then RS485, then POF, then glass fiber ( just my opinion, i don't really know if this is the correct order..)

Then you need a protocol, parity, checksum, CRC ...

And the software for resending a packet.

If one packet relies on the other, ghen what about an accidental power fail, reset or any other issue....how do you re-sync your controllers?

Klaus

The signalling sounds like a recipe for disaster but the UART itself is extremely reliable. I've been using PIC18 UARTs for many years, sometimes two simultaneously, and never had any problem with them. My projects frequently transfer data blocks of up to 32 bytes and some have been in operation for many years without any errors at all but I would seriously consider packetizing your data and adding some kind of protection to it. If you don't, you risk a cascade failure, all data sent after some corruption would be unreliable and there would be no way to detect or recover from it.

Brian.

Alloy said:

I am making a simple system which will require a reliable UART communication. I mean, one PIC will be sending UART commands to second PIC. The UART will not be busy all the time, but it will have to transfer very important information.!

Click to expand...

UART also needs a driver and you need to review also your code - is that fail safe?

Also there are weaker links along the way- what are your plans about them?

c_mitra said:

UART also needs a driver and you need to review also your code - is that fail safe?

Click to expand...

my question was related only to communication of PIC (most likely between two PICs) with UART_Write and stuff from mikroC library. So what kind of driver are you talking about?

Alloy said:

my question was related only to communication of PIC (most likely between two PICs) with UART_Write and stuff from mikroC library. So what kind of driver are you talking about?

Click to expand...

The code responsible for the implementation of the UART_Write and stuff from mikroC library are also called drivers. They are compiler specific.

If the distance between the two PICs is more and connected by means of cables, you should first use a hardware driver like MAX232. Next, coming to the software, definitely use CRC16 and packet xfers.

My normal implementation is to send data as ASCII HEX and prefix it with an STX character, then include a CRC and ETX at the end. That gives the receiving side a marker (the STX) to know new data is arriving so it can capture and calculate the CRC ahead of the checksum at the end. If variable length packets are used, I make the first character(s) the length of the following data to allow dynamic buffer sizing and an additional length check.

So a packet looks like this:
[STX][Length]{Data........}[CRC][ETX]

For acknowledgement, when needed I use:
[STX][ACK][ETX]

In some of my applications where there are multiple addressed transmitters and receivers, I add an ID byte before the [Length] on transmit and [Ack] on receive so individual modules can accept or reject the data.

You can of course choose your own control codes, those just seemed like sensible ones to use.

Brian.

betwixt said:

My normal implementation is to send data as ASCII HEX and prefix it with an STX character, .

Click to expand...

For a UART or USART, the bit serial sequence is [start bit][data bits, 5,6,7,8 bits][parity][stop bit] (one character)

Rest are done in software; packet is nothing but a sequence of character (as above) and is hardware independent.

UART has sufficient buffer (often 4 or 16 characters) so that if parity check fails the character can be retransmitted at the hardware level.