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

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

Specifications of Chameleon-AVR

• Processor To Be Evaluated: AVR 328P
• Data Bus Width: 8 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

© 2009 NURVE NETWORKS LLC “Exploring the Chameleon AVR 8-Bit”
loop “listening” for the SPI driver to place data into this shared memory region. When it detects a packet of information, it
then immediately tries to determine of the command portion of the packet is valid.
Command Processing and Execution – The command processor is a handler that interrogates the previously tokenized
input command data form the SPI channel and looks for commands in the packet. If a command is found then it continues
to process the command pattern and look for the parameters that should follow the command. The parameters (if any) are
extracted then the proper “handler” is entered. The handler is where the action happens. Each handler is connected to its
respective driver and can send and receive messages from that driver. So when a NTSC command is parsed for example,
the handler simply calls the NTSC driver and passes the request for execution. When the processing is complete, the
MCP loops again and “waits” for the next command to process.
16.3 Remote Procedure Call Primer (Theory)
Even if you don’t have a degree in Computer Science you have probably used “remote procedure calls” or RPCs in one
form or another or even invented them unknowingly! The idea of a remote procedure calls came about in the 1970’s
actually, so it’s a really old concept. The basic idea is very simple; for one process/program to be able to call/use a
subroutine or function in another process/program. More or less a form of interprocess communication.
Figure 16.4 RPC call from process to process in contrast to a DLL call.
RPCs are a little different than using DLLs or libraries since they are passive entities that are loaded on demand. RPCs
are more like making calls to another running program and using its resources (subroutines). Thus there is a client server
relationship here, and you can think of the RPC call as “message passing” as shown in Figure 16.4. There are various
forms of the technology and it’s more of a concept/methodology than a specific algorithm. For example, in some RPC
setups, the RPC call mimics the actual binary foot print of the function call. Assuming the C/C++ programming language,
here’s a solid example:
float DotProduct(float ux, float uy, float uz, float vx, float vy, float vz );
Looking at this function, depending on the compiler directives the parameters are passed by value on the stack right to
left, so there are 6 floats, each 4-bytes let’s assume. Also, there is a return value another 4-byte float, thus we need to
“pack” the parameters up into a single record and pass it along and then wait for a single float (4-byte result).
133