I am facing some embarrassing problems recently.
After some trouble-shooting, I found that: We have Board-A and Board-B. Board-A and Board-B communicate to each other with a UART TTL Level Communication. The communication cable is around 80cm long. During the communication, I got a lot of UART errors.
My mission is to build a more reliable communication between Board-A and Board-B; but not allowed to modify the hardware design and baud-rate.
To me, it is not wise to use a UART TTL Level Communication between two boards. However, I am being told that, it is very popular to us to use a UART TTL Level Communication between two boards.
I tried to find some articles/documentation to convince the involved people, that, they should not use a UART TTL Level Communication between two boards. But I can not find anything useful. What I could find is something like: The UART usually does not directly generate or receive the external signals used between different items of equipment.
My question is: Where can I find some convincing articles/documentation to convince the involved people? (This is to avoid the future problems.) If I am not allowed to modify the hardware design and baud-rate, what choices do I have to build a more reliable communication?
"If I am not allowed to modify the hardware design and baud-rate, what choices do I have to build a more reliable communication?"
Exactly what problems do you have?
The normal way to get more reliable communication is to add error-detection and error-recovery.
So, one step up is to add parity. Then you find odd numbers of bit errors in a character. This worls well for both stream and block-level transfers.
If you have block-level transfers, it's natural to add a checksum (which in this case should not be a normall additive sum, but something like crc16, crc32, adler-32 or similar) to improve the chance to detect a broken packet.
Of course, detection must be complemented with recovery, i.e. retransmission in case of transfer errors.
A stupid way to solve potential tranfer problems is to just send everything multiple times. This is acceptable unless having commands that risks being executed multiple times.
Anyway - much of the potential help depends on if you sends streams of data or blocks of data on that serial link. If it isn't block-based commands but instead stream transfers, you would normally instead reduce the number of data-carrying bits in each character sent, to let you use more bits for error detection and potentially error-correction. In short - by trying to get a higher hamming distance between the symbols.
In some cases, (such as when transmitting sound streams) you can improve the reliability by interleaving multiple sound samples over a couple of transmitted bytes. So if you get a "drop out", you only lost bandwidth of the transmitted signal - you recreate the lost data from bits transmitted before/after the drop. With ability to step up the bandwidth, you could recover without quality loss by having enough redundancy.
Interlaving without stepping up the bandwidth normally only works with sound, where you only affect the quality with transfer errors. If sending commands or text or similar, then you just have to have retransmission or redundant transfers to be able to get a 100% correct recovery (or know that the link transfer is bad beyond repair).