??? 09/19/06 16:34 Read: times |
#124586 - Fixing Problems vs. Hiding Them Responding to: ???'s previous message |
Russ, that is basically what's happening. My hope with the interrupt routine was that I could get the characters one at a time, be able to check certain values in the buffer I place them in, validate the string using the incoming checksum, and a few other things. But this way if I suddenly didn't get another byte when I'm wanting one, I could send a NAK to the other device and try the whole thing again. This would (hopefully) keep me from just getting stuck in a loop waiting for a byte that's never going to come. Does seem seem like the way to go? That seems reasonable. The interrupt routine puts characters in the buffer as they arrive, and the mainline code pulls the plug and sends a NAK if it ever times out waiting for a character. Just one caution, however. Timeouts and checksums and retries and the like are appropriate where you are dealing with something like an unreliable communications channel, where noise and dropped characters and so on are to be expected and must be handled gracefully. In other situations, however, the system should be (more or less) 100% reliable and any errors that you do see should be taken as indications of some problem that you can fix at the source. In cases like this, timeouts and checksums and retries just cover it up the symptoms without really solving the problem, and you're way better off trying to find the root cause of the errors. If you don't, you may find yourself applying patch after patch after patch as various symptoms of the underlying problem expose themselves one by one. So in your case you have to ask yourself why you are not getting all the characters you expect. If you know the answer and can justify it as acceptable, then go ahead with the timeouts and checksums and retries. Otherwise, spend some time trying to understand why you're not getting the characters you expect. -- Russ |