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

• 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

Additionally, there might be “timing constraints” on how fast you can read bytes of data from the SPI device you are
dealing with. Thus, you might have to put a delay after each read, etc.
_________________________________________________________________________________________________
Function Prototype:
Description:
Example(s):
Function Prototype:
Description:
single function is what is used to send and receive information to and from the Propeller chip. Each command has 3-byte
always. The first byte cmd is the command 0..255 that represents what you want to do. These are the same commands
that are listed in the header file and the CHAM_DEFAULT2_DRV_V112.SPIN message dispatcher is listening for. The
second byte data is the first 8-bit data operand, the 3
require 16-bits, then data and status are concatenated to form a 16-bit operand like this:
Thus, data is the lower 8-bits and status is the upper 8-bits.
For commands that only require 8-bit operands set status to 0. If you recall, SPI is a “circular” buffer system, so each byte
we send out, we receive a byte back, thus when you call this function, 3 bytes are sent, 3 bytes are received. Currently,
the function returns a 16-bit value representing the first two returned bytes, the 3
since this is such an important function, let’s take a look at the source for it:
As you can see the SPI_Prop_Sen_Cmd(…) function waits on a flag while calling a hidden function that actually does the
work. Let’s talk about that for a moment. In multiprocessor systems, when once processor requests another processor to
do something, the whole point of multiprocessors, is that the originating processor can continue to do more work in
“parallel”. Thus, we need code to consider this such that say processor A (the AVR) sends a command to the processor B
(the Propeller). Now, processor A goes about its business while processor B executes the command. But, the processor A
finishes something and then requests processor B to do something else – here is the problem. Processor B can’t perform
another function until it completes the last requested command, thus we need a mechanism that blocks processor A and
makes it wait for processor B when this set of conditions occur. That’s what the code above does. So if processor A, the
AVR, ask for too much, too fast, processor B, the Propeller, says “hold on a minute, let me finish the last thing!”.
unsigned char SPI_Write(unsigned char data8);
unsigned char SPI_Read(unsigned char data8);
long SPI_Prop_Send_Cmd(int cmd, int data, int status);
msb [status, data] lsb
None.
blocking versions of the write and read functionality or something else.
These functions are currently empty place holders, you might want to fill them up with special non-
SPI_Prop_Send_Cmd(…) is the workhorse of the entire inter-processor communications system. This
rd
byte status is the 2
© 2009 NURVE NETWORKS LLC “Exploring the Chameleon AVR 8-Bit”
nd
8-bit data operand. For commands that
rd
byte is used internally for now. Also,
165