What is different LPUART of SDK EAR v0.8.6 and RTM v2.0.0?

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

What is different LPUART of SDK EAR v0.8.6 and RTM v2.0.0?

1,755 Views
kbj
Contributor IV

Hi,

I use S32 DS for ARM.2018.R1 and SDK EAR v0.8.6 and RTM v2.0.0.

I found something strange during UART SAMPLE code analysis.


The lpuart samp of EAR0.8.6 sdk and the lpuart sample of RTM2.0.0sdk have been modified to echo one word at a time.
And I sent the attached file and confirmed the uart message.
The sample of EAR0.8.6 sdk showed the contents of the file normally.
However, the RTM 2.0.0 sdk was unable to display the contents of the file due to a frame error.

What is the difference between the RTM 2.0.0 sdk and the EAR 0.8.6 sdk in the UART function?
What should I do to correct the error in the RTM 2.0.0 sdk?

I attached the code and file.

RTM 2.0.0 result

RTM2.PNG

EAR0.8.6 result

EAR.PNG

Thanks and best regards,

Byungju.

Tags (1)
0 Kudos
7 Replies

1,235 Views
B46399
NXP Employee
NXP Employee

Hi Byungju,

Indeed, starting from SDK BETA 1.9.0 release, we slightly changed the implementation of LPUART driver, for consistency reasons.

Briefly, there are two main changes:

 1) the Rx/Tx logic is now only enabled when a reception/transmission is in progress (as opposed to the old implementation where rx and tx were enabled whenever the driver was initialized); this allows a better management of the rx messages especially, since junk data on the line does not affect the driver state, unless a reception is launched by the application. For this reason, receiving a string in multiple calls to ReceiveData for each byte doesn't work anymore, since disabling/reenabling the receiver takes too long and some bytes are missed eventually. This usecase can now be implemented using callbacks.

  2) the callback approach - callbacks are now called only when the transfer is complete and not after each byte, as they used to be; this makes more sense from the application perspective and it's also easier to use. We also added setBuffer functions for both tx and rx; these can be called from the callback to refresh the data buffer, in order to implement a continuous transfer usecase.

We updated the LPUART example and documentation to highlight these changes. Please refer to the doxygen documentation in the RTM 2.0.0 release and also try to use the latest example. 

Hope this clarifies your question. Please reply if you need further details, I'll be happy to assist you!

Regards,

Vlad

0 Kudos

1,235 Views
kbj
Contributor IV

Hi Vlad,

Currently, the structure seems to have restrictions on the implementation of echo function to transmit 1 byte data.

How do I implement the echo function to transfer the received 1 byte data for normal operation?

Thanks and best regards,

Byungju.

0 Kudos

1,235 Views
B46399
NXP Employee
NXP Employee

Hi,

Did you check the example included in RTM 2.0.0? Doesn't that implement the usecase you need?

Thanks,

Vlad

0 Kudos

1,235 Views
kbj
Contributor IV

Hi,

I attached the code with the problem in the first question.
Please refer to the first question and code.

Best regards,

Byugnju.

0 Kudos

1,235 Views
B46399
NXP Employee
NXP Employee

Hi again!

Sorry for the delayed response! The example in RTM considers a maximum input buffer of 256 characters. I think that's why it doesn't work, the text you feed from the console is way bigger and it overflows somewhere.

Could you please try increasing the BUFFER_SIZE macro defined in main.c file and check if works?

Thanks,

Vlad

0 Kudos

1,235 Views
kbj
Contributor IV

Hi, Vlad

I am sorry for delayed response.

I does not use max buffer size.

I use rxCallback function like below.

/***************************** call back*************************/

/* UART rx callback for continuous reception, byte by byte */
void rxCallback(void *driverState, uart_event_t event, void *userData)
{
    /* Unused parameters */
    (void)driverState;
    (void)userData;

    /* Check the event type */
    if (event == UART_EVENT_RX_FULL)
    {
#if 0 /*  */
        /* The reception stops when newline is received or the buffer is full */
        if ( (bufferIdx != (BUFFER_SIZE - 2U)))
        {
            /* Update the buffer index and the rx buffer */
            bufferIdx++;
            LPUART_DRV_SetRxBuffer(INST_LPUART1, &buffer[bufferIdx], 1U);
        }
#endif
    }
}

/*************** main ***************/

while (1)
  {
      /* Receive and store data byte by byte until new line character is received,
       * or the buffer becomes full (256 characters received)
       */
      LPUART_DRV_ReceiveData(INST_LPUART1, buffer, 1U);
      /* Wait for transfer to be completed */
      while(LPUART_DRV_GetReceiveStatus(INST_LPUART1, &bytesRemaining) == STATUS_BUSY);

      /* Check the status */
      status = LPUART_DRV_GetReceiveStatus(INST_LPUART1, &bytesRemaining);

      if (status != STATUS_SUCCESS)
      {
          /* If an error occurred, send the error message and exit the loop */
          LPUART_DRV_SendDataBlocking(INST_LPUART1, (uint8_t *)errorMsg, strlen(errorMsg), TIMEOUT);
          break;
      }

      /* Append string terminator to the received data */
      bufferIdx++;
      buffer[bufferIdx] = 0U;
#if 0
      /* If the received string is "Hello Board", send back "Hello World" */
      if(strcmp((char *)buffer, "Hello Board\n") == 0)
      {
          strcpy((char *)buffer, "Hello World\n");
      }
#endif
      /* Send the received data back */
      LPUART_DRV_SendDataBlocking(INST_LPUART1, buffer, bufferIdx, TIMEOUT);

      /* Reset the buffer index to start a new reception */
      bufferIdx = 0U;
  }

Thanks and best regards,

Byungju

0 Kudos

1,235 Views
kbj
Contributor IV

Hi,

This is the result of modifying the example included in RTM2.0.0 for the purpose I need.
As a result, the above problem occurred in RTM 2.0.0.
In EAR0.8.6, it works well and RTM2.0.0 has a problem, so I asked about the project.

Best regards,

Byungju

0 Kudos