SCI: LF works, but not CR

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SCI: LF works, but not CR

Jump to solution
896 Views
irob
Contributor V

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"?!

Labels (1)
0 Kudos
1 Solution
483 Views
bigmac
Specialist III

Hello,

 

When you send the string data, you are waiting for TDRE flag to become set before sending the next character.  However, you are not doing this when you separately send the control characters.

 

Regards,

Mac

 

View solution in original post

0 Kudos
2 Replies
484 Views
bigmac
Specialist III

Hello,

 

When you send the string data, you are waiting for TDRE flag to become set before sending the next character.  However, you are not doing this when you separately send the control characters.

 

Regards,

Mac

 

0 Kudos
483 Views
irob
Contributor V

Huh, what do you know?  It was right in front of me the whole time.  Thanks, bigmac.

0 Kudos