Why? Does the processor checksum every value calculated and stored in memory? Not on my computer. This is not warranted because the data failure rate is very low. Same with an RS-422 bus in an electrically quiet environment. I could probably get away with TTL level signals, but I'd like to have the ESD protection these RS-422 chips give. That additional noise immunity means there is an extremely small chance of bit errors. If we have problems, the error handling can be added.
Why are you discussing this? Out of academic curiosity? Then please continue. But what does it matter for your system implementation? There is just a UART/SPI/I²C/JTAG/GPIO peripheral and your software won't care how this peripheral is implemented, as long as it behaves as expected.
I care. Don't you?
I remember when I came to the realization of why an MCU was so cost effective compared to programmable or even dedicated logic. It's because the MCU program is a FSM, using the instructions stored in the memory. These instruction are essentially logic, which is connected through the CPU logic, creating a very low cost solution to a wide variety of problems, because of the very low cost of memory compared to dedicated or programmable logic.
I would not dare to implement a serial protocol without any form of error checking, on any length of cable.
You mention ESD somewhere. This can be a serious disturbance that can easily corrupt a few bits. Reminds me of a product where we got windows blue screens during ESD testing on a device connected via an FTDI USB to serial adapter. Cable length less than 6 feet.
So you do wait for a reply, and a reply is only expected on a valid message? What if there is no reply, do you retry? If so, you already have implemented some basic error checking. For more robustness you could (I would) add some kind of CRC.
In the following, I think Richard is just considering a situation where this problem might occur. Not your situation because he has already 'caught on', as you mention. But I should probably not speak for Richard ...
No, I don't. We do use FTDI chips in our designs to interface a serial port to USB. And we also use ready made FTDI cables. We use these chips and cables based on their specifications in datasheets and user guides etc. I have never felt the need to invesitigate how the UART/USB functionality was actually implemented inside the chip. What would I do with this knowledge? In a design I must rely on the behaviour as specified in the datasheet.
This is what I would call 'academic interest', and that is perfectly fine. And this knowledge might help you think differently about solving a problem in your own design. But it will make no difference in how you will imlement this chip (or cable) in your design.
An extra stop bit will help for this particular kind of error (and is a good idea if you get such errors often, as it will improve your percentage timing margins). An occasional pause of at least 11 bit times will help for all sorts of possible errors.
Basically, it is a good idea to assume that sometimes things go wrong. There can be noise, interference, cosmic rays, power glitches - even in a system that has bug-free software, quality hardware, and no fallible human anywhere, there's always a risk of faults. That is why most serial protocols have CRC's or other checksums, and at least a basic "if there is no reply, repeat the telegram" handler.
I'm not sure what bus arrangement you are referring to. The RS-485 bus is intended to be linear. The terminators are at the ends, to prevent reflections. There's no point in removing either of them no matter which driver is enabled. All drivers see two loads. A terminal driver sees the bus and the terminator. A driver along the bus sees two buses which are driven in parallel. So everyone sees the same impedance, half the characteristic impedance of the bus.
If a UART receiver can not properly receive a message like this, it is defective. The point of the start and stop bits are to provide the synchronization. The receiver simply needs to detect the stop be state (by sampling where the receiver thinks is the middle of the bit) and then immediately start looking for the leading edge of the next start bit. The receiver will then be synchronized to the new character bit timing and it will never slip. That gives up to ±5% combined timing error tolerance.
If the receiver waits until a later time, such as the expected end of the received stop bit, to start looking for a start bit leading edge, it will not be able to tolerate a timing error where the transmitter is faster than the receiver making the timing tolerance unipolar, i.e. 5% rather than ±5%.
That's a receiver design flaw, or the transmitter is sending short stop bits, which you can easily see on the scope with a delayed trigger control.
You should be able to diagnose which end has the problem by connecting a different type of receiver to the stream. If a different receiver UART is able to receive the messages without fault, the problem is obviously the failing receiver.
Yes, I mentioned ESD somewhere. This is testing newly constructed circuit boards, so is used in an ESD controlled environment.
I assume you mean some other device was being ESD tested? This is not being used in an ESD testing lab. Was the FTDI serial cable RS-232 by any chance? Being single ended, that is much less tolerant of noise.
There should not be any messages other than "valid" messages. I don't recall specifically what the slave does on messages with bit errors, but I'm pretty sure it simply doesn't know they have bit errors. The message has no checksum or other bit error control. The format has one character to indicate the "command" type. If that character is corrupted, the command is not used, unless it is changed to another valid character (3 of 256 chance).
Again, there's no reason to "detect" errors since I've implemented no error protocol. That is many times more complex than simply ignoring the errors, which works because errors don't happen often enough to have an impact on testing.
On the Apollo moon missions, they took no precautions against damage from micrometeoroids, because the effort required was not commensurate with the likelihood of the event.
It's hard to imagine an engineer with no curiosity.
It is very much of practical interest to me, as I design FPGAs and knowing that I can use less resources by constructing a peripheral as a CPU, is important info. The FPGA design in the UUT was pushing the capacity of the chip it was in. I was on the cusp of changing the design to a CPU centric design when it was routed at 90% utilization. This time, I'm bumping the size of the FPGA significantly, about 3x. The Gowin FPGA devices are very cost effective. I'll be able to use the hard logic and the soft CPU, both. LOL
Yes, that's hard. But imagining an engineer who does not care about the internal structure of every single chip he uses is a lot easier (for me). I tend to focus my curiiosity on things that matter to me, don't you?
You wrote: "I could probably get away with TTL level signals, but I'd like to have the ESD protection these RS-422 chips give. That additional noise immunity means there is an extremely small chance of bit errors. If we have problems, the error handling can be added."
This led me to believe you were expecting actual ESD discharges that could disturb your messages.
ESD protection is just that: protection against device damage
I do not believe ESD protection does anything to improve noise immunity. It just increases the ESD level at which the device will be damaged.
And if you have an ESD controlled environment, that is not actually needed.
No a device with an FTDI chip on it was tested. USB cable was <= 6 feet and serial ports were only a few centimeters of TTL level PCB traces. This was reproducable with an evaluation kit with only USB connected.
Okay, the slaves are already implemented? Missed that. So there is some very basic error detection: the command must be valid. And if it is not and the slave does not reply, what does the master do?
A test rig that ignores errors. I don't know the requirements of this test and how bad it would be to have an invalid pass/fail result.
I am not sure what they could have done, but adding effective shields would probably have prohibitive weight consequences, if at all possible. But if you can believe the movie Apollo 13, thre is a real danger from micrometeorites.
By definition curiosity is, "an eager desire to know or learn about something". That's not limited to things I *need* to know about. In fact, I don't limit my curiosity at all. It's a desire, not an act.
The knowledge can be very useful, if it opens new ideas for how to use these devices. In fact, I found that the majority of FTDI cables are full speed, which is much more limiting that the few Hi-speed USB cables they make. The Hi-speed cables seem to handle a lot more protocols. So now I'm back to wondering if they are implemented in a CPU based design.
Yes, you are right. My language there is poor. I should have said I prefer the noise immunity the RS-422 devices have compared to TTL devices *in addition to* the ESD immunity.
In theory, but I can't control how these will be used in the future. ESD immunity is something I want designed into any application that is connected by a cable.
So you were shooting high voltages into a device and were surprised the PC it was connected to crashed? I'm not following this at all. I'm pretty sure the FTDI cable is not rated to provide isolation. That has nothing to do with ESD protection. As you say, ESD protection is about damage, not operation.
A test fixture is in use, with software on the PC. There's no reason to change the protocol in the new test fixture and software unless there is a need, a new requirement.
The command being valid is based on as single character. The command is something like, "01 23 X<cr><lf>". I suppose the CR LF might also be required, but I don't recall. It might require one and ignore the other. The whole CR LF thing is such a PITA. The only character that is required for sure, is the "X", which at the moment can be one of three from the possible characters (don't recall if they are 8 bit or 7). I also don't recall if parity checking is used.
I do know that I had a flaw in the initial setup that gave intermittent errors. I had the hardest time finding the problem because of using bias in where to look. I tried adding re-transmission, which helped, but it borked up the code pretty well. I guess my software skills are not so good. In the end, it was an Ariane problem where the UART in the FPGA was existing code that was reused. Thinking it was a previously validated module, it was not suspected... at all. Eventually I realized it did not include the input FF synchronization to absolve race conditions. That was left for the system designer to add, since there may be more than one device on the same input.
Since that was solved, we've tested thousands of UUTs with no interface bit errors. So I have no worries about this.
Since the test will be run, over night, every few seconds, with all UUT errors logged, the chances of the same bit error happening the same way, causing the same miss of a UUT failure some thousands of time (about 7,000), is on the order as a proton decaying. Well, maybe a bit more likely.
Real, even if very small danger. That's the point. In this case, the impact is small, the likelihood is small, and the work to mitigate the problem is far more effort than justifiable, no matter how emotional people may get about "Errors! OMG, there may be ERRORS!"
Maybe I need a heavy duty cabinet to protect against the very real possibility of meteors?
Learn about something != learn about everything Matter to me != *need* to know about
My not caring abbout the innards of a particular chip seems to let you think I don't care about anything. But we are not discussing my interests here, but your bus.
Yes, alway protect accessible parts.
Ofcourse not into a device. But all over the enclosure, as is required to pass EMC testing. These discharges cause current spikes that can induce currents in parts of your circuits. Part of ESD testing also uses coupling planes, where you fire on a metal plate 'near' the device. That can also give a lot of noise. All these things may not cause device damage like direct ESD discharges, but they can disturb the device operation. Depending on the expected performance level, this may cause a fail. For medical devices you usually cannot get away with worse than "temporary loss of function and recovery without operator intervention".
ESD protection is indeed about damage prevention. But passing an ESD test usually requires more than just preventing damage.
How would you rate a phone that resets every time you pick it up when you have not properly discharged yourself from static electricity? It may just reboot and work fine after that, but it would still be a crappy phone.
Ah, existing stuff.
Okay, more restrictions on valid messages, yet more error detection present already. ;-)
Another layer of error detection. ;-)
Seems to me you wanted to talk about my interests when you said, "Why are you discussing this?" and then continued discussing that issue for some half dozen more posts.
Lol! I probably would barely notice! Cell phones are among the most unreliable devices we use with any regularity. I recall a Dave Barry article that was talking about cell phones which he mocked by describing typical conversations as, "What? WHAT?" Now, it's more like, "Hello...? Hello...? <click>"
Yes, the very first sentence of the very first post was, "I have a test fixture that uses RS-232 to communicate with a PC."
Errors in the UUT. If there is an error in the comms link, we likely would not even know about it. This will be an interesting test for both the UUTs and the comms link. I'm not certain how many messages it currently takes to implement any given test, but it should be possible to run the tests in parallel minimizing wait times for the PC software. I would estimate the total test time for a chassis to be between 10 and 60 seconds, so between 1,200 and 7,200 tests in the 20 hour soak time. As I learn more about the FTDI device, I am more pessimistic about the throughput. I could shove the details of tests into the FPGAs, so the commands are more like, run test 1 on channel number 2. That would cut the number of tests significantly, but require much more work in updating the FPGA software.
I think I'll start with a direct transfer of the existing protocol.
...
That was not my intention. It seemed to me that you cared about the internal implementation of the FTDI chip in relation to your bus problem. I just wanted to point out that is of no concern for your bus operation. And then I just got dragged in. ;-)
Are we circling back to the idea putting a microprocessor on the test board? Ivan Sutherland famously called this a wheel of reincarnation:
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.