We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hallo to everyone. I still use CARM and there's a bug using scanf:
scanf("%c",&my_key);
if PC sends CHR$(0) to the ADuC microcontroller the scanf does'nt change the content of "my_key". So i get the last received again
My fix-up is:
my_key = 0; scanf("%c",&my_key);
Now i can receive a CHR$(0) also.
Is this a known bug or a feature? :-)
I have some additional trouble when the ADuC sends a string to PC, for example
printf("A 37 180\n");
The string is always similar: A letter (A-Z) and two numbers closed with \n
Sometimes the PC is loosing a number of my string :-(
I'am despaired, yes of course maybee i could fix it with some checksum-handshake-algorithm...
I'am using only RX & TX.
CTS & RTS are connected. DCD & DTR & DSR are connected.
On PC-side i use INT14h Function 0..3 to handle RS232. Baudrate is 115200
Ideas welcome
"... receive this hundred or thousend times correct," Ok, that is evidence that your UART and line driver hardware are probably correct.
"but sometimes [...] there are one to 8 Bytes completely lost."
Ok, that means that you:
1) Have an occasional burst of electrical noise on the line (most likely), or 2) Have the 2 UARTs working close to the baud clock error limit, and occasionally lose a few byte frames due to logic delays (unlikely), or 3) Have processing issues on either computer that causes UART feed errors (unlikely) or received data loss (most likely).
Whatever your case may be, that [data loss] is the very reason to use integrity checking with retransmission. One burst of error in a few thousand packets is quite normal, especially at 115200 baud.
One to eight bytes means a burst of 800us, consistent with electrical appliance switching transients, for example.