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
"I'am despaired, yes of course maybee i could fix it with some checksum-handshake-algorithm..."
Using PC UART links with high baudrates and no data integrity verification is a very poor comm infrastructure. You have plenty of processing bandwidth in a PC and a ARM to implement at least CRC16 for data checks with zero cpu overhead.
Checksum is an extremely frail data checking code. Please do NOT use it. Unless, of course, you are implementing XMODEM in your microcontroller.
With a very small code you can perform packet checking and retransmission. Get the CRC16 algorithm or lookup tables in any MODBUS-RTU online resource.
"Using PC UART links with high baudrates and no data integrity verification is a very poor comm infrastructure"
Using any UART links with high baudrates and no data integrity verification is a very poor comm infrastructure
"Using any UART links with high baudrates and no data integrity verification is a very poor comm infrastructure"
Indeed it is. I should have broadened my statement.
Data link synchronization and integrity are essential to any comm link, and are really simple to implement. Whether an ad-hoc protocol is developed, or a standard one, it is mandatory in any design.
Hello, thanks for reply. My (PC) operating system is FREEDOS.
As i wrote checksum-handshake-algorithm i was thinking about some CRC-check. But my problem is much deeper, i never had any normal error's in my Data-stream but sometimes about every 20000 Bytes some Bytes are completely lost. Example:
while(1) { unsigned char my_key; my_key=0; scanf("%c",&my_key); printf("A 123 456 789 654 321\n"); }
I receive this hundred or thousend times correct, but sometimes something like "A 12789 654 321" There are one to 8 Bytes completely lost.
"... 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.