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

• 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

so that you are insulted from what’s really going on. This is not true with microcontrollers. The AVR 328p series has
hardware USARTs (we are using for UARTs) to take the load off the bit banging, polling, and transmission and reception
of actual bytes, but we still need to write a lot of software on top of the hardware to develop an API that is useful.
There are lots of ways to approach this; for example, if you are happy with waiting for characters you could write a receive
function that simply waits for the reception buffer to get a character, this is slow though since you have to poll for it.
Secondly, you could do the same with your transmission software and write a loop that constantly writes bytes to the
transmit buffer while waiting for the bytes to transmit before writing another. These methods are fine, but I wanted to give
you a little bit more to work with as a starting point, so you can see how you might develop a more robust serial
communications system. Referring to Figure 18.1, this is the architecture of the UART module we have developed. The
UART driver API is an interrupt driven system with circular buffers on both the incoming and outgoing characters. The
system is easy to understand from a design perspective; interrupts are setup to fire when both a character has been
received and when a character has been transmitted. These interrupts both call “interrupt service routines” (ISRs) that
have been developed to support “circular buffers”. These circular buffers allow the calling functions to place characters
in the outgoing buffer and queued for transmission as well as for characters to fill up the receiving circular buffer until the
caller wants to read characters.
The idea of this being the functions that transmit and receive characters do not have to wait, they make to functions that
interrogate the circular buffers and either insert or remove characters. This way the system is responsive and only if the
buffers are overflowed is data lost. For example, say you want to transmit the string “Hello World!”. Normally, you would
have to transmit the “H”, then wait, “e”, then wait, etc. But, with interrupt driven architecture and the buffers, the string is
simply copied into the circular output buffer and the interrupt sends the string out for you.
The receiver is the same, you can interrogate the circular buffer anytime you wish. For example, say that you know the
transmitter on the other end is going to send a single string “The World is Fine.” back to you. This string fits into the
circular buffer, so you don’t have to interrogate the buffer immediately and worry about loss of data. You can finish you
activities, maybe a disk I/O or some rendering then at your leisure call the receive function which will check the buffer for
data and send it to you.
Referring to Figure 18.1 once again, you can see some of the details of the system. There are two functions similar to the
C putc(…) and getch(…) called UART_putc(…) and UART_getc(…) these functions directly access the transmit and
receive buffers for you. Thus, from a software perspective all the work of polling the transmission and reception hardware
is taken care of for you and all you have to do is use these two functions (and pay attention to their return values)!
So the idea of our UART module is that it loads up the ISRs for communication, set the USART hardware up (speed, bits
per character, parity, etc.) and then you communicate via a collection of functions. Now, although we can use the put and
get class functions, we have developed a number of other functions that help print strings, numbers, as well as directly
access the USART transmit buffer, so you can mix and match you serial library use as you wish or write you own.
18.2 Header File Contents Overview
The “UART and RS-232” module header CHAM_UART_DRV_V010.h has a few globals as well as the #defines, so at
least there is something interesting to talk about! Let’s begin with the #defines:
The #defines are trivial; simply a constant for a convenient baud rate as well as the size of the circular buffers. You can
make these any size you wish, but memory is at a premium, so keep it in mind. If you are going to be using a lot of serial
communications and know you are going to send large strings or receive large strings and not be able to interrogate the
ARDUINO
TIP
The Arduino uses similar serial methods from the “serial” class named serial.begin(…),
serial.print(…), serial.read(), etc. learn about them in the Arduino documentation.
© 2009 NURVE NETWORKS LLC “Exploring the Chameleon AVR 8-Bit”
147