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

• 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

Referring to the figure, the client/master processor issues commands over the SPI interface which the master control
program running on the Propeller chip, processes in a large message dispatching loop to the proper driver object. Thus, to
add messages or functionality we have to consider the following things:
1. Will the Propeller driver need another object or driver? If so, we need to add this and then add code to the main
message dispatcher loop that passes messages from the client to the new Propeller object.
2. If we add messages to the system, we need to make sure they are unique and don’t overlap any other messages. Its
good practice to not use message ids we have already used since you want to be as compatible as possible. Both the
Propeller driver cham_default2_drv_112.spin and cham_twi_spi_drv_v010.h contain the master message id lists
(copies) and the various library API files have functions that wrap the use of the messages in higher level functions.
3. There are three classes of messages we can add;
33.1.1 Adding SPIN Driver Support for the Status LED
As we designed the Chameleon we added a status LED to it. The idea of this LED was for the Propeller to use it to
indicate status, state, etc. For example, when the Propeller boots our driver it blinks 3 times to indicate that everything is
good to go, driver is ready to receive messages from the client/master. However, after the we were all done designing
everything and the drivers were written. We left out messages to control the LED from the client/master, but I thought,
hmmm, I will hold off on this and later us it as the perfect example of adding some messages to do something useful.
Thus, this example was born of that motivation. With that in mind, this is a good exercise since at first you will want to
make small changes to the master driver, but not re-write it. Anyway, so the first thing you need to do is decide what new
functionality you need. In this case, all I needed was to control the LED, turn it on and off. So, the first thing you need to
do is copy the Propeller driver and re-name it something else. In this case, I made a copy of:
and renamed it to:
This way if I mess something up, I can go back to my original. Then I reviewed the messages at the top of the code and
found where new messages can go and added two new commands 100 and 101, here’s a snippet of what the constants
looked like before and after:
Before
Class 1: (Same object more functionality). There is already a driver for the messages, the driver supports some
extra functionality that we haven’t exposed yet and wish to. The sound driver for example falls under this
category. I barely exposed its true power, so you might want to add more messages. In this case, you have to add
the messages to the .H file as well as the SPIN file. In addition to this you need to add more cases to process and
dispatch the messages in the SPIN driver and then on the AVR C/C++ side you might want to add more API
functions.
Class 2: (New object new functionality). The second case is when you want to add a completely new driver object
and run it on another processor on the Propeller. In this case, you will load the object in at the top of the main
driver, start it up, and then add messages along with message handlers to the main message dispatcher loop.
This is the most complex case.
Class 3: (Simple messages that can be processed in place). Finally, the last case is the easiest and the one we
will illustrate. This is the case, where we want to add some functionality to the main Propeller driver, but we can
run that functionality right on the main processor that is running the message loop. Examples of this are the
Propeller local port driver. Messages run right on the main SPIN interpreter, there is no need to add another
processor.
cham_default2_drv_112.spin
cham_default2_drv_112_modified.spin
© 2009 NURVE NETWORKS LLC “Exploring the Chameleon AVR 8-Bit”
250