Atmel AVR 2006 Design Contest

Project Number: AT2661

Project Title: Voting Pads using AVR over RS-485
AVR Component: ATmega88
Project Description

Voting Pads using AVR over RS-485

Most of us have seen the TV game show

“Who wants to be a Millionaire?” in one or
other of its flavors broadcast around the world.
One of the Lifeline that can be used by the
contestant in the Hotseat is “Ask the
Audience”. The Contestant asks the studio
audience which answer (out of the 4 options:
A, B, C or D) they believe is correct.
Members of the studio audience indicate their
choices by pressing the key on their keypad
corresponding to the correct answer. The
audience vote is displayed immediately on the
Contestant and Host's screen.
Figure 1 Voting Pad

The system we present here is made up of

many voting pads each consisting of an ATmega88, a MAX485 and a couple of LEDs and
pushbuttons. The keypads communicate over the RS-485 bus which is nothing but a pair
of twisted cables similar to ones which exist inside a CAT5 Ethernet cable.
The front-end of the system consists of a Java application running on a PC which
generates a bar graph similar to the one we see in the TV game show. A separate circuit
which we call a “RS232-RS485 Bridge” is used to connect the network to the PC via its
serial port.
We chose to write the program for the microcontrollers in C using the freely available
avr-gcc (also distributed as a part of WinAVR) compiler. For the front end we used the
Eclipse Editor to ease our task of coding the Java application.

THE VOTING PADS

Each of the voting pads sport an ATmega88 microcontroller. The microcontroller takes
care of reading the status of
the push buttons, lighting
the corresponding LEDs and
communicating with the
host computer. MAX485
driver ICs are used for

Figure 2 Block Diagram of a voting pad

converting between TTL and RS485 signaling techniques. MAS485 is a half-duplex
RS485 driver which can be operated with speeds upto 2.5 Mbps. If you are operating in a
noisy environment and noisy spikes are common on the bus, then it is recommended that
you replace MAX485 with MAX483. MAX483 are slew rate limited and can only be
operated upto 250000 bps which is okay for us since we are operating at only 115200 bps.

Serial communications at such high speeds require precise timing and hence we have
used an external 3.6864 MHz crystal to generate the clock for ATmega88. Any other
crystal which is a multiple of the baud rate we are using would have worked. One thing to
keep in mind is that the ATmega88L which is a low voltage version can only be operated
upto 8 MHz unlike the non ‘L’ version which can be operate upto 16 MHz. If one wants to
decrease the component count then the internal 8 MHz RC oscillator of ATmega88 can
easily be used for speeds upto 38400 bps.

The MAX485 transceiver consists of a separate transmitter and receiver which must be
enabled mutually exclusively to either transmit or receive data to or from the bus. One of
the pins of ATmega88 is assigned to take care of switching between transmission and
reception. A pull down resistor on that pin ensures the MAX485 to be in the receiving
mode all the time. Two LEDs on the TXD and RXD lines of ATmega88 indicate the flow
of data in and out of the voting pad. This allows for easy debugging of the network.
Figure 2 shows the basic block diagram of the voting pads showing only the essential
components and connections. The microcontroller is programmed to listen for key presses
and store it in a variable in its RAM. The LED corresponding to the option selected is lit
up accordingly. When queried by the host computer, the microcontroller responds with the
option selected and the ACK (Acknowledge) LED is lit up to indicate the successful
registration of the vote.

THE COMMUNICATIONS TECHNIQUE

For communication over the RS-485 bus, we used the standard serial format with 8 data
bits, no parity bit and one stop bit. The bit rate was set to 115200 bps. We used a simple
packeting method to transfer data across the bus. Since we have multi-drop network, we
require a kind of addressing scheme. For this we assigned addresses to each voting pad
and stored these addresses in the EEPROMs of ATmega88 on each of the pads. The
packet format which we used is quite simple.

The first byte in the packet consists of a synchronizing character which marks the
beginning of a packet. This character was ‘a’ in our case. The second byte was the senders
address. The host computer was assigned the address 0. The voting pads were assigned
addresses from 1 onwards. The third byte was the address of the node on the bus for which
the packet was meant for. The fourth byte indicated the number of data bytes to follow in
the packet. The bytes following the fourth byte were the actual data bytes meant for the
destination. During development we used only 9 voting pads in the network and to make
our jobs easier we used the ASCII values of the addresses instead of their true
hexadecimal values. So for example if a voting pad’s address was ‘3’, we stored it as 0x33
rather than 0x03 in its EEPROM. This was done just to make our jobs easier while
debugging the system using a terminal software on the host computer. On a terminal
software 0x03 would be displayed as a special character which would make it very
difficult to understand what’s going on. On the other hand, 0x33 would actually show up
as ‘3’ on a terminal software.

To understand this packet format further consider the string “a072KQ”. Here ‘a’ is the
synchronizing character, ‘0’ is the address of the host computer and ‘7’ is the address of
the voting pad being queried. ‘2’ specifies the number of bytes to follow and the character
string “KQ” is the 2 byte data to be transferred to the destination voting pad. “KQ” is the
command for querying the voting pad for the option selected. When such a packet is sent
by the host computer, the corresponding voting pad would send another packet in reply
with the option selected on it by the audience member. So a typical response to the above
packet would be “a702KB” which means that the person who has the voting pad number 7
has selected option B. As you can see, we have used the ASCII values (instead of the hex
values) to ease the debugging process as stated earlier. “KR” is the command to reset the
voting pad.

Table 1 shows the packet format. Note that there is no form of error checking
implemented in our packet format. The bit errors were really very negligible even for
speeds of 115200 bps at lengths of up to 50 meters.

Byte Description
1 Synchronizing Character ‘a’
2 Source Address
3 Destination Address
4 Number of Data bytes to follow ‘k’
5 1st Data Byte
6 2nd Data Byte
. .
. .
. .
n kth Data byte
Table 1 Packet format

THE RS-232 to RS-485 BRIDGE

Since our computers do not have an RS-485 interface, we needed to convert the RS-485
signals to RS-232 signals which are used with the standard serial ports available on most
PCs.
To do this we connected a MAX232 and MAX485 back to back. The MAX232
converted the RS2-32 signals from the PC’s serial port to TTL levels which were then
given to MAX485 which converted them to RS-485 signals which could be sent over the
bus. All this sounds quite simple but in reality there is a catch – the MAX485 must be
switched between the transmitting and receiving mode depending on the direction on
which the data is flowing. One could use the RTS signal on the available on the PC’s
serial port to trigger the MAX485 between these modes, but it so happens that Microsoft
Windows is very poor in its timing while controlling the RTS signal. We encountered
problems while using such a setup, and hence looked for a better way to achieve our goal,
Atmega88.

Figure 3 shows the

block diagram of the
RS-232 to RS-485
bridge. Like in the
voting pads, we used a
pull-down resistor to
put the MAX485 in
the receiving mode by
default. In this case
any data on the bus
transmitted by any of Figure 3 Block Diagram of RS-232 to RS485 Bridge

the voting pads was

received by MAX485, converted to TTL and passed on to MAX232 directly to be sent to
host computer in RS-232 format. Whenever the computer transmitted any data, MAX232
converted it to TTL and passed it on to the ATmega88. On sensing that its UART has
received a byte, the ATmega88 retransmitted the same byte out to MAX485 while at the
same time triggering it into the transmitting mode. In this way we were able to easily
convert between the two signaling levels.
In our system we connected the RS-232
to RS-485 Bridge somewhere in between
the bus. We added terminating resistors of
120 ohms on the two extreme voting pads
connected to the bus. One of these voting
pad also carried 2 biasing resistors of 560
ohms to hold the A and B wires in their
default state whenever there was not data
flowing on the bus. One of the twisted pair
in the CAT5 cable formed our A and B Figure 4 RS-232 to RS-485 Bridge
signals.
If you are using a laptop - which are now a days devoid of a standard serial port - you
can use a USB to RS-232 dongle to connect the network to your computer. We have tested
our system with these converters and have found them to be just as good as the actual RS-
232 ports available on older PCs.

POWER

We made use of the one of the 3 extra twisted pair remaining in the CAT5 to distribute
DC power to the nodes. We used an SMPS working off the AC mains to deliver 12 volts
to the nodes. The power supply was rated at 2 amperes and was enough for 10 nodes.

THE FRONT END

 We wrote the front end in Java (JDK 1.5.0.60) using the Eclipse Editor (3.1.1). The
plug-in architecture of Eclipse makes it easier to integrate any library in to your
application. The Visual Editor plug-in allows you to develop Java application using a
simple Visual Basic like GUI. For implementing serial communication in Java we were
confronted with two choices of libraries : Java
COM API 3.0 (Published by SUN) and RXTX
2.1 (open source).

Since the support for Windows was under

development in the latest Java COM API, we
resorted to the GNU RXTX 2.1 Library for
serial communications.

To use RXTX library with Eclipse, the

RXTXcomm.jar file and dlls files are to be
copied to the lib directory of project and JAR
file is now to be used in the build path of the
project. Figure 5 shows the screenshot of our
Java application.

Figure 5 Screenshot of the Java application

IMPROVEMENTS

We took care to add the AVRISP six pin header to the voting pad boards so that we
could program them easily without removing the microcontroller from its base socket. A
bootloader capable of programming the microcontroller on which its resides by receiving
the new program codes over the RS485 network would have been nice. But adding a
bootloader during the initial development of the project would have made it much more
difficult to debug.
Now that we have the hardware fully operational and functioning, we can think of
adding such features so that newer programs with newer features would be easier to
download over the network itself. One of the examples of newer features that could be
implemented in the network is the logging of time which the user took to make his
decision. One of the timers onboard ATmega88 could be used for this purpose. When the
voter presses any one of the switches, the time take to do so will be logged and sent back
to the host computer when queried along with the option selected. An broadcast packet to
start the counter may be sent initially to start the counters in all the voting pads
simultaneously. Such an arrangement can be use to implement the pads for “Fastest Finger
First” Round of “Who wants to be a Millionaire?”.

In most places, voting pads in excess

of 200 would be required. The MAX485
transceivers we used can only support
upto 32 drivers per segments. This means
that only 31 voting pads (one of the
drivers will be the MAX485 on the

Figure 6 The System with 3 voting pads, RS-232 to RS-

485 Bridge and a power supply.
RS232-RS485 Bridge) can be connected to a given segment of the bus wire. This would
mean that multiple segments would be needed to implement a network for a decent sized
audience. These segments would have to be connected to each other using repeaters which
would complicate things and introduce delays. The repeaters would have to be designed
separately and since they would increase the devices used in the system, the MTBF of the
system would decrease. A better solution would be to use MAX487 instead of MAX485.
MAX487 can support upto 128 drivers per segment at speeds upto 250 kbps.

Connecting so many devices to the bus would imply that the bus wire would have to be
physically very long and therefore more prone to bit errors caused by noise. In such a case
a newer packet format with CRC would help in alleviating the problem.
Since this system for use by many humans, it should be able to withstand at least some
amount of faults caused by negligence on the part of its users. One of the most common
faults would be a break in the bus wire which would cause some part of the network to be
disconnected from the host computer and hence would prove disastrous. To prevent such
mishaps, more sturdy connectors like the subminiature D-9 connector can be used with the
twisted pair bus wires instead of the RJ45 or RJ11 connectors. Another enhancement to
this effect would be to use not one but two bridge circuits with the system. A host
computer with two serial ports would interface to the network via two bridges connected
at the two extreme ends of the network. This way if there is a break in a wire, the whole
network would be divided into two segment each of which would be connected to the host
computer via either one of the bridges.