Hello everybody,
My serial ISR is as below. When I send a string to the microcontroller some characters are not received. The characters are lost in a peculiar way. eg. 1234567890123456 is received as 12356789012456 & 6543210987654321 is received as 65421098765321. Exactly 4th & 13th characters are lost in the mentioned 16 character string, not tested further.
void ISR_Serial (void) interrupt 4 // using 2 { unsigned char in_byte; if (RI){ // If data is received.. RI = 0; in_byte = SBUF; // get character in var RxBuffer[ RxInChar ] = in_byte; // save it in the buffer at RxInChar location if(RxInChar==RX_BUF_SIZE) // if buffer full, (care should be taken by sending app) RxInChar=0; // then make it 0 else if(in_byte==0x0D){ // whether byte was CR? RxBuffer[ RxInChar ] = '\0'; // & replace it by NULL char RxInChar=0; // then make pointer to 0 (for next transmission) if(!pc_mode_active) strcpy(tmpdata,RxBuffer); ser_data_avail=1; // set data available flag for main routine } else RxInChar++; // increase the location pointer } if( TxEnabled ){ // If data is transmitted if (TI){ // if previous byte is finished transmitting TI = 0; if (TxOutChar != TxInChar){ // adjust queue and transmit character... SBUF = TxBuffer [TxOutChar++]; TxOutChar %= TX_BUF_SIZE;//% is the modulus operator } else TxEnabled = 0; // nothing else to transmit, so disable function... } } }
If I comment out following two lines, there is no problem. (though pc_mode_active is true at this time).
RxInChar=0; // then make pointer to 0 (for next transmission) // if(!pc_mode_active) // strcpy(tmpdata,RxBuffer); ser_data_avail=1; // set data available flag for main routine
The baudrate is 115200. RCAP2H = 0xFF & RCAP2L = 0xFD, in VB I've used "115200,N,8,1"
As pc_mode_active is true at default, the 'if loop' should not execute. Similarly there should not be a problem because the code will reach to this point only on receiveing CR which is at the last position. Please help.
Thanks in advance.
Nice.
But as you can see, the prio 1 step when something isn't working is to take one step back and try to analyze the problem and understand exactly _why_ it isn't working.
That makes it much easier to create a custom fix that solves the problem without breaking something else. Or that doesn't just _seem_ to solve the problem because of some unexpected "luck".
It is too easy to just test something because the developer feels "stressed". But it seldom saves time to just test solutions. Figuring out the real issues means that you know how to test your program after having added any required fixes.
I do not know the source, but one of my favorite quotes is:
"succesful testing does not prove the abscence of bugs, it only proves the abscence of known bugs"
Thus I would never believe in "testing a bug away" if you can not analyze the source of the bug and THEN remove it you have no knowledge whatsoever if one of these "about once a week it fails" may exist.
Erik