Using CLI in a non-blocking configuration?

[Dave_couling]

I've been using the CLI and also piping NRF_Log thru the same backend.  In my application there are alot of time critical operations.  I've noticed with some GPIO toggling for timing debugging that the CLI module is blocking the CPU for long segments of time.  This greatly affects my systems ability to process data in main context.  If I switch over to just using the NRF_Log and no CLI, everything aligns perfectly.  Thus I've concluded that the CLI module is the blocking culprit.  How could I configure or modify the CLI to run in non-blocking mode (using UART backend)?

I see the same issue if I try and use RTT so it seems to be backend agnostic.  I've also tried disabling the Rx task to reduce any "listening" time in the CLI system.  Any help would be greatly appreciated!

Thanks guys,

[Sigurd]

Hi,

What SDK version is this ?

Is NRF_LOG_DEFERRED in sdk_config.h set to 1 ?

[Dave_couling]

SDK 15.2,  and yes Logging is deferred.  Logging has no issues, its the CLI that is cause huge blocking times

[Sigurd]

There are a few ways to decrease time needed for processing CLI, but CLI needs a lot of time for processing, so don't expect major improvement. The less features that are enabled, the faster the processing will be.

Things that could decrease the processing time:

1)  Disable colors - it will decrease number of transferred bytes

2) Increase NRF_CLI_PRINTF_BUFF_SIZE -> Higher value will decrease number of uart peripheral accesses

[Jakub Rzeszutko]

Hi,

Please specify exactly what you think lasts a long time. We will then be able to offer more solutions.

I guess that the matter concerns the function: nrf_cli_process ?
The most time is spent on this function when CLI has to print out logs at the same time and receives and sends data related to command handling.
Printing logs requires deleting and reprinting messages on the screen.
Please write what time of service you are observing and what would be satisfactory for you?

[Dave_couling]

I observe about 20-80msec block times while the CLI is enabled.  This goes away when the CLI is disabled and I'm only using NRF_Log.  This indicates to me that the issue lies somewhere in the Rx side of the CLI

[Dave_couling]

Any update on what could be causing these long block times in the CLI module?  For now I've had to completely disable CLI as a feature in our feature.  We still use NRF_LOG for device status over UART

[Sigurd]

Hi,

I'm not seeing this kind of long block times, when I toggle on entering/exiting nrf_cli_process(). Where have you added the GPIO toggling? Maybe you can add an example that shows the issue ?

[Dave_couling]

In parallel to the CLI I have a thread which is sampling the ADC.  I'm noticing the ADC thread is blocked by the CLI (despite proper priority settings).  I toggle the GPIO every 100 samples of ADC arriving.  This timing is based on a TIMER and PPI.  The timing is perfect when only using NRF_LOG.  But when I was NRF_CLI the ADC timing is blocked and jittering

[Sigurd]

Could you check how much time you are spending in nrf_cli_process() function?

Are you printing logs with CLI when this happens?

What priority settings are you using?