Skip to main content
added 966 characters in body
Source Link
jonk
  • 79.7k
  • 7
  • 85
  • 198

For now, that's all I can easily imagine. So try these few things earlier than later:

  1. Verify that you are initializing the asynch rate properly with the library you are using on the transmitter side.
  2. Verify that you are using the same rate properly on the receiver side.
  3. Verify that the clocks used on both sides are capable of providing those rates within the appropriate error bars for async (about 2% or less.)
  4. Verify that that the number of stop bits match up, or that the transmitting side uses MORE stop bit time than the receiving side, if they don't match.
  5. Track down what is being placed in your string buffers. Don't assume. Verify. Check the first 10 bytes. Print their byte values as integers and see what they are.
  6. Scan through the string buffer looking for a 0 byte. When you find the first 0 byte, tell us at which buffer index it occurs at.
  7. Hook up your receiving device to some other source. Verify that it can receive a continuous string without error.
  8. Tell us what compiler you are using.

For now, that's all I can easily imagine.

For now, that's all I can easily imagine. So try these few things earlier than later:

  1. Verify that you are initializing the asynch rate properly with the library you are using on the transmitter side.
  2. Verify that you are using the same rate properly on the receiver side.
  3. Verify that the clocks used on both sides are capable of providing those rates within the appropriate error bars for async (about 2% or less.)
  4. Verify that that the number of stop bits match up, or that the transmitting side uses MORE stop bit time than the receiving side, if they don't match.
  5. Track down what is being placed in your string buffers. Don't assume. Verify. Check the first 10 bytes. Print their byte values as integers and see what they are.
  6. Scan through the string buffer looking for a 0 byte. When you find the first 0 byte, tell us at which buffer index it occurs at.
  7. Hook up your receiving device to some other source. Verify that it can receive a continuous string without error.
  8. Tell us what compiler you are using.
Source Link
jonk
  • 79.7k
  • 7
  • 85
  • 198

I think you have more than one problem. Since you don't identify your compiler, nor how you set it up, it's going to be hard to help with precise instructions.


Let's start with problem #1.

Given your last test, it sounds to me like strlen() isn't working.

The sizeof() function, which you aren't using here, is evaluated at compile time and might have returned a large number since its job is to tell you the known size of a buffer like this.

But strlen() evaluates at run-time and should technically report the actual string length after initialization with the string. If this string is placed statically (outside of a function at the "module/file level"), then this initialization should take place prior to main() starting up (by hidden assembly code.) If this string is placed as a function-local variable, then this initialization takes place every single time the function is called (I remember the days, though, long before the first C standard arrived when such initialization was ignored.) Either way, your code should not be able to call strlen() before initialization takes place. So strlen() should always be able to "see" the string.

So either strlen() isn't working, or it is. If it isn't working, you need to find out why. If it is working, then your initialization string isn't being properly initialized (or it is being initialized with garbage or some foreign language multi-byte mess.) If that's the case, you need to track that down as well.

One thing to try, in order to verify that the string buffer is being initialized is to STOP TRYING to use string functions on it. Obviously, that is NOT WORKING for you. So now, try and dump out a few byte values as integer numbers. See what is in that buffer. Verify!!!

I'm also not entirely sure if your receiving program is getting the right number of bytes, or not. I'd like you to confirm or deny that question in my mind. I think you are saying that it is getting lots more characters. And, if your strlen() result is counting lots of characters, then it makes sense that lots of characters are being sent out. But I'd like you to talk a little more about this. Just because I might pick out something from what you add.


The other problem I see is that your receiver (whatever it is that is "getting" the characters being sent along) isn't getting the right values. This can be for several possible reasons. Since this is asynchronous communications (as I gather it), it's possible that the bit rates don't match up right between sender and receiver. Did you make sure to initialize the serial library correctly? On both ends? This could also account for different numbers of characters being sent than received, as well as the garbage you see. It's vital that you get these things matched up right.

Another possibility is that your sending library is using one stop bit and your receiving side expects two stop bits, for example.

Another possibility is that your receiving code/device/whatever cannot handle back to back characters. It has some stupid, idiotic delay inside of it that prevents it from properly parsing a continuous stream of asynchronous characters. But it can receive them one at a time, with breaks of time in between. So you get stuff that seems right when you use a separate call, each time. Because there is a LONG delay in between. But when you send out a string, the sending code just RAMS IT OUT FAST, back to back, and your receiver just gets overwhelmed and cannot keep up.


For now, that's all I can easily imagine.