erpc *-bus compatible idl function generation

[kikass13]

Hi,

i have implemented the use of erpc via can bus in my stm32 project.
As far as I can tell, the erpc IDL (erpcgen) tooling will generate fixed ID's for differentiating / managing the different rpc function calls. (id 0, 1, 2, 3 ... N).

When utilizing a (1:*)-Bus, the slaves on that bus can all receive the rpc data. Normally, bus arbitration is done via various addressing schemes (can, i2c, ethernet etc).

In some use case, it is not possible/desired to rely on bus arbitration and instead broadcast packages (erpc calls) (canId 0x00, ethernet x.x.x.255). The current implementation of erpc does not tolerate that, because the function calls on the server/client are only separated by whatever ID was generated via the IDL. If a client would send a rpc call with id 0, that function could travel to 3 different servers and they would all execute whatever 0 means for them (probably different functions altogether).

Is it feasible to change the ID utilized by the erpcgen IDL tool to be a hash (32+bits) to differentiate between message function types instead? The erpcgen tool could also work recursively through a project (containing .erpc files for all servers and clients in the system) to make sure, that each and every individual erpc function has a different id (hash) so that no hickups occur.

This would allow (or is the first step to a) multi server/client approach in transport agnostic systems.

[Hadatko]

H i am not sure if semi random hash would solve somthing. Instead of that maybe we can have just offset... Or program id. So you would have program id, interface id and function id.... Program id sounds good to me. So far you can set manualy id for each function using annotations in current solution. But if you agree with program ID we can add this one. Or offset... Sounds easier to implement and should work.

[kikass13]

An offset is fine, but a manual one is kind of weird. The hash suggestion mainly comes from other bigger idl genertion framworks like the one used inside of ROS (for example). The non trivial part is letting the IDL automagically differentiate ALL needed erpc message definitions in a way that

• lets erpc functions be unique at all times
• lets erpc functions be the same after regenerating the message (if nothing changed)

Only a hash (which takes into account message contents, return values, parameters and it's name) can properly encode the message types in a future proof manner.

This is necessary, in case someone is recording / logging bus activity and wants to recreate whatever happened on the bus. To reconstruct messages, one would need to generate the same message identifier (with the in the recorded .erpc message declaration) and decode the messages using that message identifier. Only then is one able to reconstruct a past event properly

[Hadatko]

I understand now. Well sounds good to me. So simple solution could be take function declaration as string and encode it (hash,...) and output would be its id

[kikass13]

would probably work. I mean ... if the message already exists, it's name / arguments / retun values are essentially the same. Which means that duplicate message types should not be a problem (because the two different functions already behave identical).

[Hadatko]

I would apply this principle also for interface ID. So combination interface and function should make it more rare. The is still same risk as you described but much smaller than now.

[kikass13]

@Hadatko i have a proof of concept working which uses an md5 hash from the function prototype string

• <FunctionType> <FunctionName>(<FunctionParams>)

I have edited the code structure in such a way, that the uint32_t methodId is now replaced with a 129 byte (char[33]) data structure (md5 + \0 string) and it seems to work fine.

It should theoretically allow multiple clients and servers on the same bus, each of them sending and receiving rpc information which should be identified properly, because servers can now identify functions based on a truly unique Identifier.

Although i Have to say that the underlying write functiosn for header and such are messy (even without me interfering) ... :p
I will clean this up and update the IDL as well as the erpc internals and create a PR at some point (after im relatively satisfied).

Does someone need this?

[kikass13]

hmm for anyone interested:
#207