Redirect SHELL GETCHAR to custom implementation missing?

[robertoquilez]

In the previous version, a nice feature that now is missing was to redirect the GETCHAR (SHELLReveiveDataCallBack) to a custom implementation. For instance, this enabled to implement a GETCHAR version with a SHELL freertos task in SUSPENDED STATE while waiting for a character. 

Is there a way to redirect the GETCHAR to a custom application as before with the new SDK shell version?

By the way, the SHELL in SDK 2.5.0 documentation (MCUXpresso SDK API Reference Manual_MK66F18.pdf) does not match the source code.

Documentation refers to : 

SHELL_Init(&user_context, SHELL_SendDataCallback, SHELL_ReceiveDataCallback, "SHELL>> ");

When the SDK source code:

    shell_status_t SHELL_Init(shell_handle_t shellHandle, serial_handle_t serialHandle, char *prompt);

[jorge_a_vazquez]

Hi Roberto Quilez

The implementation in the SDK 2.4 version uses callbacks for the "send" and the "receive" functions. Now in SDK 2.5, those parts are managed in the serial_manager component, so if you want to change this, you can do it in the SerialManager_StartReading function in the serial_manager.c/.h

Regarding the documentation, thanks for pointing out this, I will report this for future releases.

Hope this information helps
Have a great day,
Jorge Alcala

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[robertoquilez]

Thank you very much, Joge,  for your rapid response.

From my personal use case and personal point of view,  I think that it is a pity to have to modify the source code of one of the SDK components.  Every time I update the SDK, I might loose my modifications and I will have to take care of including them manually.

I think the previous implementation was more convenient as it was part of the shell initialization settings.  Actually I have the impression that it is much more complex (and limited) that the previous one.