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

• 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”
Technical Overview
This demo really shows off the UART and bi-directional communications. Not only are we printing to the UART for display
on the terminal on the PC, but we are getting input from the terminal and processing it, so it’s a very complete two way
communications demo. Also, there are some animations and fun techniques that are used to display the logon logo and
other effects to “sell” the game. For example, the intro logo is an array of data that is used to print out “WarGames”:
The interesting thing about this array is that its defined in FLASH memory rather than SRAM, so this demo shows how
you do that. Notice the keyword PROGMEM after the array declaration? This instructs the compiler to place the array in
FLASH rather than SRAM. However, this isn’t without side effects. Now that the data is in FLASH, you have to use special
functions and techniques to access the FLASH data, but this is more of an inconvenience that anything else. For example,
later in the code when the logo is displayed, the following function reads the data, displays it on the terminal, and makes
some sounds:
I have highlighted the special function needed to access FLASH based storage, the pgm_read_byte(…) function. This is
all you need to get to the bytes of the FLASH with a pointer.
The remainder of the main program is more or less printing strings with timing and a bit of conditional logic; however,
there is one function that is the workhorse of the program and that’s the Get_String(…) function. When programming,
most programmers are completely oblivious to the underlying code in printf(…) or scanf(…) and so forth, but in
embedded systems we can’t use these calls since they usually have no meaning and we need to write them ourselves!
Alas, in this case, we need some kind of simple single line text editor, so the user can type on the screen, backspace, etc.
and do a few reasonable “edit” related keystrokes. The terminal program has no idea about this and nor does the UART,
the UART just receives ASCII characters, thus we need to write a single line text processor to make this work. The
function listing of this code is below.
236