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?
Indeed not!
These are 180cm - and work well over 115200 baud at TTL levels!
www.ftdichip.com/.../USBTTLSerial.htm
Many thanks to everyone.
I am a software engineer, and almost don't know anything about hardware. So I am sorry for that I am not able to provide precise and enough information about the hardware design.
As far as I know, Board-B's (the receiving end) reset circuit is unreliable (a confirmed known issue). When powers on Board-B; there is quite high percentage that, Board-B will fail to work/reset.
Now I understand that, my original assumption is incorrect. TTL Level Communication should NOT be a problem. And since no one mentions software solution in this thread, I think a software solution is not feasible. I will keep Chad's suggestion in mind (a cable that can clean up any noise or ground potential), and wait to see what will be our next step. It seems that we have decided to close this communication error issue.
One more question.
May I assume that, for external communications, RS232 provides a more reliable communication quality than TTL level; so, it provides more tolerance for bad hardware design and cables?
Yes, RS232 is more tolerant, because of the changed voltage levels used as one and zero. With TTL-level signals, you do not have much margin if you fail to keep the two grounds together firmly. That is a reason why RS-232 is specified for up to 15 meters.
Per, many thanks.
Is it?
See: www.8052.com/.../57828
I seem to have lost my copy of the RS232 specification, so I can't re-check that just now - but I'm pretty sure that it was a direct quote from the spec.
Somewhere I have a standard text, and I'm pretty sure it sais 50 feet and max 2500pF.
On the other hand, 50 feet is suitable for 19200 baud - at lower speed you can step up the cable length.
Unfortunately, there is a huge amount of misinformation about RS232 - including in "standard texts" that really should know better!
My original EIA books are currently deep down in storage.For a number of years, I have just made use of pdf versions of language standards, and datasheets/application notes/... for whatever components/modules I'm using. But the TIA-232 standards requires payment, and I normally avoid such standards unless I really do need them - in this case, RS-232 is obsolete.
The most important parameters here is capacitance and the slew-rate control of the driver. So datasheets for some drivers will give more explicit information, based on capacitance and cable length. Then you will be able to find references to 1 km or more depending on cable and baudrate.
But the important thing is that the actual standard was made for 15m/50 feet, which does give an indication that RS-232 itself is designed for longer distances than raw logic-level signals. This was the scope of the previous discussion.
Next thing is that even if you can manage very long cable length with suitable cable capacitance and baudrate, few people will still use RS-232 for really long lengths. If optical isn't an option, then most people would go for a differential solution - RS-422/RS-485 or similar.
Indeed.
In fact, RS232 is specifically designed for the interface between a "modem" (DCE) and a DTE - and it is the purpose of the modem to provide the long-distance link...
the solution to the OPs problem is not making major rework and adding 232 transceivers, the solution is to make the hardware drive of the TTL levels solid
Erik
Drifting yes.
But it whas the OP who did add that additional question. This time about "external" communication.
If the OP wants the thread to drift, then sure I'll play.
I believe that, my ex-hardware-partner in my previous company can make the hardware drive of the TTL levels solid. But I guess that, he will choose RS232 interface instead for many reasons. In the past, I do not need to worry about this kind of problems.
However, in my current company, I don't think "we" know what is solid and robust.
"in my current company, I don't think 'we' know what is solid and robust"
Clearly not!
So you really need to hire someone who does know - either as a permanent employee, or on a temporary/consultancy basis.
We are a OOXX level-n qualified company.
I believe that, most companies here in Taiwan are very interested in improving the Quality Assurance System / Business Flow / Work Flow / Process Management / Project Management ...... ...... ......
But most companies here in Taiwan are not very interested in improving employees technical ability.
Putting a leopard into a turtle's team, does not change the overall speed.
We already have a consultancy from nearby university, but most universities here in Taiwan do not know much about advanced technology, and the real skills that a engineer would need.
Maybe this is also a common worldwide issue.
www.developer.com/.../what-happened-to-software-engineering.html
Most of the agile methodologies focus mainly on the process management topics and don't discuss construction techniques in their teachings (the main exception is Kent Beck and Extreme Programming). I believe this due to the agile methodologies assuming you are already doing the technical practices!
Unfortunately, in my career as a consultant and an agile coach, I have seen all too often that those engineering practices are being left behind.
When having logic-level communication between boards, or maybe through a ribbon cable, you would normally (unless the distance is very short and you are in good control of emissions etc) use buffer chips.
They have much larger current-drive capability. Sometimes reduced by having EMI filters that slows downs the flanks of the signals. And they have schmitt-trigger inputs that makes sure they don't produce spurious noise if the input signal have a slow flank overlayed with a bit of noise.
I don't know about your distances, but if inside the same enclosure, then you normally do not go for RS-232 or similar. RS-232 is intended for external signals, i.e. basically short-distance (a couple of meters) of box-to-box communication. As covered earlier - with low baudrate and good cables you could even go quite long. But the intention is basically 1-15 meters.
With multiple boards in the same enclosure, you normally have some form of shielding from the box. If not, then you must consider cables with shielding to avoid radiating too much noise. But then - anyone who uses a box without shielding just have to have the skills to make a PCB that doesn't radiate noise. In reality, you design PCB with well-placed ground planes to keep down radiation even if intending to place PCB inside shielded box.