LPCopen UART receiving more than 1 Byte

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

LPCopen UART receiving more than 1 Byte

419 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Ano on Sun Oct 12 15:48:24 MST 2014
Hi guys,

currently I'm trying to receive more than 1 byte.
The first function I have works. It's pretty much the same, that is in the LPCopen example.
char UART_WaitForKeyAndReturnIt(void)
{
char key = 0;

// Wait for a key
while(key == 0)
{
Chip_UART_ReadRB(LPC_USART, &rxring, &key, 1);
}
return key;
}


If I try to read more than 1 key, say 4 for example, the Chip_UART_ReadRB function seems to get stuck.
This function should read 4 Bytes (so 4 ASCII signs) and calculate one 16bit value out of it. So that a user can
enter for example "1234", so ASCII sign 1, 2, 3 and 4, and value should then be 1234.
uint16_t UART_WaitForValueAndReturnIt(void)
{
uint16_t value = 0;
char key[4];
key[3] = 0;

// Wait for a key
while(key[3] == 0)//0 here is ASCII, so even if entered value is 0, it will be the ASCII sign '0' = 48
{
Chip_UART_ReadRB(LPC_USART, &rxring, &key, 4);
}

value = (key[3] - 48);
value = value + ((key[2] - 48) * 10);
value = value + ((key[1] - 48) * 100);
value = value + ((key[0] - 48) * 1000);

return value;
}


Is there some fundamental error in my code that I am just too blind to see?


/edit: Just found out: If I enter 8 values, not just 4, then it kind of works. But key[0] to key[3] won't have the first 4 values, but the last 4.
Example: I enter '12345678' then the key[] will contain: key[0]=4, key[1]=5, key[2]=6, key[3]=7.


//EDIT2: -----------------

Apparently I found the mistake. It was not in this code, but in the terminal program I used. If I send 1234567, there is a delay between the 1, the 2 and the 3. Not between 4567. Don't know why, but this seems to be the problem, so only 4567 will be registered as the one message of 4 digits, the others before are registered as 3 messages with each 1 digit long. Used anther terminal programm without that "bug" and it works now...
Labels (1)
0 Replies