BitCloud UART Receives Only One Byte

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a problem sending a stream of bytes to an Atmega256RFR2 XPRO running a BitCloud application. I'm using callback mode for both TX and RX. Transmitting works fine and I can print text strings to my PC terminal, but when I try to send more than one byte using, for example, Atmel Studio's Terminal, the UART receive callback indicates received length = 1, and received data is the first byte of the group I send. The UART receive callback then gets called again with the length = the number of the remaining bytes I sent, but the received data is not correct.

This topic has a solution.

Beshoy R. Samy

Embedded Systems Engineer

Cairo, Egypt

Last Edited: Fri. Oct 16, 2015 - 12:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Can you show your relevant code here? Like UART initializations and callbacks.

 

The behavior with one byte is correct, the callback is called as soon as possible and that happens faster than the second byte is received. But the fact that on the next call you have full length tells me that there is a significant processing delay. It might be your callback handler or debugger, for example.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Alex, thanks for replying.

 

Here's my UART code:

 

APL_OperationResult_t initUsart(void) {
    usartDescriptor.tty = USART_CHANNEL_1;
    usartDescriptor.mode = USART_MODE_ASYNC;
    usartDescriptor.baudrate = USART_BAUDRATE_115200;
    usartDescriptor.dataLength = USART_DATA8;
    usartDescriptor.parity = USART_PARITY_NONE;
    usartDescriptor.stopbits = USART_STOPBIT_1;
    usartDescriptor.rxBuffer = usartRxBuffer;
    usartDescriptor.rxBufferLength = USART_STRING_LENGTH;
    usartDescriptor.txBuffer = NULL; // Use callback mode
    usartDescriptor.txBufferLength = 0;
    usartDescriptor.rxCallback = usartRxCallback;
    usartDescriptor.txCallback = usartTxCallback;
    usartDescriptor.flowControl = USART_FLOW_CONTROL_NONE;
    if (HAL_OpenUsart(&usartDescriptor) != -1) {
        return APL_OP_SUCCESS;
    } else {
        return APL_OP_FAILURE;
    }
}

void usartRxCallback(uint16_t length) {

    usartReceivedLength = length;
    HAL_ReadUsart(&usartDescriptor, aplUsartRxBuffer, length);
    aplState = APL_STATE_USART_DATA_RECEIVED;
    SYS_PostTask(APL_TASK_ID);
}

 

I was using a debugger when I experienced this behavior, so I guess you're right that's why I'm getting the rest of the transmitted bytes on the second callback.

 

It's weird though that the callback's expected behavior is to get called when the first byte is received, while there's a length argument in it. What is it used for then if it's always 1?

 

What is the best way to receive a stream of bytes?

 

Thanks for your help, and sorry for my delayed reply.

Beshoy R. Samy

Embedded Systems Engineer

Cairo, Egypt

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The parameters indicates hoe many bytes are available in the buffer. When the first byte is received, it might be the last, so there is no sense in waiting, so HAL indicates it. While you process this byte, a few more might accumulate in the buffer. If this happens, another callback will be called showing new number of bytes received.

 

You need to accumulate how many bytes yo have received and only call actin when expected number of bytes is received, or end of line symbol of some sort. It all depends on the protocol you are using.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for your help Alexru, I will try one of the methods you suggested.

Beshoy R. Samy

Embedded Systems Engineer

Cairo, Egypt