shell_write

[Chan_17]

Hi NXP Team,

i am using KW45 as receiver and EATT_central.c example i am using as base code.

from transmitter  i will get multiple bytes of data via BLE . we checked the time its taking to print data in receiver using shell ,its taking around 1ms to 2ms  for printing 10bytes. but i am getting huge data from transmitter and to print that its taking too much time.

we tried with printing more than 10 bytes to 200 bytes ,its taking too much time.

Is nxp can confirm is shell used in EATT_central.c is blocking oor non blocking ?

please suggest what is the optimised way to print data over UART?

currently i am using Queue to take data from BLE and convert that raw data , i am trying to print that converted data using shell_write.

is there is role of Baud rate in data printing using shell?

[luis_maravilla]

Hello,

Could you help us confirm is you are using the KW45 from a NXP development board [KW45B41Z-EVK or KW45-LOC] or in a custom board?

Could you help us describe details about the implementation on converting raw data and printing using shell_write, please?

The example EATT_Central uses non-blocking when using "HAL_UartSendNonBlocking" in [fsl_adapter_lpuart.c] to print in shell.

To print data over UART both blocking and non-blocking UART APIs are provided, though it is recommended to use a non-blocking implementation. Blocking functions polls the sending queue, waits for the sending queue to be empty. The non-blocking functions send/receive data using an interrupt method, return directly without waiting for all data written to the transmitter register.

In file [fsl_adapter_uart.h] the baudRate_Bps is defined for 115200 in the description for Initialize UART.

For more information about the UART Driver Non-blocking information please refer to: MCUXpresso SDK API Reference Manual: UART Driver and for the User interface usage response on the EATT Central please refer to: EATT Central — MCUXpresso SDK Documentation

Best Regards

Luis

[Chan_17]

Hi

Board : KW45 EVK 

SDK: SDK_25_06_00.KW45B41Z83xxxA

Convesion: we re receiving 210 bytes of 32 samples on  every 30ms of gx,gy,gz and we are converting that raw data to user readable data using loops and some mathematical calculations(shifting, multiplication,devision).

210 bytes after conversion we are priting using shell_write() shell_writeDec() shell_writeHex().

[luis_maravilla]

Hello,

Thank you for the confirmation,

To improve performance and response, it's recommended to use smaller attribute value sizes, ATT can only send 23 bytes of data as default length in a radio packet to maintain a logical mapping between radio packets and ATT packets.

For more information about this you can consult Chapter 5.1.2 in Bluetooth Low Energy Application Developer’s Guide

This series of community post also explains about sending long attributes if can contribute to your project. Bluetooth Low Energy - Working with long attributes on a GATT Server - Part 1: ATT_MTU - NXP Communi...

In my previous comment are the information and links regarding the questions on UART Non-blocking and Baud rate.

Best Regards

Luis