I'm trying to dynamically create objects over serial, which is probably similar to the RPC library.    The thing is, I'd like to use my USB serial line for other communications as well, so I don't want to hand over full control to SerialRPCInterface.

As an example, suppose I have an LED class, with a member function blink.    I want to be able to create these objects over serial by passing a command like "LED p15", and then code on the microcontroller will take care of blinking all of the defined LEDs.   I'm just wondering how I can go about converting the string "p15" into a PinName object I can use as an argument to my LED constructor function.

Hi Jimmy

The RPC sounds like it could still be of use to you.  To use RPC you don't have to use the RPC Interface library so you don't have to give the serial port over to it completely.  You just need to pass a string into the rpc function, the RPC interface library is just one way of handling the strings from the serial port.

So perhaps you could create your own code for receiving information over serial which recognises when you want to send the command to RPC (may be when it starts with "/") and when you want to process it in your own way. Or your code could interpret the serial information and then create the necessary string to pass into the rpc.  If you use RPC then you also won't have to write any of the code for creating your objects and you'll be able to control them over rpc as well.

As there quite a few benefits to using the rpc format for communicating perhaps you could consider returning your data using rpc as well, for example using the RPCFunction objects to trigger the return of a string of data in csv format. This way all of your communication would be in the rpc format and so you'd be able to easily extend your communication to control other mebd interfaces etc.

Alternativly, and to answer your question directly to convert "p15" into a pin name object you should be able to use some of the tools that the RPC defines and uses. Converting strings to arguments is one of the key tasks of the rpc handler and so rpc.h defines a function:

PinName parse_pins(const char *str)

If you pass your string into this function it should return the PinName. You'll need to include rpc.h

Hope some of these ideas are of use

Michael

Thanks Michael.

The parse_pins function seems to be exactly what I was looking for.

I've been considering switching my serial communication over entirely to RPC, but the apparent complexity of adding RPC support to my classes and member functions had so far kept me away from it.   I think I've finally figured out the basics, so I'll start implementing it and publish some sort of guide to help other people who are having a little trouble getting started.

Here's the guide:

http://mbed.org/users/JimmyTheHack/notebook/creating-custom-rpc-classes/

My wiki formatting may be off though, since my code blocks seem to be having trouble representing things that look like html tags. <like this>

I got member functions working but was unsure whether there is a method recommended for accessing the object variables of an RPC-able class.  Am I best off just creating a separate write function for each variable?  Or is there a way to access the variables directly?   For instance, I'm interested in being able to define variables such as openingTime, closingTime and exposureTime for a shutter object over RPC.

Hi Jimmy

Great working gettting RPC working and writing it up.

Theres no way of accessing the member variables of an object over RPC so yes you will have to write access methods. This is due to the way the RPC works at the moment. The line:

{ "toggle", rpc_method_caller<int, LED, &LED::toggle> }

Generates a function from the templated function declarations of rpc_method_caller which knows how to parse the arguments string for toggle and call the method pointed to by &LED::toggle.

This can only take methods so you have to write a method which sets or gets the members variables.   Writing access methods for any member variables you want to read or write to and not having any public member variables is sometimes considered OOP best practise anyway, for various reasons such as keeping the implementation of the class completely speparate from the interface that the rest of your program (or in this case the RPC)  uses to interact with the class. This could be useful if an abstraction of your class was going to implement things very differently. The approach of using access fucntions also gives you the opportunity to check the values going into your member variables are valid, ie within a certain range.

Michael