Chameleon-PIC Nurve Networks, Chameleon-PIC Datasheet - Page 133

• Manufacturer Part Number: Chameleon-PIC
• Description: MCU, MPU & DSP Development Tools PIC24 & PROPELLER DEV SYSTEM (SBC)
• Manufacturer: Nurve Networks

Specifications of Chameleon-PIC

• Processor To Be Evaluated: PIC24
• Data Bus Width: 16 bit
• Interface Type: USB, VGA, PS/2, I2C, ISP, SPI
• Operating Supply Voltage: 3.3 V, 5 V
• Lead Free Status / RoHS Status: Lead free / RoHS Compliant

So we might do something like this to “pack” the parameters up into a contiguous memory space:
// this is used as transport buffer for RPC calls
CHAR RPC_input_buff[256];
// now pack the params into the array one at a time
memcpy( RPC_input_buff+=4, @ux, sizeof(float) );
memcpy( RPC_input_buff+=4, @uy, sizeof(float) );
memcpy( RPC_input_buff+=4, @uz, sizeof(float) );
memcpy( RPC_input_buff+=4, @vx, sizeof(float) );
memcpy( RPC_input_buff+=4, @vy, sizeof(float) );
memcpy( RPC_input_buff+=4, @vz, sizeof(float) );
// finally, a call would be made to the “RPC interface”
RPC_Interface( “DotProduct”, RPC_input_buff, RPC_output_buff );
Now that the parameters are packed into a single data structure, we simply call the RPC interface and pass the starting
address of the structure. The RPC interface in this case takes a string as the function name and then two pointers; one to
the input parameters and one to where the output results are stored. There is obviously and “agreement” and set of
conventions between the caller and receiver on this function and how it works, so the client can make RPC calls and the
server can respond to them. In this case, the server or other process reads the first string, determines the RPC function
then calls a handler with the two pointers. It’s up to the handler to “know” how to unpack the parameters and generate the
results via calling the local function. Thus, RPC calls necessitate a number of extra steps including:
RPC Steps:
(1) Encoding → (2) Transport to server → (3) Decoding → (4) Execution → (5) Encoding → (6) Transport back to client.
Obviously not the fastest thing in the world, however, if the computation workload is 2x or more than all the interface steps
then it’s worth it or if the local process or machine can’t perform the computation, etc. Thus, RPC calls and technology
allow a process or machine to use subroutines and resources running in another process or another processor or an
entirely different machine.
In our case, we use the concept of RPCs to make calls to another processor from the PIC’s SPI interface, thus it’s a
machine to machine call where each “call” packet is only 3-bytes. But, let’s keep exploring the general idea of RPCs and
some strategies that might help you later as you update/modify the default drivers shipped with the Chameleon.
16.3.1 ASCII or Binary Encoded RPCs
When designing an RPC system you can make it really complex or really simple. The main idea is that you want to be
able to call functions in another process, processor, machine. Decisions have to be made about the “RPC protocol” and
how you are going to do things. There are no rules for RPC calls unless you are using a Windows, Linux, Sun, etc.
machine and want to use one of the official OS’s RPC call APIs. When you design your own RPC protocol, it’s up to you.
In our case, it’s tempting to make RPC calls ASCII based and human readable. This of course, eats bandwidth and is
slower than binary. However, since it is human readable, the RPC calls take a format that look more like commands rather
than strings of bytes representing data.
Thus, one model might be to use ASCII format which would be easy to use and remember for a human. Now, the next
step up, would be to still use ASCII formatted data that is human readable, but to make it more abstract. For example,
instead of having a command like this:
We might encode “NTSC” as a single number and the command “Print” as another number, and then the “Hello” would
stay as is:
As you can see, this version of the ASCII protocol is much smaller, we have saved bytes already! It’s still human readable,
but not as warm and fuzzy. The entire RPC string is 11 bytes (including NULL terminator). But, can we do better? Sure, if
we encode in binary then we don’t send the longer ASCII text, we send the actual byte data. Therefore, the binary
encoding would look like:
NTSC Print Hello
25 0 Hello
© 2009 NURVE NETWORKS LLC “Exploring the Chameleon PIC 16-Bit”
133