erpc client non blocking request handling

[kikass13]

Hello,

I have integrated erpc into our embedded platform (modm + arm) and successfully ported the matrix_multiplication example.

It seems to me (correct me if Im wrong) that the client has to block by design after making a request to the server. It seems odd to me, because the server is capable of polling but the transport layer has to block on receive only because the client request manager seems to be unable to handle proper yielding mechanisms

I have added this feature and wanted to ask if my use case is of touch or if it would be useful for anyone.

What did I do?

• change the RequestContext class to contain a state machine
• change the IDL generated code for the client (in my case matrix_multiply_client.cpp) in a way, that allows the Request to be persistent and stateful
• change the erpc_c/infra/erpc_client_manager.cpp to handle and serve the "stateful" behavior

What would need to be done

• my changes inside the idl generated code are obviously bad, these changes have to migrate into the erpcgen tool if something like this would be relevant

I am thankful for replies :)

[github-actions[bot]]

Hi eRPC user. Thank you for your interest and welcome. We hope you will enjoy this framework well.

[Hadatko]

Hi @kikass13 personally i did changes in eRPC framework to support nonblocking feature (but enterely different). Didn't have time to upstream. I want wait until others PRs will be accepted as they are connected.

[kikass13]

@Hadatko Hmm Sounds nice, please ping me if you have some changes upstream, so that I can take a look (maybe it is exactly what I need) :)

[kikass13]

@Hadatko ping, just wanna ask if there is any progress with nonblocking client calls. Our development will soon reach the point where we have to "rollout" a lot of distributed firmwares, which will use erpc as a common messaging interface. Our threading model used will depend on whether or not erpc can handle nonblocking behavior ... (because of cooperative multitasking) .

We need to know (in a timescale of some months) if we have to use my "hacked" nonblocking implementation or the "cool and fancy" erpc-ish solution

Would be nice if there's an update on your work, Thanks :)

[Hadatko]

Hi @kikass13 , i didn't saw other PRs merged so far so i am postponing of creation new PRs as they are connected to existing one. @MichalPrincNXP do you have any time schedule when are you planing to merge ours existing PRs?

[MichalPrincNXP]

@Hadatko , which PRs integration is blocking you?

[Hadatko]

@MichalPrincNXP https://github.com/EmbeddedRPC/erpc/pulls/Hadatko

[MichalPrincNXP]

Thanks, will focus on it now and try to integrate soon.

[kikass13]

@Hadatko as far as i can tell from your PRs, my requested feature is not really implemented yet. Did I miss something? There is the ability to use a TransportArbitrator , but everything I saw uses some form of multithreading .... what if I don't want to use a threading model at all? Is there an implementation for the arbitration that is based on simple polling?

[kikass13]

@Hadatko

ping? Your PR's are through, it seems. But sadly my point was not addressed :(

• from https://github.com/ramlco/erpc/blob/develop/erpc_c/infra/erpc_transport_arbitrator.cpp

#if ERPC_THREADS_IS(NONE)
#error "Arbitrator code does not work in no-threading configuration."
#endif

seems like i have to add this myself / refactor my own solution :/

[Hadatko]

Hi, sa i mentioned i didn't create new PR as old PR were not merged. Now when the PRs are merged (recently) i can create new PR related to this issue. Unfortunatelly i don't have much time and i wanted try to improve that. So i can push PR only like proof of concept (alpha?).

[kikass13]

@Hadatko well no worries. I climbed deep into the IDL code generator and added my feature there now (i will probably wont PR it, because it disrupts how erpc is designed to operate in some major ways).

I have moved erpc into our stm32 hal library modm and chnaged the IDL (erpcgen) in a way, that would support my use case properly.

Instead of dealing with erpc's client problems, I just added a simple persistent request handle into the clients and the rpc calls return the result instantly (with valid=false). After polling this function multiple times, the valid flag will become true eventually and i get the result of the operation in the ret.value field

retMatMul = remote::erpcMatrixMultiply(matrix1, matrix2, result);
if (retMatMul.valid) {
    retMatDet = remote::erpcMatrixDet(result);
    if (retMatDet.valid) {
         MODM_LOG_INFO << std::to_string(result) << modm::endl;
         /// print matrix result & determinant
        MODM_LOG_INFO << "[Client] Matrix determinant: " << retMatDet.value << modm::endl;

this stuff works inside a protothread, so cooperative multitasking is not a problem anymore :)

I will probably use my hacked version until erpc supports something useful (regarding blocking clients) in the future. I will try to get involved if something comes up again because I am interested in keeping this thing alive and help if needed :)