I have a strange bug that I'm unable to figure out yet. I have a set of serial debugger functions that I want to use with my JS16 target. So far so good, but my transmit function (TxString) behaves strangely.
In particular, I can't seem to get a carriage return code (0x0D) to register. I'm using Realterm, in ASCII mode to see the LF and CR characters represented on the terminal.
Here's my code:
/********************************************************************
* TxString(): send string of characters as ASCII via SCI
*
* Parameters: pointer s, new line option
* Entry Conditions: None.
* Exit Conditions: None.
* Return: None.
* Remarks: no limit on input number of characters,
* option for outputting newline escape characters
* after conclusion of string
********************************************************************/
void TxString(byte* string,byte newline){ word time = 0xFF00; do { __RESET_WATCHDOG(); // feeds the dog while(!SCIS1_TDRE) { __RESET_WATCHDOG(); // feeds the dog } SCID = *string; } while (*++string != 0); if (newline == TRUE) { SCID = CR; // send carriage return <--- this line doesn't do anything in Realterm SCID = LF; // send line feed } while(!SCIS1_TC) { __RESET_WATCHDOG(); // feeds the dog }} // end TxString()The macros "CR" and "LF" equate to 0x0d and 0x0a. The CR line doesn't seem to send anything, but LF does. It's as if the CR is being swallowed.
Curiously, if I call TxString with embedded escape codes, then I can get repeatable CRs:
TxString("CRLF test here --->\r\n",0); Now why is that? What's so special about the "\r"?!
