• State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 21 subscribers
  • Views 1579 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to make remote call of functions, like through RS232.

Vladimir Grekhov

Hi All,

I have some communication protocol with PC(RS232), and I'd like to call functions remotely. Any smart ideas, how to pass them?
Or if someone had attempts and has comments on it?

Thanks,
Vladimir

Parents Reply Children
  • 0 in reply to Bahri Okuroglu

    Yes, something like this. I read a bit about RPC, and wonder if someone solved this task using C51.

    Thanks,
    Vladimir

  • 0 in reply to Vladimir Grekhov

    Yes, I've implemented both RPC client and server processes using C51. After studying the RFC's to understand the RPC model, a stripped-down implementation can be easily realized, even for small projects.

  • 0 in reply to Dan Henry

    Hi Dan,

    It was good to hear.
    Can you send links to the RFC's...or may be a small example gould be helpful too.

    Thank you,
    Vladimir

  • 0 in reply to Vladimir Grekhov

    http://rfc.net/rfc1831.html is titled "RPC: Remote Procedure Call Protocol Specification Version 2" and http://rfc.net/rfc1832.html is titled "XDR: External Data Representation Standard".

    These specifications/standards have a lot of "baggage" that, if you are in control of (or can define) both ends of the comm link, is not required for a successful implementation. I just use them as a general model. For example, let's assume one end is an embedded 8051 and the other end is a PC. Rather than having some XDR translation code that all data objects pass through, I simply explicitly state in a protocol specification document what the XDR is, and give preferential treatment to the "inferior" processor by stating that multi-byte data objects "on the wire" or "in the air" are to be in C51's native byte order (big-endian) -- let the superior (in terms of horsepower/memory) processor deal with translation issues. Rather than having a generic RPC compiler, I explicitly state in the protocol doc how each remote procedure's CALL and REPLY structures are organized.

    When my PC client process wants to call a procedure in the embedded system, a client stub function builds up a CALL structure, encapsulates it inside a datalink protocol, ships it to the remote RPC server via whatever physical comms channel is appropriate, and waits for a REPLY structure to come back. When the embedded system receives the CALL structure, it passes it to the server process which uses the procedure number in the RPC header to dispatch the CALL to the appropriate function, passing pointers to the received CALL argument structure and to a REPLY structure. The procedure/function performs its work, fills in the REPLY structure, and returns to the server, which then ships the REPLY back to the remote RPC client.

    The semantics are the same when the embedded system is the client and the PC is the RPC server. Some of my projects have had both client and server processes running concurrently on both ends of the link. If your comms architecture can utilize the RPC (subset) model, it's a simple and extensible way to go, IMHO.

    --Dan Henry