This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

CLI and wait_for_event

I am using ATT MTU throughput example and I noticed that using CLI (calling cli_start) causes the main while(1) loop forever. In other words, wait_for_event does not block until it gets an event. I verified it using the breakpoint.

Is there a way to use CLI and also block until we get an event?

I am using nRF52840 and S140 nRF5_SDK_14.2.0.

Parents
  • "blocking" parameter is used to configure how to print logs in certain crash situation.

    Existing solution with UART transport is not very power efficient because the peripheral is active almost all the time in order to receive characters. What is more HFCLK is always active all the time. Extra current caused by app_timer wakeup is not adding a lot of power to the equation. Especially if you are using Soft Device witch also wakes SoC.

    Solution you have proposed is of course possible but it would require to re-write CLI UART transport. To be honest I am not sure if it is worth it. With your proposal instead of cyclic wakeup we would need to have an interrpt every recived byte what could increase current consumtion compering to existing solution.

    We are no working on more robust and power efficient UART driver but it will be available in Q1-Q2 2018.

Reply
  • "blocking" parameter is used to configure how to print logs in certain crash situation.

    Existing solution with UART transport is not very power efficient because the peripheral is active almost all the time in order to receive characters. What is more HFCLK is always active all the time. Extra current caused by app_timer wakeup is not adding a lot of power to the equation. Especially if you are using Soft Device witch also wakes SoC.

    Solution you have proposed is of course possible but it would require to re-write CLI UART transport. To be honest I am not sure if it is worth it. With your proposal instead of cyclic wakeup we would need to have an interrpt every recived byte what could increase current consumtion compering to existing solution.

    We are no working on more robust and power efficient UART driver but it will be available in Q1-Q2 2018.

Children
No Data
Related