I’ve set up my project as described in the documentation for 1 app, 2 processes. I can get both processes to run, as long as I don’t call (and don’t bind) the IPC call in the .adef. If I do bind them and comment back in the call, it compiles and links, but the “Application tab” says that I’m missing a binding when I try to download it to the device. It says I need:
.clientprocess.ClientComp.export → .serverprocess.servercomp.export
Which is what I have already, minus the at the front.
but if I put that with the in the adef file, I get an error saying that it can’t start with ‘<’. I already have it without the on both sides and it links fine. The server function works when it is run, but the client doesn’t run, even though the process says it’s running. It’s like it’s been left in limbo.
If I put ClientProcess.ClientComp.export → serverprocess.servercomp.export in the .adef, I get what I had above. If I put in ClientProcess.ClientComp.export → .export then I get the same message but the left side is the same, but the right side is what I have. In other words, it seems to satisfy the Dev Studio, but not the actual running agents.
I’m wondering if this has something to do with one of the components being c++ and the other is c. I’ve extern “C”, the function to get it to compile right, but obviously, that’s not enough.
So, I tried compiling the c file in C++, but I get the same issue.
2nd syntax is the usual way to access interfaces served by other apps (like Legato services); typical example: le_mdc.api; cf Modem Data Control - Legato Docs
1st syntax is what you need to use when you want to bind interfaces inside an app (your use case).
Your binding needs to be written ConnMgr.ConnTestComp.SServer → CRCPP.CRCPPComponent.SServer in your adef file to be functional.
(Side note: on this forum, use \ before < in order to escape formating for something like <root>)
Hi @daav,
Actually, I have tried that (that was the first thing I tried), and other variations, and I just get different messages of a missing binding, or the compiler doesn’t like it.
Making that exactly as you suggested yields:
Missing binding: CRCPP.CRCPP.ConnMgr.ConnTestComp.SServer → CRCPP.CRCPP.CRCPPComponent.SServer
Adding that to the .adef yields an error in the compiler/linker. I thought maybe there was some inner confusion since my app is named CRCPP, so I renamed the CRCPP to CRCPP1 in the “executables” section.
I still get the full blown missing binding message above, with the second changed with the executable name change, i.e. CRCPP.CRCPP1…
@daav,
If you make the corrections there, do you get it to work? The weird thing is the linker is satisfied, it’s only when I try to put it on the device that I see the error.
The linker is OK because at binary level, things are good. We’re talking about independent executables that will talk over IPC. Each binary is correctly linked.
I tried further (last time, I only tried the build, didn’t run it on a device), and indeed, I can reproduce your issue… At the moment, I don’t understand what’s happening with your app. When I try with a simpler app (simpleIPC.zip (121.6 KB)), I get it working.
I’ll check internally for more support on this, it’s out of my knowledge.
Got some fresh look from the team: your server COMPONENT_INIT function must return, otherwise IPC messages are never processed.
I gave a try, with my suggested fix above + forcing a return: no missing bindings anymore!
@daav,
Funny thing. If I return from COMPONENT_INIT. My app terminates. I made another thread, of which I have several, but as soon as COMPONENT_INIT returns, everything dies. I tried calling event loop, but that didn’t work either. Apparently it doesn’t stay in there, which I thought it might.
See that we have attached(CRCPP_modified.zip (147.3 KB)
) modified version of CRCPP.zip you had provided. With the modified changes, We are able to install and start the application successfully. We are not sure 100% what is the exact functionality of the code provided, But we see that data connection is up after we start the application and also SServer_GetConnectionSettings() API is getting called.
Changes we made to get it work are explained below:
We have added the changes in COMPONENT_INIT of CRCPPComponent.cpp into a separate thread as there should not be a while loop inside the COMPONENT_INIT. It is not a good practice to have a while loop inside the COMPONENT_INIT, COMPONENT_INIT should return(not exit) ASAP.
Added the ConnectService() API’s(le_mdc_ConnectService(),le_sim_ConnectService(),le_mrc_ConnectService(),le_data_ConnectService()le_info_ConnectService() ) where ever applicable as we had created the separate thread.
Other few minor changes.
Please compile the attached(CRCPP_modified.zip) modified App and cross check on your side once.
PS:We have used legato-18.03.0 version and WP76 module to verify.
@daav, @muralinagraj,
OK. Expanding on this, I want to create a FUNCTION in the same process that takes 3 uint32_t or equivalent. IPC apparently knows about “string” types, but is there any other? If so, how do I achieve this? There isn’t anything about types for IPC and uint32_t doesn’t work.
Thanks, @raf. I kept trying different things and discovered this a few moments ago. Thanks for the information as I couldn’t seem to find anything that would identify what they were. That is most helpful!