Kyrre Glette
Øyvind Tanum
Ola G. Lein
Erling Alf Ellingsen
Rune Martin Andersen
Kristian Barek
Øyvind Grotmol
Kjetil Jørgensen
November 26, 2002
BJARNES2 Broadband Operating eXperience
Bidirectional3 Joint Access Routing Network Equipment Service
3
BBOX1 Integrated DIRECT Internet Open Network Access Layer
1
2
ii
Abstract
This document reports the autumn project of eight fourth-grade students at the Department of Computer
Science and Information Technology, NTNU, Trondheim.
The assignment was to make a multi-purpose box. Its main task was to make it possible to share a broadband
internet connection. In addition it should be able to act as a home automation system.
This project introduces a variety of different design techniques and tools, most of which were new to the
students. They experienced the various aspects of a hardware design, the most important of which were PCB
design, the use of a microcontroller and FPGA logic design. The project emphasized learning of various
techniques rather than an optimal design.
The report begins with an interpretation of the assignment, including a detailed requirements specification.
After this it moves on to the design phase, explaining high-level design choices before going into the details.
A test plan for the various parts of the design is presented. The results are then commented. A discussion of
practical issues, like parts acquisition, implementation tools and problems encountered is also included. In
the evaluation part technical and project workflow-related experiences are discussed.
Pre-imposed design was restricted to the required presence of an Atmel microcontroller and a Xilinx FPGA.
The rest of the design choices were made as a result of the group’s interpretation of the assignment and
the following requirements specification. The design presented in the report includes the use of the already
mentioned Atmel AVR microcontroller and Xilinx FPGA, as well as Crystal Ethernet controllers, a dualport
SRAM buffer and a real time clock.
The PCB layout is a four-layer design. It has two routing layers and planes for power and ground, where the
power plane is divided into a 3,6V sector and a 5V sector. Components are mostly surface-mounted, and all
components are mounted on the topside of the board.
FPGA logic is used for optimizing the interface to the Ethernet controllers, doing block memory copies that
would otherwise place too much of a burden on the microcontroller.
Microcontroller tasks includes handling of IPNAT packet routing and control of the web server and DHCP
server. It is also responsible for the home automation system, interfacing both an external X10 transceiver
and a mobile phone.
At the end of the project the product had not reached full functionality, in terms of the requirements specification. However, this was mostly a question of software implementation. After a pair of minor hacks the
hardware design worked, although at a non-optimal speed. Given more time the design could have been
perfected with extended networking and home automation protocol support. The logics could have been
optimized further and a decent, user-friendly web interface could have been added.
iii
iv
Foreword
We, the authors of this document, are eight students from at the Norwegian University of Science and Technology (NTNU), Trondheim.
This report summarizes the fourth grade autumn project (SIF8084) in the Computer Architecture and Design group at the Department for Computer and Information Science. The project makes up for half of the
workload for the autumn semester, and spanned from 26th of August to on 22nd of November.
The main purpose of this project is to get familiar with hardware development and to get experience of
working with big projects. The project takes on the whole cycle from customer requirements to the final
product, with focus on design and implementation stages.
We would like to thank our instructors Karstein Kristiansen and Morten Hartmann, and also Gunnar Tufte,
for support and follow-up. Gaute Myklebust from Atmel also deserves thankyous for supplying us with the
newest and hottest Atmel products for our project. Finally, thanks to Asbjørn Djupdal and Geir Svihus for
sharing valuable hardware experience, including Foundation makefile secrets and PCB tips.
Trondheim, November 14, 2002
Øyvind Tanum
Ola G. Lein
Erling Alf Ellingsen
Rune Martin Andersen
Kristian Barek
Øyvind Grotmol
Kjetil Jørgensen
Kyrre Glette
v
vi
Contents
1
Introduction
1
2
Assignment
5
2.1
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2
Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3
Requirements specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3.1
Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3.2
Non-functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3.3
Testability Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3.4
Requirements elaboration
9
3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System design
13
3.1
Design choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.1.1
Block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.1.2
Microcontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.1.3
FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.1.4
Ethernet controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.1.5
Dual-Port SRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.1.6
Mobile phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.1.7
Backup power source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.1.8
X10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.1.9
Real Time Clock (Timekeeper) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.1.10 Rejected options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
PCB design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.2.1
Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.2.2
Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.2.3
Connections
25
3.2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii
viii
CONTENTS
3.2.4
Design choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
FPGA - microcontroller interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.3.1
Division of labor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.3.2
Connection protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.4
FPGA Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.5
Microcontroller design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.5.1
Nut/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.5.2
Home Control System (HCS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.5.3
Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.5.4
Mail alert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.5.5
IPNAT Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.5.6
Timekeeper Real Time Clock (RTC) . . . . . . . . . . . . . . . . . . . . . . . . . .
38
SMS Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.6.1
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.6.2
Communicating with the cell phone . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.6.3
AT commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.6.4
The PDU message format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
3.7
Packet trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.8
Home Control System (HCS - X10) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.9
Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
3.9.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
3.9.2
Design sketches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
3.9.3
Dimensions and Drill Schematics . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
3.9.4
Plexiglas logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
3.3
3.6
4
Testing
51
4.1
PCB test
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.2
FPGA test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.2.1
Unit Testing during Development . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.2.2
Modular Behavioral Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.2.3
On-Board Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
4.3
Microcontroller test
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
4.4
System test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
4.4.1
64
Network performance tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CONTENTS
4.4.2
5
5.2
65
67
Software used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
5.1.1
Mentor Design Capture/Expedition PCB
. . . . . . . . . . . . . . . . . . . . . . .
69
5.1.2
Xilinx Foundation 3.1i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
5.1.3
Aldec Active-HDL v4.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
5.1.4
Atmel AVR Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
5.1.5
AVR-GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
Hardware used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
5.2.1
Atmel STK 500
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
5.2.2
Atmel AVR Embedded Internet Toolkit . . . . . . . . . . . . . . . . . . . . . . . .
71
5.2.3
XILINX FPGA test board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
5.2.4
Hewlett Packard Logic Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
5.2.5
DEC VT320 teletype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
Notes
73
6.1
Design flaws . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
6.2
Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
6.2.1
MCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
6.2.2
FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
6.2.3
PCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
Future expansions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
6.3.1
More RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
6.3.2
Expansion Port (’Geek port’) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
6.3.3
More HCS protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
6.3.4
PPPoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
6.3
7
Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tools
5.1
6
ix
Discussion
77
7.1
Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
7.2
Experiences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
7.2.1
General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
7.2.2
Tutorials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
7.2.3
Software development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
7.2.4
Teaching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
x
CONTENTS
7.2.5
Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
7.3
The product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
7.4
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
8
Acknowledgements
83
9
Bibliography
87
List of Figures
1.1
Overall model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3.1
Block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2
PowerPlane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.3
Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.4
Microcontroller Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.5
FPGA Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.6
Memory Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.7
Ethernet Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.8
Serial Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.9
Power Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.10 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.11 I/O Module illustration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.12 Microcontroller design overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.13 SMS thread model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
3.14 Front panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
3.15 Back panel
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
3.16 Dimensions. Backpanel (Top) - Frontpanel (Bottom) . . . . . . . . . . . . . . . . . . . . .
48
3.17 Plexiglas logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.1
Network performance test setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
5.1
Atmel STK 500 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
5.2
Atmel AVR Embedded Internet Toolkit
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
5.3
XILINX FPGA test board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
5.4
Hewlett Packard Logic Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
5.5
DEC VT320 teletype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
xi
xii
LIST OF FIGURES
7.1
The BBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
List of Tables
3.1
Hole diameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.2
Register list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.3
Ethernet Controller Module Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.4
Ethernet Controller Module Control Register Bit List . . . . . . . . . . . . . . . . . . . . .
32
3.5
Ethernet Controller Module Status Register Bit List . . . . . . . . . . . . . . . . . . . . . .
32
3.6
Siemens AT commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.7
Received PDU format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
3.8
Transmitted PDU format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.9
7 to 8 bit translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.10 Header format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.11 Address/function byte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.12 House and device codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
3.13 Function to binary mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.1
PCB test plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
4.2
Module test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
4.3
On-board testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
4.4
MCU test plan, part 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
4.5
MCU test plan, part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.6
MCU test plan, part 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.7
MCU test plan, part 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
4.8
MCU test plan, part 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
4.9
MCU test plan, part 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
4.10 Ping command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
4.11 NAT verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
4.12 Latency test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
xiii
xiv
LIST OF TABLES
Chapter 1
Introduction
1
2
Introduction
3
The task assignment of this project was to build a multi-purpose box for Bjarne, our virtual customer. We
have decided to call the box BBox.
The box was to make it possible to share a broadband Internet connection. This is usually not possible with
a normal Internet Service Provider, as you usually only get assigned one Internet address (IP). BBox should
allow you to connect several computers and let them all hide behind one IP address.
In addition, the box was to have several features not directly related to the networking part: It would function
as a home automation controller, giving Bjarne the ability to control his home appliances from elsewhere on
the Internet or via a mobile phone. It should also be possible to connect various sensors to the BBox, and
have the BBox page the owner via SMS.
The concept is described in figure 1.1 (page 3). This model shows the BBox as the middle link between
Bjarnes home, the Internet and a GSM telephone network. Multiple computers and home appliances can be
connected to the box, making the home automation as flexible as possible.
Figure 1.1: Overall model
4
Introduction
Chapter 2
Assignment
5
6
Assignment
2.1. Description
7
2.1 Description
This is the assignment description we were given at the start of the project:
Bjarnes Bredbånd
Bjarne har fått installert bredbånd. Han bor i kollektiv med flere andre studenter og vil kanskje dele bredbåndet med andre. I tillegg ønsker ikke Bjarne at andre skal kunne bryte seg inn i det interne nettverket han
eventuellt deler med sine naboer. Bjarne ønsker også muligheten til å styre diverse elektriske apparater og
installasjoner i sitt eget hjem over nettet,og overvåke hjemmet utenfra via nettet. En annen sak som Bjarne
kunne ønsket seg var at hvis det skjedde uventede ting som oversvømmelse, innbrudd og kanskje strømbrudd
så ville gjerne han og ett eventuellt vaktselskap ha beskjed om det så fort som mulig.
Etter en lengre og ganske omfattende markeds undersøkelse finner ikke Bjarne den ultimate boksen som
kan gi han alt dette. Utstyr for å styre diverse elektrisk utstyr i hjemmet og diverse sensorer for å overvåke
hjemmet finnes,men ikke den boksen som "syr" sammen alt dette. Bjarne spør en av de andre han bor
sammen med, en fjerde års student på datamaskingruppa på NTNU om hun kan tenke seg å lage den boksen
som kompletterer Bjarne sitt behov for "kjekt å ha bokser" i hjemmet.
En rask skissering fra Bjarne sin side over ønsket behov er som følger.
• En boks som kobles opp mot en ekstern bredbåndsleverandør
• Som gjør det mulig for flere å dele samme bredbånds forbindelsen
• Som også nekter uvedkommende å komme seg inn på det interne nettverket
• Med muligheter for å styre og kontrollere diverse elektriske apparater ved hjelp av andre eksisterende
bokser som allerede er på markedet som kobles til Bjarne sin drømmeboks.
Bjarne er også en person som liker "dingser" og er helt åpen for forslag for å gjøre hverdagen enklere og
bedre. Derfor legger han ingen begrensninger på eventuelle innspill og ideer du måtte ha for å kompletere
boksen hans ennå mere. Kom også gjerne med dine innspill om hvordan den bør kunne brukes, betjenes og
forenkle hverdagen. Sett derfor opp din(e) ide(er) til hvordan Bjarnes-Boks bør realiseres med de elektronikk
komponentene du har tilgjengelig.
2.2 Interpretation
The requirement specification given in the course was very vague. We were encouraged to make our own
interpretations and provide comments and suggestions. Our interpretation of the specification follows.
• Connect to an external broadband provider.
• Let several users share the same broadband connection.
• Control of electronic devices in a house through an external control device.
• Disallow unauthorized external access.
The BBox has two network interfaces. One of them will connect to a broadband modem or router. It is
assumed that this router will be able to communicate with IP over Ethernet. Certain broadband modems only
8
Assignment
support PPPoE 1 . The BBox will not support this protocol, although trivial, it would be a time-consuming
and non-interesting task to implement.
Using IP Network Address Translation to route IP packets from one Ethernet interface to another, the BBox
will allow several users on the LAN to simultaneously use the broadband connection. The BBox will implement a DHCP server to ease the configuration of the computers on the LAN.
The BBox will not allow any unauthorized access to the inside of the local network, for the simple reason
that the BBox will be unable to determine the recipient of the unauthorized package. Further firewalling
features, such as analyzing the packets for possible hazards or detecting IP spoofing attempts, will not be
implemented.
The X10 protocol is a protocol for Home Automation devices. There are several manufacturers of X10
compatible products. The product range includes light switches, dimmers and motion detectors. This makes
X10 a suitable protocol for the BBox.
The BBox will be able to detect break-ins and other unusual situations from various devices in the house.
The prototype of the BBox should have a backup battery, so that in case of a power loss it will be able to send
an SMS message to a specified number.
2.3 Requirements specification
From the assignment description and our own interpretation of the task, we have made a requirements specification. Lacking a real customer, these requirements are constructed by ourselves and are what we consider
as reasonable requirements for the product. We also decided on some testability requirements, although not
interesting for the customer, these are important for the design process, especially for the prototype designs.
2.3.1 Functional Requirements
Network Requirements
The Box should:
• be able to share an internet connection with several computers.
• disallow unauthorized external access and provide notification to owner if such attempts are made.
• provide a web interface to the Home Control System.
• provide email notification.
• provide a load meter to indicate the amount of network saturation.
• allow for limiting of network traffic to certain computers.
Home Control Requirements
The Box should:
1
PPP over Ethernet, used primarily for operators to be able to meter usage and bill per gigabyte.
2.3. Requirements specification
9
• be able to control and receive input from external home control devices via an external controller
interface.
• be able to alert and communicate with the owner based on input from external devices.
• be able to respond to input from external devices based on a set of user defined rules.
• be controllable from a personal computer, either from the local computer network or the internet.
2.3.2 Non-functional Requirements
The Box should:
• be designed for users which have basic experience with computers.
• have a compact and appealing design.
• run on a standard 230V AC net.
• be able to operate for a limited time without an external power supply.
• be able to operate in a normal home environment.
2.3.3 Testability Requirements
The box should:
• have test pods on all vital PCB traces.
• use as many socket mounted components as possible.
• have a serial interface for debugging.
• provide spare pins with VCC and GND on the PCB.
• have several status LEDs on the PCB.
• include boundary scan possibilities for both the microcontroller and the FPGA.
2.3.4 Requirements elaboration
This is a more detailed specification of the requirements presented in the previous lists. Requirements that
require further explanation are detailed.
Internet connection sharing.
• The box should be able to share an internet connection with several users. To accomplish this, each
computer needs to have its own IP address. The BBox should support a limited form of IP Network
Address Translation (IPNAT), so that an internet connection with a single IP address can be shared.
• The box should be able to act as a DHCP server to provide the local computers with dynamically
assigned IP addresses.
10
Assignment
• The box must be able to cope with a data rate of at least 2 Mbit/s.
• The box should have two standard 10-megabit RJ45 Ethernet connectors, one for the external internet
connection, and one for the Local Area Network (LAN).
Access control
• The box should not give unauthorized users access to the Local Area Network. The box should reject
internet packets that are not part of an existing outgoing connection unless its destination is specifically
assigned by the owner.
Web interface
• The box should provide a web interface to control and view the status of various home control devices
that are connected to the box. The box should provide a simple access control to the web interface.
Computers on the local network should have more privileges than external computers. Possible hazardous operations should not be available through the external web interface.
Email notification
• The box should provide an audiovisual notification when the owner has received email, within a short
amount of time.
Load meter
• The box should provide a visual presentation of the current traffic load average.
Traffic limit
• The user should be able to control the maximum amount of traffic allowed for each local computer.
Home Control I/O
• The box should be able to communicate with the X10 CM11A home control interface via a RS232
port. It should not have to communicate with X10 devices directly.
Owner Communication/Alert
• The box should be able to alert the owner in case of an extraordinary situation (burglary, flood, power
loss, etc.) via an SMS message.
• The box should be able to receive simple commands via SMS messages from the owner. The box
should only accept messages from certain phone numbers.
2.3. Requirements specification
11
Control
• The box’s behaviour should be programmable, ie. the user should be able to specify actions for different
inputs, program actions to be performed at a specific time etc.
• The box should be controllable from a PC connected to the network. It should also be possible to
connect to the RS232 and communicate directly with the box for maintenance purposes.
Testability Requirements
The points specified in the testability requirements are very important for helping us develop the system.
Since we are building a prototype, we do not find it very important to make an extremely compact or perfectly
routed design. Generous spacing between components makes it easier to cut traces and make modifications
to the PCB if necessary. Large component with sockets also makes the PCB larger and thus more expensive
than necessary. Testpods, extra power pins and a lot of the status LEDs are also features that will exist only
on the prototype. The final version of the BBOX will probably be a lot more compact than this prototype that
we are making.
12
Assignment
Chapter 3
System design
13
14
System design
3.1. Design choices
15
3.1 Design choices
3.1.1 Block diagram
This chapter describes how we planned the BBox would be implemented. It contains some information of the
most important components, and how they work together. The end of the chapter also contains the options
that were discarded. The overall system design is described in figure 3.1 (page 15).
Figure 3.1: Block diagram
3.1.2 Microcontroller
The use of the Atmel ATmega128 8-bit RISC microcontroller was a requirement in this course.
The microcontroller deals with the following tasks in our design:
• Web interface
Web interface is needed to make HCS functionality available through the web, and to make it possible
to configure routing options of the IPNAT.
• DHCP Server for LAN DHCP clients
To make it easier for computers to connect to the LAN, a DHCP server is used to handle internal IP
addresses. No IP configuration is thus needed for the connecting computers.
• Communication with the X10 interface
X10 commands are sent and received by the microcontroller through the X10 interface connected at
one of the serial ports.
• Communication with the cell phone
AT commands to and from the cell phone are sent and received by the microcontroller. The cell phone
is connected to one of the serial ports using a data cable.
16
System design
• IP Network Address Translation (IPNAT)
Because the ISP only provide one real IP address, translation is needed when multiple computers are
connected using the BBox. The NAT makes sure all IP packets are routed to the correct destination on
the LAN.
• Initialization of the Ethernet controllers
The microcontroller initializes the ethernet controllers by giving them IP addresses, and setting up
routing rules.
3.1.3 FPGA
The use of the Xilinx 4044XLA FPGA was a requirement in this course.
The FPGA communicates with the Crystal CS8900A Ethernet Controllers. When necsessary, it will allow
the microcontroller to communicate directly with a certain controller in order to initialize it.
The FPGA handles transfer of ethernet between the dual-port SRAM and the ethernet controllers. It is
believed that the microcontroller will be unable to handle the amount of network traffic and still be able to
perform the other tasks of the BBox satisfactory if the packets are to be transferred by the microcontroller
itself.
The FPGA will also scan the packets for certain strings in the case of certain protocols that carry information
relevant to IPNAT inside the packet. This will ensure that there will be no significant overhead in handling
these packets.
3.1.4 Ethernet controller
The Crystal/Cirrus CS8900A Ethernet Controller is a 10 MBit ethernet controller that can operate in several
different modes. In our design we use two controllers, both operating in 8-bit polling mode. These are
connected to the FPGA, which constantly poll them for new data. Since a dedicated piece of control logic is
implemented in the FPGA, this operating mode will be almost as efficient as an interrupt driven mode.
The CS8900A is a popular controller for use with the AVR microcontroller family, and is well documented.
3.1.5 Dual-Port SRAM
Part of the SRAM is used by the microcontroller for its day-to-day operation. For the networking subsystem,
both the FPGA and microcontroller will access the same area of memory. The FPGA will blit a packet
quickly from the NIC into SRAM, where the microcontroller will examine and decide what to do with it.
On the microcontroller side, a latch is used to make it possible to address 64K of memory using 8 address
lines. On the FPGA side, 16 address lines are used.
3.1.6 Mobile phone
A mobile telephone will be used for simple communication with the user. This is practical when the user does
not have access to a network connected computer. It will also be used for critical alerts like burglary. The
phone will be a Siemens C35 model. First option is for it to be built into the box and fitted with an external
antenna. But because the GSM signals might interfer with the electronics inside the box, it is possible that
we have to place the phone on the outside.
3.1. Design choices
17
The phone will be controlled by the microcontroller, using a serial connection. It will be connected directly
to the TTL connectors if possible. Otherwise it will be connected to the DSUB via a Siemens data cable.
Communication with the phone will be through the Hayes AT commands, extended for mobile phones.
These can be used for sending and receiving SMS messages. Incoming messages will have to be checked
for validity. The sender’s number will be checked against a list and there will be a password check. The
messages will then be parsed and the command will be sent to the control program.
The control program can also be configured with actions so that some events will trigger a message sending
command. Also, in case of a power loss the phone and the microcontroller will receive power from a backup
power source for enough time to send an SMS alert message to the phone. This message will be sent to the
user or an some kind of alarm central.
3.1.7 Backup power source
A battery is not included in the prototype. However we have considered several options for power supply in
the event of a power loss. One alternative would be to use the battery on the Siemens C35 cellular phone or
simply a rechargeable battery. This would, however, require additional work and components on the PCB,
for instance charging circuits. We were advised by the course teacher to just simulate a power loss through
an external signal.
3.1.8 X10
With X10 being the most wide-spread home control system in use today, we decided to use the X10 line of
products from Marmitek. The CM11A home control interface provides access to X10 control- and sensor
devices. There are several third party, free utilities that support the CM11A.
3.1.9 Real Time Clock (Timekeeper)
The Timekeeper (R) chip from STMicroelectronics is a battery powered RTC (Real Time Clock) and SRAM.
When the power supply to the Timekeeper falls below a certain value, the RTC and SRAM will transparently
be switched from external to battery power supply.
In our design, the Timekeeper will provide an accurate date and time to the BBox. Additionally, it can provide
the BBox with external non-volatile memory that can be used for storing configuration data.
3.1.10 Rejected options
• USB support
Plans were made to implement USB support on the box. This would make it possible to connect a
webcam or similar to extend the home automation to a complete alarm central. But because of the
complexity of the USB support, the plans were discarded. Instead we decided to focus on the SMS and
X10 integration.
• Graphic display
A 640x480 LCD was also made available for us, and we had plenty ideas for how we could make
use of it. One idea was to integrate it in the top of the box, making it a wall mounted module. The
house could then be displayed on the screen, showing status information for each room. Network load
monitor, mail notification, etc could also have been displayed. Unfortunately using a display meant
that we had to write a display driver and a controller. The backlight was also broken, meaning that
18
System design
we would have to improvise a new light. This would result in a great deal of extra work. Such a
display on the BBox would have seemed somewhat malplaced anyway, as the box is just intended as a
supplement to a computer. We decided instead to use LEDs for load meter and mail notification, and
a web interface for home automation. A web interface makes perfect sense as the computer, which is
guaranteed present in the household, already has a far superior user interface.
• Keypad
Likewise, a keypad could have enabled the user to control various features of the box without having to
use the web interface. However, a keypad would only come to its full right when used with a display.
Without a display, the keypad could at most be used to control simple features, e.g. X10 house control.
This feature would probably best be implemented through a separate X10 remote control. The user
interface argument from above applies here as well.
• Additional microcontrollers
An additional ATmega128 microcontroller was considered. We decided that one microcontroller would
be able to handle the amount of work if the microcontroller did not have to transfer the IP packets itself.
If we had included a graphic display in the design, we would probably have included an additional
microcontroller to handle the graphics.
• Integrated Hub
To enable multiple users to connect to the internet through the box, we thought about creating an
integrated hub. Instead we decided to create only one port in and one port out, so that the user could
connect an independent HUB to the box if more than one connection was needed.
3.2 PCB design
3.2.1 Board
General
The size of our PCB is 218mm * 210mm, and it consists of 4 layers. The top and bottom layers are used for
routing. While the bottom layer is just used for routing, all components are mounted on the top layer. The
components used are a wide collection of Surface Mounted Devices (SMD) and Through Components. There
are 230 components with a total of 1348 pins; 121 SMD and 109 through mounted devices. The second layer
is the ground layer and the third layer is the power layer.
Layers
The Gerber files for the layers are provided in the appendix.
• The Top Layer (Layer 1)
Most lines in this plane have a width of 12 mils to allow for manual changes in case of design errors.
However, some were given a width of 10 mils to allow full routing. The line spacing is 8 mils. The
Top Layer is used for horizontal routing.
• The Ground Layer (Layer 2)
The entire plane is used for the ground signal, as it is needed by most components.
3.2. PCB design
19
• The Power Layer (Layer 3)
The power layer is divided into two areas with different voltage. Most of the components used require
5V, except the Xilinx XC4044XLA Field Programmable Gate Array (FPGA) and its belonging SPROM
(XC1701L). The FPGA and SPROM run on 3.6V.
Figure 3.2: PowerPlane
We considered using only 5V or only 3.6V. However, we had components in stock with differing
voltages. The Xilinx components required 3.6V, while the Ethernet controllers and the TimeKeeper
required 5V. The microcontroller is limited to 8MHz with 3.6V, and the logic level is 5V.
With this in mind, we decided to use a split power plane. Therefore, we use the 5V version of the
microcontroller so that we may operate it at 16MHz.
• The Bottom Layer (Layer 4)
This layer is used solely for routing. The line widths are set to minimum 10 and typical 12 mils to
allow manual changes in case of design errors. The line spacing is minimum 8 mils. The bottom layer
is used for vertical routing.
Holes
All hole sizes were selected from Elprint’s aperture table [17]. We also strived to reduce the number of
different hole sizes, thereby reducing the price and delivery time of the PCB. The holes used are as listed in
table 3.1 (page 19).
Diameter (in)
0.012
0.035
0.047
0.063
0.130
Quantity
628
428
109
18
17
The vias
Table 3.1: Hole diameters
The placement of the holes is displayed in the appendix.
20
System design
3.2.2 Components
This section contains short descriptions of the different components used in the design. The listing is meant
for easy reference. Components are mostly sorted according to the schematics and where they logically
belong. Some common components that are used multiple places, are described under the heading "Various".
In figure 3.3 (page 20) you can see the PCB complete with all components.
Figure 3.3: Components
Microcontroller
• Microcontroller (ATMEL ATMega128)
The Atmel ATMega128 microcontoller is the central processing unit for the entire box.
• Mobile phone
A mobile phone will be connected to the box through a serial interface.
• X10
We will use an external device, CM11, to connect the box to other X10 devices. The communication
will proceed through a serial interface.
• TimeKeeper (M48T02)
The primary purpose of the TimeKeeper is to keep track of the time with its real time clock (RTC). In
addition to the RTC, it contains 2KB of nonvolatile memory. This may be used for storing settings etc.
• Latch (74ALS573B)
3.2. PCB design
21
Figure 3.4: Microcontroller Components
The latch is needed because the microcontroller uses the same port for the lower address bus and the
data bus when accessing the memory. The latch holds the address while data is being read from or
written to memory. This arrangement is used for both the TimeKeeper and the dual-port RAM.
We considered using the cheaper 74HC573 from the HC series, but that chip is not specified for the
high frequencies used in our high-performance design.
• MUX (74HC4053)
The mux is needed because some of the pins of the microcontroller have alternate functions.
• JTAG Connector
The JTAG interface is used to debug the microcontroller.
• SPI Connector
The Serial Programming Interface is used to program the microcontroller.
• Crystal
A 16 MHz crystal provides the clock reference for the microcontroller.
Field Programmable Gate Array (FPGA)
• Field Programmable Gate Array (Xilinx XC4044XLA)
The main functionality of the FPGA is to transfer packets between the RAM and the two Ethernetcontrollers according to instructions from the microcontroller.
• Serial Programmable Read Only Memory (SPROM) (XC1701L)
When the BBox is powered up, the FPGA needs configuration. On everyday use the data needed is
provided by the SPROM. On power-up the FPGA reads information from the SPROM and configures
itself.
22
System design
Figure 3.5: FPGA Components
• Econ Oscillator/Divider (DS1075M)
The Econ Oscillator provides the clock signal for the FPGA. It is adjustable in 513 steps up to 100MHz.
Thus, the speed of the FPGA may be tuned to gain optimal performance.
• JTAG MultiLINX Connector
The JTAG interface allows debugging of the FPGA.
• XChecker Connector
The XChecker connector is connected to the FPGA and provides the possibility to connect a PC, via
the serial port, to the FPGA. This cable connection allows direct programming and debugging of the
FPGA. In other words the XChecker is used in the programming and testing phase, while the SPROM
is used when the product is finished.
Memory
Figure 3.6: Memory Components
• Cypress Dual Port SRAM (CY7C009)
The main memory in the system is dual ported to allow both the microcontroller and the FPGA access.
The FPGA will buffer incoming packages in RAM and inform the microcontroller. The controller
inspects it and instructs the FPGA with what to do.
3.2. PCB design
23
Ethernet
Figure 3.7: Ethernet Components
• Ethernet Controller (Cirrus CS8900A)
The Ethernet controllers are the interface between the FPGA and the local and external networks.
• Ethernet Isolation Transformer (TG42)
The isolation transformer provides a galvanic isolation to the ethernet controller.
• Ethernet Connectors (RJ45)
These are the external LAN/WAN connectors.
• 20 MHz Crystal
The 20 MHz clock crystal sets the ethernet controller speed.
Serial interface
Figure 3.8: Serial Components
24
System design
• Serial Level Shifter (Maxim MAX202CPE)
This device provides the interface between the TTL levels from the microcontroller and the RS232
serial cables.
• SerialChooser
To allow direct access to the TTL serial ports at the microcontroller, a connection strip has been included. When the DSUB is used, pins 3 and 4 should be shorted. Direct access is provided through
pins 2 and 3, while pin 1 is not connected. Thus, it is ensured that both options are not enabled at the
same time.
• Serial Connectors (DSUB9)
The X-10 controller is connected externally via one of the serial connectors. Furthermore, these ports
may be used in the development process. Should the direct TTL connection to the mobile phone fail,
we will use one of these serial connectors instead. The sex of the connectors is male.
• Capacitors
Capacitors have been added to the Maxim chip in accordance with an application note. We were hinted
that it would be advantageous to increase the value of the decoupling capacitor for the chip to 1uF.
Power
Figure 3.9: Power Components
• 9V Connector
The 9V power connector is connected to a 9V external Direct Current (DC) power supply.
• Diode Bridge Rectifier (1KAB20E)
Since there is no standard polarity considering 9V power supplies, a rectifier is included to ensure
desired polarity.
• Adjustable Voltage Regulator (CS-5203A)
To provide correct voltage to the power planes, two voltage regulators are used to transform the 9V
input to the desired 5V and 3.6V.
• Decoupling capacitance
We used the general rule of thumb that each power supply pin requires one 100nF decoupling capacitor.
3.2. PCB design
25
Various
• Philips LED Shift Register (HEF4894BP)
This device is convenient as it allows any number of LEDs to be controlled using only two or three
output pins. Each device controls 12 LEDs, and it is possible to connect several in series. The FPGA
is connected to one for debugging. The microcontroller is connected to one for debugging and one for
status information at the front panel.
The LEDs that will be mounted at the front panel, are connected to the board with jumpers. The others
are soldered direct on the board.
• Resistors
Generally, resistors from the E12 series have been preferred. These are the most common values and
thus the most available. Only where specific values are required has this principle been broken, as is
the case for the 4.99KOhms reference resistor required for the Ethernet controllers. The 24.3 Ohms
values specified in the design files were found in an application note, but they are not very critical.
Therefore, 24.5 Ohms resistors were created by sandwiching 27 and 270 Ohms resistors from the E12
series.
We have used 10K Ohm pull-up resistors throughout the design. This is the most common value, and
the power consumption is not critical enough to imply that we should risk using a higher value.
For the LEDs, we used 390 Ohm resistors. With 5V supply voltage and 2V drop across the diodes, this
should give 7.7mA current, which is within the normal operation range. Six of the diodes enlighten the
BBox logo in the front panel. These use 47 Ohm resistors instead, which results in 20mA current. The
increased power consumption gives a stronger glow in the logo and will likely make the product more
attractive to fashionable customers.
3.2.3 Connections
This section contains information regarding the connections between the components, in accordance with
the schematics. The schematics can be found in appendix B.1. Each page in the schematics has its own
subsection.
BBox
The top level, BBox, contains no components itself, only other blocks. The components have been divided
into the blocks according to their logic connections.
Power
The power connector is connected to a diode bridge. This is because there is no standard as to the polarities of
the plug, so that we have to ensure correct polarity in both cases. The power is connected to large decoupling
capacitors before entering the voltage regulators. There is one regulator for each power plane, 5V and 3.6V
that is. The resistor values are selected according to formulae given in the data sheet [11] to yield the desired
voltages. A diode is provided for each regulator to provide additional overload protection. There are also
large decoupling capacitors at the internal side of the regulators to stabilize the voltages under varying current
loads.
Connection pins to ground and the two power planes provide easy access and thereby facilitate measuring.
Furthermore, one LED for each level provides fast visual notification in the case of total voltage loss.
26
System design
Several jumpers with ground and power connection are spread across the board in case of design errors. If
some unconnected pin needs to be tied to a certain voltage level, this will prove to be useful. There are six
jumpers with 5V and two with 3.6V.
Microcontroller
The microcontroller is one of the most complex chips in the design and has extensive connections since it
controls the operation of the entire board.
A 16Mhz crystal with two capacitors provides the necessary clock signal for the controller.
The 8-bit direct bus is provided for fast communication between the controller and the FPGA. With a high
traffic load on the Ethernet, a high throughput may be required between these components. A two-bit handshake bus is also provided for synchronization signals. The direct bus uses port B, and the handshake bus
uses the two lowest bits of port D.
The ISP connector is provided for programming the controller. A multiplexer is connected in between because the pins used for ISP are also used for the serial port A and one of the IO pins in port B, which we use
for the direct bus. The multiplexer is controlled by the reset signal.
The JTAG Connector allows boundary scan for debugging purposes.
24 LEDs are connected using only three pins on the controller. This is made possible by connecting to shift
registers with parallel output in series. Half the LEDs are used for status information in the front panel and
enlightening the BBox logo, while the rest are used for debugging purposes.
A button is provided for resetting the controller.
4 switches allow control signals to be given to the controller. This is useful for debugging and possibly also
for user settings of a more permanent nature.
Serial port A and B are both used for communication with the X10 interface box and the cell phone during
normal operation, and with PCs during debugging.
The microcontroller uses port A for both the lower part of the memory address and the memory data bus.
The recommended solution for this is using a latch, which is also what we have employed. During a memory
IO operation the lower address part is first loaded into the latch, and then port A can be used as a data bus.
Two memory chips are used in the system. The Timekeeper only contains 2KB of memory and it primarily
used for its built in Real Time Clock and long-lasting battery. The other chip is the dual port SRAM. The
RAMSelect signal is used to alternate between these memories.
Serial Interface
A RS-232 Level Shifter, the Maxim 202CPE, is used to transform the TTL signals from the microcontroller
into the higher voltage level used externally.
Two male DSUB connectors on the board provide the physical connection and are mounted on the back of
the BBox for easy access.
The purpose of the SerialChooser is to circumvent the Level Shifters for cell phones that use TTL themselves.
In such cases, the phone may be connected directly on the middle pins (2 and 3) of the SerialChooser.
Otherwise, pins 3 and 4 must be shorted. This is because the Level Shifter is disconnected during the direct
TTL connection to prevent it from driving the output signal.
3.2. PCB design
27
FPGA
The FPGA is the link between the microcontroller and the two Ethernet controllers.
An SPROM is used to store the configuration data for the FPGA. This is necessary since the data is lost
during power down.
An XChecker connector is used to program the FPGA and the SPROM. A JTAG connector provides boundary
scan for debugging.
The upper side, IO99 through IO129, is used for address, data and control signals for the LAN controller,
Ethernet1. Similarly, the right side, IO65 through IO95, is used for the WAN controller, Ethernet2.
The right side, IO3 through IO32, is primarily used for the dual port RAM. These signals are the 17 address
bits, 8 data bits and the read/write select.
The bottom side is used for various signals that are described below.
The Direct and Handshake bus to the microcontroller occupy IO33 through IO42.
12 LEDs are connected to IO49 and IO50 for debugging purposes.
4 switches are connected to IO53 through IO56 for control signals during debugging. One of these switches
is also used to control M0, M1 and M3, which determine whether configuration data is to be read externally
from the XChecker or from the SPROM during initialisation.
A button is provided for resetting the FPGA and the SPROM.
Clock Generator
The Econ Oscillator generates the clock signal for the FPGA. This chip was selected because the speed can
be set up to 100MHz. The programming will be performed outside of the board, so it is placed in a socket.
Therefore, the only connection with other blocks is the clock signal going to the FPGA.
Ethernet
An Ethernet connection was used also in the last year’s project. Therefore, resource efficiency required us
to reuse their design. However, this meant that we had to be very critical since the design was created by
freshmen. Indeed, several weaknesses and flaws were detected and had to be corrected. We also introduced
testpods to facilitate testing.
A 20MHz crystal with capacitors provides the clock signal for the Ethernet controller.
We do not use the DMA functions of the Ethernet controller since the FPGA is responsible for transferring
the data. Therefore, the DMA signals are tied or left unconnected.
The address, data and control signals are all connected direct to the FPGA.
The RJ45 connector is the external physical connection. The TG42 Ethernet Isolation Transformer changes
the voltage level before the signals enter the controller.
The LINKLED and LANLED provide the user with status information, and the BSTATUS LED is used for
debugging purposes.
28
System design
LEDs
LEDs are used extensively in the design for debugging purposes. They provide fast visual information and
as such are valuable in the software development process. When the board is modified for mass production,
these LEDs are likely to be abandoned to reduce production costs, board size and power consumption.
The CLK signal of the shift-register is used to clock the data in through the DATA signal. The strobe signal is
used to prevent flashing the LEDs while data is shifted in. The shift register connected to the FPGA has tied
this pin, because the data will not be changed often enough that the flashing can be detected. The situation is
different for the other registers because the microcontroller will fade some of the LEDs in the front panel by
rapidly changing the values.
LED Connectors
This block is identical to the "LEDs"-block, except that jumpers are used instead of LEDs. This is because
the LEDs will be mounted in the front panel of the box and wired to the jumpers. These LEDs will be retained
in the production version.
4 Switches
By using a quadruple switch, the number of components on the board is reduced. This block also contains
pull-up resistors to ensure that the voltage level is always well defined.
Testpod
Our test strategy relies on heavy use of the HP digital logic analyser. All important TTL signals are connected
to one of the seven testpods on the board. Thereby, it is possible to monitor and analyse all intercomponent
activity. The mass production version will not contain testpods.
The testpod consists of 20 pins, of which two are unconnected. Furthermore, one pin is connected to ground
and one to the relevant clock signal if any. We have divided logically the remaining 16 pins into two 8 bit
buses for easy connections, since many of the signals to be measured have this size.
3.2.4 Design choices
In this section some of the PCB design choices are described.
Placement
• Rotation
The components are for the most part rotated the same way, thereby reducing the probability of error
during mounting. Also, it is easier to comprehend how the board is designed and make changes at a
later stage. This principle has only been broken when the routing was made simpler by doing so.
• Fiducials
Fiducial marks have been placed in two opposite corners. The purpose of this is to allow the placement
of the board to be optically determined if the card were to be mounted by a machine. However, during
the manual mounting of the prototype boards these were not used.
3.3. FPGA - microcontroller interaction
29
• Spacing
The footprints were adequately spaced to account for components that are physically larger than their
footprints.
• Decoupling capacitors
The general principle of one 100nF capacitor for each power pin has been employed. The capacitors
were placed as close to their respective pins as possible to achieve the best effect. This strategy has
also been controlled against application notes from the manufacturers of the respective components.
Components
• Optocouplers
At one stage of the project, we included optocouplers in our design to separate the serial ports galvanically from the rest of the board. However, it turned out that this would require extensive changes to the
design because the power supply to the Maxim chip would also have to be galvanically separated if the
protection was to have any effect. Since this extra protection was not considered absolutely necessary,
it was abandoned.
We also considered separating the ethernet connection. Since this signal is analog, we could not use
optocouplers. The trafo was also believed to provide the necessary protection.
• Switches
To save pins, we considered using a different approach for the switches. With the current design,
one pin is connected to each switch. One alternative would be to use a mux, which would require
ceil(log2(n))+1 pins for n switches. Another would be to use a shift register with parallel load, which
would require 3 pins for any number of switches. However, we had enough pins on the devices, and we
did not need many switches. Therefore, we saw no point in adding the extra complexity in hardware
and software introduced by these alternative methods.
• Battery
In the finished product we would have included a battery as a backup power source. In the case of
power failure, the box should be able to send a SMS before ceasing operation. Since this is only a
prototype, the battery was not included in the design.
• FPGA IO-pins
We tried to assign the IO pins of the FPGA in a way that would make the PCB routing the easiest. This
primarily implied choosing pins that were physically close to the destination, and sorting the pins so
that the traces did not have to cross each other.
3.3 FPGA - microcontroller interaction
3.3.1 Division of labor
The easiest way to implement a system such as this would have been to connect the network controllers
directly to the processor bus. However, this would cause the microcontroller to be a potential bottleneck the
entire system.
Reading a byte from one of the controllers would take about 4 cycles, as would storing it into memory. The
controllers do not support random access, so the packet would have to copied into memory first, and then
30
System design
copied out to the other network controller. We were concerned that this would be too slow, considering the
relatively low speed of the AVR.
An intermediate solution would be to build an ISA bus of sorts, and use an ordinary DMA controller to
perform the copying. By giving each module a separate connection, we hoped to be able to use the modules
in parallel as much as possible.
3.3.2 Connection protocol
The FPGA could have been connected directly to the memory/data bus, but this would have required addressing decoding logic (for the RAM chip), as well as further limiting the available RAM space.
An 8-bit bidirectional bus is used between the µC and FPGA, with an additional bit for framing.
3.4 FPGA Design
FPGA modular design overview
The figure 3.10 (page 30) gives an overview of the different modules in the FPGA design, its interconnections
and connections with the rest of the design.
Figure 3.10: Block Diagram
The microcontroller controls the FPGA through the I/O module. For communication between the internal
modules, a sort of register bank, accessible for all modules, was considered. This was soon abandoned due to
the growing complexity as the number of necessary registers for the Ethernet modules increased. We opted
for a more scalable solution, an internal system bus. The bus solution also required an address decoder unit,
selecting the appropriate unit for bus access. The bus is symbolized by the gray arrows in the figure.
I/O Module
The IOM receives commands from the microcontroller through the 8-bit control channel. An additional pin,
called ATTENTION, is used for synchronization.
3.4. FPGA Design
31
On the rising edge of ATTENTION, the value on the control channel is latched in an address register. (Illustrated in figure 3.11, page 31). The top bit selects Read or Write mode (0=read, 1=write). For a write
command, the data is sampled on the falling edge of ATTENTION, and a single write cycle is performed
on the internal data bus. For a read command, the internal READ signal is asserted and held for as long as
ATTENTION is high. The control channel is then driven to the value on the internal data bus.
Figure 3.11: I/O Module illustration
Address Decoder
The Address decoder is connected to the internal modules that are addressable as shown in the register list. It
analyzes the address on the internal address bus and enables the corresponding module so that it will be able
to read/write data on the internal data bus. The registers that are available on the BBUS are listed in table 3.2
(page 31).
Register Name
E1xxx
E2xxx
DLEDx
DTEST
Range
00-0f
10-1f
20-21
22
Description
WAN Ethernet Controller
LAN Ethernet Controller
Debug LEDs
Test Register
Table 3.2: Register list
RAM Arbiter
Several modules need to access the RAM. The RAM Arbiter is a simple module used to avoid collisions: Each
module may set a REQ line, signaling that it intends to use the RAM bus. The arbiter will give the winning
module a GRANT signal beginning the next clock cycle, which will remain in effect until the requesting
module releases the REQ signal.
Ethernet Control Modules
There are two identical ethernet control modules, one for each ethernet port.
Each ECM consists of these parts:
• Input/Output buffers and pads. These are used by the packet blitter, and are overridable by setting bits
in the ExCR. This is done during initialization to communicate directly with the CS8900.
• A main state machine. This will consist of two main paths, one for sending and one for receiving
packets. Each path consists of a number of states setting various control registers of the NIC, and will
then activate the blitter unit at the appropriate time.
32
System design
Register Name
ExDCAL
No.
0
Dir.
R/W
ExDCAH
ExDCD
1
2
R/W
R/W
ExCR
ExSR
ExRPAR
3
5
6
W
R
W
ExSPAR
7
W
ExSPLR
8-9
W
ExRPLR
A-B
R
Description
Ethernet Direct Control Address - used by the microcontroller to communicate
directly with the Ethernet controllers during initialization
High byte
Ethernet Direct Control Data - used by the microcontroller to communicate
directly with the Ethernet controllers initalization
ECMx Control Register
ETH Status Register
ECMx Receive Packet Address Register - specifies in which memory buffer
should store the next incoming packet (high 8 bits of the memory address).
When this register is written, the ESPR bit in ExSR is cleared.
ECMx Send Packet Address Register - specifies in which memory buffer a
packet to be sent is found.
ECMx Send Packet Length Register/Counter - this register contains the length
of the packet to be sent
ECMx Receive Packet Length Register - this register contains the length of the
packet just received.
Table 3.3: Ethernet Controller Module Registers
Bit Name
ECRA
No.
0
ECSP
1
EDCWE
2
EDCRE
3
ECIOS
4
E_AEN
E_VCC
E_RESET
5
6
7
Description
Receive Active - when enabled, the ECM will poll the NIC status register for incoming
packets. If one is received, it will be copied into the buffer specified in ExPAR.
Send Packet - after this bit is enabled, the ECM will begin transferring the packet pointed
to by ExSPAR as soon as possible.
Direct Control Write Enable - while this bit is set, the Data and Address outputs of the ECM
are driven to the values in the EDCA/EDCD registers
Direct Control Read Enable - while this bit is set, the Address output of the ECM is driven
to the value in the EDCA register. The Data bus is tri-stated, and is readable as the EDCD
register after a short delay.
IO Select - this bit selects whether the direct access initiated by the EDCWE/EDCRE bits
will be to IO space or memory space.
Set to zero for normal operation (if set to one, signals that the bus is in use)
Must be set to one for normal operation.
RESET - active-high reset pin
Table 3.4: Ethernet Controller Module Control Register Bit List
Bit Name
ESPR
No.
0
ESPS
1
Description
Packet Received - This bit is set when a packet has been received and placed in the shared
RAM. It is automatically cleared when the ExRPAR register is changed.
Packet Sent - This bit is set when a packet has been successfully transferred to the network
controller (not necessarily to the LAN).
Table 3.5: Ethernet Controller Module Status Register Bit List
3.5. Microcontroller design
33
• The blitter: This is a conceptually simple unit which will perform a block transfer from the CS8900’s
RAM to shared RAM, or vice versa.
Debug LED Register
This module is a simple 12-bit parallell-to-serial converter. It is connected to a HEF4894BP - an external
combined shift register and LED driver IC. The register is divided into two 6-bit rows, according to the layout
on the card, thus the 6 LSBs of each separate address are used.
IRQ Module
This very simple module allows other modules to set flags indicating that they need attention. If any module
requests attention, the external IRQ line to the AVR is asserted. In effect, this is an elaborate OR gate.
3.5 Microcontroller design
The following tasks are handled by the software running on the microcontroller:
Home Control System
The BBox is able to send and receive SMS messages and X10 commands from/to devices in the house, and
mail notification from an internet provider. Depending on rules specified by the user, the BBox will take
action when a certain message is received, or a timer event occurs. The Home Control System deals will all
of this.
Separate software modules take care of the actual communication with the cell phone and X10 transceiver to
enable the HCS to send and receive SMS messages and X10 commands.
Web Interface
The web interface allows the user to configure the various options of the box and sending of X10 commands.
IPNAT routing
While the FPGA handles the ethernet controller communication, the microcontroller implements the actual
routing of the IP packets. The microcontroller will control the FPGA, which in turn interrupts the microcontroller when an ethernet packet has been received or transmitted.
Having to deal with different tasks means that the microcontroller software will have to support some kind of
multitasking. Also, in order to provide a web interface and DHCP server, it will have to provide an IP stack
with the relevant protocols supported. To synchronize the various tasks being performed, the software should
also contain some kind of event dispatching mechanism. Fortunately, simple operating systems implement
these often used features.
Several such operating systems were reviewed in the design phase of the project. We ended up choosing
Nut/OS [15] from the Ethernut Project.
The following figure shows the different software modules, as implemented in the microcontroller:
Microcontroller
Dual port SRAM
Nut/OS
34
X10
Transceiver
Mobile
Phone
UART
UART
X10
Interface
SMS
Interface
Nut/OS Heap
Figure 3.12: Microcontroller design overview
HCS
Interface/Control
FPGA
IP NAT router
System time
Nut/OS IP stack
WAN
Controller
www
interface
TimeKeeper
dhcp
LAN
Controller
System design
3.5. Microcontroller design
35
3.5.1 Nut/OS
Introduction
Nut/OS is an open source software and hardware project for implementing embedded ethernet applications.
The project site offers extensive documentation and example applications.
Among the useful features of Nut/OS are:
• simple non-preemptive multithreading
• events and timers
• dynamic heap memory management
• Nut/Net, a TCP/IP-stack with all base protocols implemented. (And in addition a DHCP client, DNS
resolver and an HTTP server.)
• formatted printing through buffered devices
Nut/OS supports the ATmega103 and ATmega128 microcontrollers. The above features make it ideal for
use in our project. Other IP stacks and operating systems were considered, but none as flexible and well
documented as Nut/OS.
Some Nut/OS concepts:
Threads
Threads are implemented by using the Nut/OS THREAD macro. A thread is never expected to return.
Unless an interrupt is received, a running thread will not be blocked unless it calls specific blocking Nut/OS
functions. The thread can call NutThreadYield() if it explicitly wants to yield control to another thread, or
NutThreadSleep() if wants to suspend its execution for some specified time.
NutThreadCreate() is used to start at new thread. One must specify a stack size and priority for the thread.
NutThreadSetPriority() can be called later on to set the thread priority of a thread.
Events
A Nut/OS event queue is represented by a HANDLE struct. A thread wanting to signal an event can call
NutEventPost() or NutEventPostAsync() with the handle as the parameter. The latter function will allow the
signaling thread to continue execution.
When a thread wants to wait for a specific event, it can call the function NutEventWait() with the event
handle, and optionally a timeout value. The thread will be blocked until the event is signaled or the timeout
expires.
Devices
The Nut/OS uses a NETDEVICE struct to represent a device. All external devices, and some virtual devices
like sockets, are accessed through their NUTDEVICE structs. To use a device, the code will have to use the
NutRegisterDevice() function to register the device as being used. If needed, a device type specific function
is called to initialize the device. In this project we have made use of the following devices:
36
System design
UART devices: devUart0 and devUart1
These devices represent the UART devices on the ATmega128. On the ATmega103 there is only one UART
available as devUart0. The UART devices provide an abstraction to the UART devices, handling I/O buffering.
Network devices
We have made two ethernet devices available to Nut/OS, devEth1 and devEth2. Nut/OS already have a
devEth0 device for their Realtek ethernet driver.
SOSTREAM devices
These devices are virtual devices representing an I/O stream. They are mostly used when sending network
data, but can also be used when accessing other communication devices.
Formatted Printing Functions
Nut/OS provides several functions for writing formatted output to devices, including NutPrintFormat(), a
variant of the common printf, NutPrintString, and NutPrintBinary.
Nut/Net
Nut/Net is built on top of Nut/OS and contains the network specific part of the Ethernut Project. Nut/Net
implements a full IP stack. It has an IP routing table and an ARP table, and supports all basic IP protocols
as described above. To set up networking, one have to call the NutNetIfConfig() function and supply the
appropriate ethernet device as a parameter. Nut/Net handles all communication with the ethernet driver.
In addition to the basic protocols, it supports a DHCP client. To use this, one simply has to call the NutNetAutoConfig() instead of NutNetIfConfig().
Last, but not least, Nut/Net implements a simple HTTP web server. HTML documents can be stored in
a small file system, which is created with a utility that converts regular files to C source files that can be
included in the code. The HTTP server also supports "cgi scripts". By using the NutRegisterCgi() function,
one can associate a specific function with a filename in the web server. When the URL is accessed, the
function is called with en SOSTREAM argument representing the established connection.
NETBUFs
The Nut/Net NETBUF struct is used for handling all network data on its way through the IP stack. There are
pointers to separate buffers (in NBDATA structs) for use in the data, network, transport and application link
layer. These are allocated on demand by the Nut/Net code.
3.5.2 Home Control System (HCS)
The microcontroller communicates with the X10 interface and the cell phone.
3.5. Microcontroller design
37
The HCS module is responsible for carrying out the tasks as described by commands received via the Web
Interface, X10 Control Devices, by SMS from the GSM phone and from a mail alert system.
It maintains a list of X10 devices containing device type, device and house code, a nick name and the current
state. It also maintains a list of rules to be applied when an SMS message or X10 message is received, or
when a mail alert packet is received. The rules specify the action to be performed when a certain event occurs.
X10 events are identified by a device/house code and a function. SMS events are uniquely identified by a
phone number and a text string. In addition, the HCS module maintains a list of allowed phone numbers. If
an SMS event has no associated phone number, the list of allowed phone numbers is used to determine if the
event should be allowed to be executed.
A timer thread is woken up by Nut/OS once a minute, and will check whether a certain event is scheduled to
run. Timed events can be scheduled once or repeated each hour, weekday or week.
X10 commands are queued in a separate queue before they are sent to the X10 controller. Separate threads
handle incoming and outgoing X10 messages independent of the rest of the HCS module. This way, the HCS
system will be free to attend to other matters as the X10 commands are being sent.
SMS messages are handled in a similar fashion, except only one thread handles both incoming and outgoing
messages. Whereas an X10 message can arrive at any time, the cell phone is manually polled for new
messages.
3.5.3 Web Interface
The following has not yet been implemented due to lack of time.
The web interface is implemented using the Nut/OS HTTP interface.
Depending on whether the web interface is accessed from the local network or the internet, the BBox should
grant access to different kinds of operations. From the internet, the user should only be able to control devices
in the house, and only after having been authenticated. From the LAN, the user should be able to do the same
without authentication. However, to configure the BBox, authentication should be required.
In the prototype version, only normal HTTP authentication is performed, as this is natively supported by
Nut/OS. Ideally an SSL enabled web server should have been implemented, but this is beyond the scope of
this project.
The web interface provides the user with the following configuration options:
• Set time and date.
• Set up static NAT routes.
• Set WAN IP address, or enable DHCP client.
• Set LAN IP address.
• Enable/disable DHCP server.
• Set the cell phone number.
In addition, the following options can be configured for the HCS module:
• List of X10 devices present in the house, including type of device and a nick name.
• Phone numbers that are allowed to send SMS messages to the BBox.
38
System design
• Events. The events can be triggered by a specific X10 command, a specific SMS message or a timer,
which can be set to go once (on a specific date/time) or repeatedly. The actions of an event can be to
send a specified X10 command or an SMS message. Events can be added and removed, but not edited.
On a separate web page, the user is able to view the status of, and control the various X10 devices. In
addition, any events specified in the configuration can be called.
Using the built-in Nut/Net authentication mechanism, the configuration web page and the Home Control web
page are placed in separate directories, each having different levels of security. All dynamic web pages are
implemented as functions and registered with the Nut/Net HTTP server.
3.5.4 Mail alert
One of the requirements of the BBox is the ability to alert the user when new mail has arrived in his/her
mailbox. This is implemented by having the user run a procmail 1 script that simply access a specified web
page on the BBox. The mail alert LED will then be turned on. The user can turn the LED off by pressing the
mail acknowledge button. The LED will then be turned off.
This feature is not implemented.
3.5.5 IPNAT Routing
The IP Network Address Translation Routing Module has the responsibility of communicating with the
network controllers through the FPGA. It manages a routing table that is updated whenever a connection is
created, destroyed, times out, or when the user adds or removes a route through the Web Interface.
When a packet is received through one of the network interfaces or the Nut/Net system requests a packet to
be sent, the IPNAT Routing Module will notify a high priority thread, which will handle the packet.
If a received packet has a local destination, the thread will allocate a Nut/Net NETBUF struct and call the
appropriate Nut/Net function. Else, it rewrites it and arrange for it to be resent, and updates the NAT table as
described in the Packet Trace section. If the packet is a SYN or FIN message, the NAT table entry either be
created, deleted or its state updated, depending on the previous state of the NAT table.
If the ethernet destination address is not available, the packet will be queued until an ARP request has returned
an ethernet address, or the packet has timed out.
A separate thread periodically traverses the NAT routing table and removes any timed out entries. This thread
is also responsible for doing ARP requests from Nut/Net
3.5.6 Timekeeper Real Time Clock (RTC)
The Timekeeper stores the date and time in BCD (Binary Coded Decimal) format. It is accessed through the
same memory bus as the dual port SRAM. The SRAM is therefore deactivated when accessing the Timekeeper. Prior to reading and writing the RTC, a control register can be written to. The RTC will then stop
updating the memory to allow it to be read safely, or read back the values stored when the write bit is reset.
When the Timekeeper module is shipped from factory, the oscillator is stopped in order to preserve battery
life. To enable the oscillator, a stop bit in the control register must be reset.
The Timekeeper only contains a two-digit year. To be Y2.1K compliant, the BBox would have to store
additional digits in EEPROM. Due to additional time constraints, we choose not to implement the Y2.1K
1
A free software program that can process delivered mail, compatible with many mail servers.
3.6. SMS Communication
39
feature. The consumer will in any case be forced to upgrade the Timekeeper due to its life expectancy of 10
years. This will yield an opportunity to solve the Y3K problem before it materializes.
This feature is not implemented.
3.6 SMS Communication
3.6.1 Description
The BBox should be able to alert the user via SMS when a critical event occurs. Examples of critical events
are:
• Power loss
• Break-in, fire (and other alerts) detected by the Home Control System (HCS)
It should also be able to receive SMS commands for some of the HCS functions. These commands will
be received and parsed by the microcontroller (via the cell phone) and placed in the HCS command queue.
Examples of HCS functions:
• Turning on/off lamps.
• Activating the alarm.
• Turning on/off the heating.
To implement this functionality, an SMS thread is run in the microcontroller. This threads does two things:
• Check for incoming messages.
• Send outgoing messages.
Conseptual model of the SMS thread shown in figure 3.13 (page 40).
3.6.2 Communicating with the cell phone
The phone is connected to one of the serial ports in the BBox, and communication is done using Siemens
specific AT commands [13]. This require the DTR (Data Terminal Ready) pin to be high (12v), since the
data cable used with the phone needs power to be activated. In the original schematics the DTR pin was
not connected, but this was later done manually by soldering a wire between the DTR pin and pin 2 of the
MAX202CP.
A better solution would be to connect the phone on the inside of the BBox, but because of lack of space
and the danger of the phone interfering with the electronics in the box, we have decided to put it on the
outside even though it was supposed to be on the inside. If the box were designed to be mass produced, the
phone would have been placed on the inside, or else it would have destroyed the impression of the box as one
product, and not a box and a phone.
Connection specification:
• Baudrate: 19200 bps
40
System design
Figure 3.13: SMS thread model
3.6. SMS Communication
41
• Data bits: 8
• Parity: none
• Stop bits: 1
• Handshaking: none
3.6.3 AT commands
The needed AT commands are found in table 3.6 (page 41).
Command for sending an SMS:
Response (success)
Response (failed)
Command for reading SMS:
Response (success):
Response (failed):
Command for deleting an SMS:
AT+CMGS=<length><CR><pdu><ctrl+Z/ESC>
+CMGS: <mr>
+CMS ERROR: <err>
AT+CMGR=<index>
+CMGR: <status>,[<alpha>], <length><CR><LF><pdu>
+CMS ERROR <error message>
AT+CMGD=<index>
Table 3.6: Siemens AT commands
To retrieve the messages sent to the phone we issue the AT+CMGR command:
AT+CMGR=<index>
where
<index>
is the memory index where the message is stored.
We issue the command
AT+CMGR=1
to retrieve the first message from the phone. This results in the following response from the phone:
+CMGR: 0,,25
06917409001200040A91740910368400002001115131920007D4F29C9E769F01
OK
where 0 is the message status and 25 is the PDU length.
06917409001200040A91740910368400002001115131920007D4F29C9E769F01
is the PDU containing all of the message information.
This hex string can be parsed to retrieve what we need, that is; the message text and the senders phone
number. The phone number is used to verify that the message is coming from an authorized user. If the
user is authorized OK, the message is parsed and compared to all valid commands. If a match is found, the
command is executed and a confirmation is sent to the user. If the user sent an invalid command, the BBox
responds with an error message. If the message is coming from an unauthorized user the message is deleted
without any notification to the sender. This is to prevent spending money on error messages to unauthorized
users.
After a message is read, it is deleted by issuing the command
AT+CMGD=1
This deletes the message at memory index 1. We assume that the message memory initially is empty, and an
incoming message will therefor be placed at index 1. To maintain this assumption over time, we also assume
42
System design
that we are able to delete all incoming messages quickly enough to clear index 1 before a new message
arrives. If we are not able to clear the memory quickly enough, the next message will be placed at index
2. This means it is lost, since we only read messages that are placed at index 1. When we then are able to
delete the message at index 1, the next incoming message will be stored at index 1. The worst case scenario
is that 11 messages is neglected (12, which is standard memory size, minus the one at index 1). After that,
the network will delay all incoming messages until there is room in the phones message memory.
3.6.4 The PDU message format
The text messages are sent to/received from the phone in PDU format, which includes information regarding
service senter, transmitter and receiver address, the message itself, timestamp etc. We need not take advantage of all the features of the PDU format, and therefor use the default values when we generate and send
messages.
The received PDU includes what is given in table 3.7 (page 42).
06
91
7409001200
04
0A
91
7409103684
00
00
20011151319200
07
D4F29C9E769F01
Length of the SMSC information (octets of phone number and addresstype)
Type-of-address of the SMSC. (91 means international format of the phone number)
Service center number (in decimal semi-octets format. This means that the numbers
are switched two by two; 123456 -> 214365). If the length of the phone number is
odd, it is padded with a trailing F to make it even (12345 -> 12345F -> 2143F5).
First octet of the SMS-DELIVER message. We use the default value, which means:
"Reply path exists, No header in data field, No status report requested, No more
messages to send, This is an SMS-DELIVER PDU"
Address-Length. Length of the sender number (0A hex = 10 dec)
Type-of-address of the sender number
Sender number (decimal semi-octets). Same rule of conversien applies as with the
SMSC number.
Protocol identifier. (00 -> standard SMS)
Data coding scheme used. (7 bit standard alphabet, ordinary message)
Time stamp (semi-octets). (20011151319200 -> 021011 151329 00 -> YYMMDD
HHMMSS ZZ). This message was sent October 11th, 2002, 15:13:29, and the time
zone difference is 0 hours.
User data length, length of message. The data conding scheme field indicated 7-bit
data, so the length here is the number of septets.
Data field. Message "heisann" , 8-bit octets representing 7-bit data.
Table 3.7: Received PDU format
The PDU to be sent includes what is given in table 3.8 (page 43).
The PDU will be parsed (or built) in the AVR after receiving (or before sending) the message.
The messages are sent using a 7 bit alphabet, instead of the standard 8 bit. Because of this, we need to
implement translation from 8 to 7 bit and reverse. The translation is done by concatenating all the 7 bit
characters in the message, cutting pieces of 8 bits and sending these as normal 8 bit characters. When the
message is received the 8 bit characters are concatenated and cut into 7 bit pieces, which is the original
message. This way the format saves one bit for each character in the message, and gives 160 available
characters, instead of 140 using a 8 bit format.
Example translation in table 3.9 (page 43).
3.6. SMS Communication
00
11
00
0A
91
7409103684
00
00
AA
07
C862721A743A01
43
Length of SMSC information. Here the length is 0, which means that the SMSC
stored in the phone should be used.
First octet of the SMS-SUBMIT message. (11 means "No reply path, No header
in user data, No status report requested, Relative format, No rejection of duplicates,
This is an SMS-SUBMIT message".)
Message reference. The "00" value here lets the phone set the message reference
number itself.
Address length. Length of receivers phone number. (0A hex -> 10 dec).
Type of address. (91 indicates international format of the phone number).
The phone number in semi octets (Translation as above). If the number length is odd,
a trailing F is added before translation.
Protocol identifier. (00 means standard SMS).
Data coding scheme. (00 means standard SMS.) Setting this value to 10 lets us send
SMS alerts that pop up on the receivers screen without the user having to open the
message from the inbox. (Doesn’t work on old phones).
Validity period. (AA means 4 days).
User data length. (Length of message). The data coding field indicated 7-bit data, so
the length here is the number of septets to be sent.
User data. These octets represent the message "HEISANN".
Table 3.8: Transmitted PDU format
7 bit char
6543210
6543210
6543210
6543210
6543210
6543210
6543210
6543210
8 bit char
06543210
10654321
21065432
32106543
43210654
54321065
65432106
saved byte
Table 3.9: 7 to 8 bit translation
44
System design
3.7 Packet trace
The journey of an IP packet through the BBox
• The ethernet frame is buffered in the internal buffer of one of the network controllers, and the FPGA
is notified.
• The FPGA transfers the packet into shared memory and signals the microcontroller.
• The microcontroller looks at the packet header and decides what to do.
• If the packet is a SYN packet and the connection is accepted by the rule set (to be specified), an entry
is made in the NAT table 2 and the packet is forwarded (see below).
• If the packet is a FIN packet, the NAT table will be updated according to a simple state machine.
Depending on whether it is the first FIN packet in the connection, the NAT table entry is either updated
or removed, and the packet is forwarded.
• If the packet is addressed to a local port (on the BBox), we pass it on to the Nut/OS IP stack.
• If the packet still has no entry in the NAT table, the packet is discarded.
• The IP and ethernet headers are patched according to the NAT table, and the connection timeout value
in the NAT table entry is updated.
• The FPGA transmits the ethernet packet to the controller on the opposite side 3 , and the controller
transmits the packet on to the network.
Elaboration on the handling of individual packets:
• The source address is set to the BBox’s IP address on the particular net for which the packet is heading.
In the case of incoming traffic, the destination address is looked up in the NAT table.
• If the packet belongs to a protocol that requires special attention, e.g. FTP, IRC DCC or AUTH, the
FPGA will already have written information into shared memory. The exact extent of this as of yet
undecided, but it might be as simple as having the FPGA provide a list of offsets to "interesting" strings
within the packet, to avoid having the microcontroller do string matching, as the memory access of the
microcontroller is comparatively much slower than the FPGAs. This preprocessing would be done in
parallel with the initial copying of the packet.
• There appears to be some uncertainty as to whether or not IP packets embedded in ICMP "invalid
packet" payload fields should be patched. We choose to ignore them, since we probably broke the
packet in the first place.
3.8 Home Control System (HCS - X10)
The BBox should be able to interface with electrical devices in the house, enabling the user to control devices
in the house through a web interface or by sending SMS messages. It should also be able to receive input
from devices like door sensors or fire detectors.
2
If the IP address is unknown and on the LAN, we might have to use ARP to locate the MAC address of the host. This will,
however, happen very rarely, as most connections are outbound. The internal DHCP server’s constant ARP probing should have
discovered the host already. We can probably drop the packet safely, and thus avoid having to maintain a queue of delayed packets.
3
Or the same side, in case of ping packets et al.
3.8. Home Control System (HCS - X10)
45
X10 is a popular system for home control automation. Several manufacturers make X10 controllers and
sensors, including dimmers, switches, motion detectors and light sensors. The X10 protocol is widely used,
reasonable inexpensive, and well documented. It is therefore ideally suited for this project.
As the interface between the BBox and X10 devices we have chosen the Marmitek CM11G transceiver. It
can transmit and receive X10 commands through an RS232 interface. It also contains a microcontroller with
a timer facility to send X10 commands. Since the BBox already contains a real time clock, we have decided
to implement the timer feature in software.
The transmission medium used in X10 is the regular mains supply. Alternatively, some devices support
wireless communication through RF signals. Up to 256 devices can be addressed, using an addressing scheme
of 16 house codes ("A" to "P") and 16 device codes (1-16). Several devices can share (and respond to) a single
house and device code.
Each X10 message is transmitted two times, and each bit sent is followed by its complement bit. This is the
only fault tolerance built into the system, as there is no feedback from the receiving X10 devices. The bits
are transmitted on the zero-crossing of the alternating current. This does not provide an impressive data rate,
but it is sufficient for the kind of communication done by X10 devices (switching devices on/off, dimming
lights, etc).
An X11 message can either be an address message or a function message. For each X10 command sent, there
will be one or more address messages (always within the same house code) and one last function message.
There are 16 unique function codes defined. The most frequently ones used are the on, off, dim, bright, all
units off and all lights on/off commands.
The CM11 transceiver communicates with the BBox at 4800 bps with 8 bits, 1 stop bit and no parity. When
sending an X10 message, a header byte and an address/function byte is transmitted from the BBox. The
transceiver then responds with a checksum byte, after which it expects a reply confirming or cancelling the
message. The message is then ’transmitted on to the mains supply, and an acknowledgement byte is sent.
The header byte has the format described in table 3.10 (page 45).
7
d1
6
d2
5
d3
4
d4
3
d5
2
1
1
fa
0
e
Table 3.10: Header format
d1-d5 is the value (ranging from 0-22) in the case of a dim/bright command, while fa is 1 for a function
message or 0 for an address message, and e is 1 in an extended message.
The address/function byte has the format described in table 3.11 (page 45).
7
h1
6
h2
5
h3
4
h4
3
f1
2
f2
1
f3
0
f4
Table 3.11: Address/function byte
h1-h4 represent the house code and f1-f4 represent the function code or device code, depending on the type
of message. The house code and device code is shown in table 3.12 (page 46).
The mapping between function code and binary value is shown in table 3.13 (page 46).
When the transceiver experiences a power failure, it will need to be updated with the correct date, time and
default house code. It will send the byte 0xa5 every second to alert the BBox until the BBox has replied with
a proper response.
46
System design
Housecode
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Device Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Binary Value
0110
1110
0010
1010
0001
1001
0101
1101
0111
1111
0011
1011
0000
1000
0100
1100
Table 3.12: House and device codes
Function
All Units Off
All Lights On
On
Off
Dim
Bright
All Lights Off
Extended Code
Hail Request
Hail Acknowledge
Pre-set Dim (1)
Pre-set Dim (2)
Extended Data Transfer
Status On
Status Off
Status Request
Binary Value
0000
0001
0010
0011
0100
0101
0110
0111
1000
1001
1010
1011
1100
1101
1110
1111
Table 3.13: Function to binary mapping
3.9. Box
47
Likewise, when the transceiver received an X10 message from another X10 device, it will store it in a 10
byte large buffer and assert the RS232 "RING" signal in addition to sending the byte 0x5a every second. The
BBox can then receive the buffer by sending an acknowledgement. The transceiver buffer is then emptied. If
more than 10 X10 messages are buffered, any new messages will simply be discarded.
The X10 communication software is implemented using two Nut/OS threads, X10ReceiveThread and
X10TransmitThread. The receiving thread continuously polls the Nut/OS uart device.
• If more than three 0xa5 polling bytes are received in sequence, the x10_settime() function is called,
which in turn sets the date and default house code to a default value, as described in the CM11 hardware
documentation (the date could have been set to the system time, but as discussed above, the timing
feature of the transceiver is not used).
• If more than three 0x5a polling bytes are received in sequence, the acknowledgement byte (0xc3) is
sent to the transceived, and the returned data parsed. The x10_receive() function in the HCS Module
is called with the address, function code and value as arguments. For each function message in the
buffer, only the preceding address message is considered. This is done both to ease implementation
of the HCS Module, and because no known X10 devices (except computer controlled ones) support
sending of more than one address message per X10 command.
• If the byte is not recognized as either of these, it is assumed to be part of a communication between the
transceiver and the X10TransmitThread thread. Thus the X10TransmitThread is notified by means of
the x10_rcvd event handler, by using the NutEventPost() function.
When the HCS Module wishes to transmit an X10 command, it calls the function x10_enqueue() with the
address, function code and value of the command. This function allocates an x10command struct inserts it
into a linked list, and then notifies the X10TransmitThread through the x10_queue event handle. By having
the X10 communication code maintain its own queue, the HCS Module will be able to send several X10
commands "at once" and afterwards immediately be able to attend to other matters.
The X10TransmitThread will wait for queued events (by calling the NutEventWait() function on the x10_queue
handle). Whenever it is notified of a queued message, it will try to transmit the first message in the queue.
After assembling the header and address/function bytes, these bytes are transmitted by calling the
x10_send_message() function. This function tries to send the bytes, wait for a checksum by waiting for an
x10_rcvd event, send an acknowledgement, and wait for a return acknowledgement. Finally, the x10command
struct is removed from the queue, and any remaining queued commands are handled.
3.9 Box
3.9.1 Overview
3.9.2 Design sketches
The front of the box contains a mail LED, a MAIL RESET button, plexiglas logo and a loadmeter. The mail
LED is switched on when mail arrives and is reset when the MAIL RESET button is pressed. The loadmeter
shows the load when there is network traffic through the Bbox. Front panel is sketched in figure 3.14 (page
48).
The back panel contains two network interfaces. One is connected to the Internet Service Provider (ISP), and
the other is connected to the users computer (or a hub if multiple users are to connect to the internet). Three
LEDs show link and activity for each of the two interfaces. A power connector is mounted in the middle of
48
System design
Figure 3.14: Front panel
the back panel, and two male DSUB connectors are connected at the right. The DSUBs are used to connect
the cell phone and the HCS interface. Back panel is sketched in figure 3.15 (page 48).
Figure 3.15: Back panel
3.9.3 Dimensions and Drill Schematics
The drill schematics for the front- and backpanel of the box are displayed in figure 3.16 (page 48). The
sketches are very intuitive and require no further explanation.
Figure 3.16: Dimensions. Backpanel (Top) - Frontpanel (Bottom)
Comments on dimensions:
• The backpanel require drill holes for two DSUB9 serial-connector (A), a power connector (B) and
3.9. Box
49
RJ45 Ethernet connector (C) and six LANLEDs.
• The frontpanel require drill holes for the plexiglaslogo, a button and six LEDs.
• The frontpanel-button fits a 13,0 mm drill hole.
• All the LEDs require 3,0 mm drill holes, and the distance between the center of each LED is 4,0 mm.
3.9.4 Plexiglas logo
In front of the box there is a logo made from a piece of plexiglas that we got as a product sample. The BBox
logo was then engraved from the back of the plate to make a nice and clean visual appearance. The short
ends sides of the plate contains three blue LEDs each. When these are lit, the logo appaear as a blue floating
3D figure in the clear plexiglas. Because the plate is clear elsewhere, it is possible to view the circuit board
inside the box. This is (for the time being) a very popular feature in modern electronics designs. Picture of
the logo is shown in figure 3.17 (page 49).
Figure 3.17: Plexiglas logo
50
System design
Chapter 4
Testing
51
52
Testing
4.1. PCB test
53
4.1 PCB test
The printed circuit board testplan provides a logical order for conducting tests on the PCB. The testplan was
finished in advance, except the status-attribute which is used to indicate progression and refers to comments.
The first two tests were constantly checked during the whole development phase, but test 3 and 4 were
executed only once when the board returned from production. Test 5 was executed to check the power
planes, while two other boards were at Alphatron. The hand-soldering of the two prototype boards started in
test 7 and continued through 13. The soldering of the components was executed in the most reasonable way,
to avoid unnecessary problems. The smallest or lowest components, usually surface mounted devices(SMD),
were soldered at first, while the biggest or tallest components were soldered in the end. Furthermore, we
completed one board before starting the other. Thus, the experience gained from the first board would gain
us during the repetition, and the errors made could hopefully be avoided the second time. If we made an error
so severe that permanent damage would be inflicted, at least we would not risk destroying both boards. PCB
test plan listed in table 4.1 (page 54).
(1) LEDs contains: One Philips LED Shift Register, 12 resistors and 12 LEDs. (2) LEDs2 contains: One
Philips LED Shift Register, 12 resistors and 12 jumpers to be used for external LEDs.
Comments on status:
1. An unplaced resistor was discovered after the PCB had been produced. Luckily, it was possible to implement it in the FPGA. See "Design Flaws".
2. The board seems alright after a little inspection, but errors are understandably very difficult to discover
visually.
3. After the soldering of the Power block were finished, the voltages were checked. All powerjumpers
showed an adequate accuracy, and the measured voltages were 5.11V for 5V plane and 3.55 V for the 3V6
plane.
4. Alphatron’s soldering was checked with a microscope and no errors were found.
5. We later found out that an additional pin on the dual port RAM had to be connected to the microcontroller.
See "Design Flaws".
6. We later found out that the "Data Terminal Ready"-pin had to be set high. See "Design Flaws".
4.2 FPGA test
4.2.1 Unit Testing during Development
The VHDL code modules contain their own test vectors embedded as comments between the entity and
architecture sections. A small Perl-script (found in the appendix) extracts these and generates ActiveHDL
scripts that run the simulator with the given parameters. A comment like "–>101010" next to a signal or
input definition specifies that the signal is to be driven to the given value initially. Several lines of the form
"–delta-time signal=value signal=value" define a wave form.
4.2.2 Modular Behavioral Simulation
The different modules in the FPGA design are tested independently. A test bench will be written for each
module in order to take care of sending stimuli and interpreting outputs. For test plan, see table 4.2 (page
55).
54
Testing
Test
No.
1.
Description
Expected/Correct Result
Status
Check schematic diagrams for errors.
OK
2.
Check the PCB design.
3.
Check the PCB visually for obvious errors.
4.
Compare the routing to the pinlist.
5.
Solder the components in the Power block. Check
voltages.
6.
Check Alphatron’s soldering.
7.
Solder the components in the Power block. Check
voltages.
8.
OK
All components connected.
OK
All components connected.
OK
11.
Solder the remaining components belonging to the
MCU part of the PCB. Unplaced components include Decoupling Capacitors, TimeKeeper, Latch,
MUX, JTAG, ISP, Crystal, 4xDIP switch, LEDs(1),
LEDs2(2), Pressbutton and one Testpod.
Solder the remaining components belonging to the
FPGA part of the PCB. Unplaced components include Decoupling Capacitors, SPROM, JTAG MultiLINX, Clock, XChecker, Switch, LEDs(1), PressButton and two Testpods.
Solder the remaining components belonging to the
Ethernet Controller part of the PCB. Unplaced components include Decoupling Capacitors, Crystal,
Isolation Transformer, RJ45 Connector, Resistors,
other Capacitors, LANLED, LinkLED, BStatusLED
and two Testpods.
Solder the Dual Port RAM’s Decoupling Capacitors.
All components are connected. Pins
that require connection are connected.
All components are routed. All the
components are placed.
Correct component placement and
routing according to the Gerber files.
All pins are connected as specified in
the pinlist.
The power-planes are connected to the
correct voltage. 5V in the VDD5 and
3.6V in the VDD3V6
FPGA, MCU, Dual Port RAM and
ethernet controllers are connected correctly.
The power-planes are connected to the
correct voltage. 5V in the VDD5 and
3,6V in the VDD3V6
All components connected.
12.
Solder the remaining components in the Serial part.
All Decoupling Capacitors connected
correctly.
All components connected correctly
13.
Solder the remaining Testpods.
All components connected correctly.
OK,
note 5
OK,
note 6
OK
9.
10.
Table 4.1: PCB test plan
OK,
note 1
OK,
note 2
OK
OK,
note 3
OK,
note 4
OK,
note 3
4.2. FPGA test
55
No.
1
Module
I/O Module
2
Internal bus, decoder
3
Debug Output
The module is given a few register values.
4
Ethernet Control Module
Direct Control Output Test:
Test vectors are written to the
EDCD/EDCA registers, and the
EDCWE bit is set.
Direct Control Input Test: A test
vector is written to the EDCA
register and on the external NIC
data bus, and the EDCRE bit is
set.
Polling: The ECRA bit in ExCR
is set.
5
6
7
8
Test Description
Several commands are placed
on the control port, and the response is noted. All defined
commands are exercised.
Test data is written to and read
from the test register and other
registers.
Packet reception: The EFR bit
(in the NICs status register) is
set.
RAM Arbiter
The grant lines are asserted one
by one and simultaneously.
Expected Results
The control signals and other inputs
for the register bank should reflect
the given command.
Results
OK
The data read from the test register
correspond to the data written, and
should not be changed by writing to
other registers.
The data should appear at the output
one bit at a time, LSB first, properly
clocked (the data should be valid on
the positive clock edge)
The correct values should appear on
the external NIC data and address
bus.
OK
The data from the external NIC data
bus should appear as the EDCD register.
OK
The ECM should begin polling the
NIC status register. It should continue to do so until the Ethernet
Frame Received bit is read as 1. At
this point, the Packet In Transit bit
should go high.
The ECM should read the NIC registers containing the packet size,
and enter a loop doing a NIC-tomemory copy. The packet length
should show the correct values, and
the RAM cycles should be valid. etc
ad nauseam
Only one request line should be
high at any time. No grants should
happen unrequested.
Not
Implemented
Table 4.2: Module test
OK
OK
Not
Implemented
OK
56
Testing
4.2.3 On-Board Testing
These tests are performed by uploading a small test driver program to the microcontroller. The test driver
allows us to read and write hex values from the various registers of the FPGA. See tabel 4.3 (page 56).
No.
1
2
3
4
5
6
Module
Internal bus, decoder, I/O module
Debug Output
Ethernet Control Module
Test Description
As test 2 above.
Expected Results
As above. This will implicitly show
that the I/O Module is working.
Results
OK
As test 3 above.
The data should be visible on the internal debug LEDs.
The status registers should show
reasonable values.
Once a cable is connected, the "link
valid" flag should go high. Being in
promiscuous mode, the NIC should
accept any packets received from
the Ethernet. Thus, the "packet received" flag (of the NIC) should go
high at most a few seconds later.
We should also be able to read this
packet manually (though slowly)
across the control connection.
The packet should appear
OK
Direct Control test: We send various commands to the NIC
Ethernet Initialization: A complete set of initialization vectors
is sent to the NIC. The NIC is
placed in promiscuous mode.
Network test: A frame is sent by
controlling the Ethernet chip directly
Polling: The reception enable bit
is enabled.
7
Packet Reception: As above.
8
Packet Transmission: A frame is
placed in memory, and the ExSPAR and ExSPLRL are set accordingly. At the receiving end
a packet sniffer (say, tcpdump) is
run.
After a little while, the Packet In
Transit bit should go high.
After a slightly longer while, the
Packet Received bit should go high,
and a packet should be readable
from the shared RAM.
After a while the Packet Sent bit
should go high. The frame should
appear in the packet trace at the receiving end.
OK
OK
OK
Not
Implemented
Not
Implemented
Not
Implemented
Table 4.3: On-board testing
4.3 Microcontroller test
Microcontroller testing is devided into testing of sub components (table 4.4, page 58) and program modules
(table 4.5 on page 59, table 4.6 on page 60, table 4.7 on page 61, table 4.8 on page 62 and table 4.9 on page
63).
Simple tests are done on the BBox curcuit board, using pieces of code. Overall testing is done using all the
4.3. Microcontroller test
57
code combined together. To monitor the serial outputs from the BBox we use a terminal client. LEDs are
also used for debugging.
Some parts have not been tested, since not all of the system is implemented. These tests are labeld N.I. (Not
Implemented).
Note 1: Only successful in test code, not from within Nut/OS.
Note 2: Not all of the features are implemented, and therefor their initialization will not work correctly.
58
Testing
Test
nr
1
Sub component
General
Test name
Test description
Expected results
Results
Flash programming
the AVR
The AVR is programmed
using the SPI interface
while mounted on the circuit board
The AVR is programmed
with at simple program that
turns the LEDs on and off
at an appropriate interval
The reset button is pressed
AVR Studio verifies successful programming
OK
2
General
LED
test
The LEDs flashes
OK
3
General
4
Serial Port
Reset function test
Serial port
test
The AVR is reset and return
to normal operation
Data is written correctly to
a connected terminal and
be read correctly from the
terminal (and echoed)
The FPGA will respond
according to defined behaviour
Correct bitvalues (according to the datasheet) are
output to the serial port
OK
5
6
FPGA
communication
Timekeeper
FPGA communication
test
Timekeeper
test
7
SRAM
SRAM test
The AVR is able to
read/write SRAM and
confirm this to the serial
port
The AVR is able to
read/write EEPROM and
confirm this to the serial
port.
The AVR is able to run
the Nut/OS UART example
and communicate through
both of the serial ports
OK
8
General
EEPROM
Read/Write
Test
Verify that we are able to
read and write from the
AVR EEPROM.
9
Nut/OS
Nut/OS
UART test
The AVR is programmed
with the UART example
code from the EtherNut
package and the board is
connected to a terminal
with the appropriate baudrate
10
Nut/OS
Nut/OS
memory test
The Nut/OS is able to address the external SRAM
and report correct memory size, and allocate heap
memory
The Nut/OS / AVR is able
to respond to an interrupt
by writing ’Interrupt!" to
the serial port
OK
11
Nut/OS
Nut/OS
interrupt test
flash
Test that we are able to
send and receive data on
the serial ports
Test that we are able to
write to FPGA registers
and read from registers
Data from timekeeper will
be read and written by the
AVR and output to the serial port
Verify that we are able to
activate the SRAM and utilize it from the AVR
Table 4.4: MCU test plan, part 1
OK
OK
N.I.
OK
OK
N.I.
4.3. Microcontroller test
59
Test
nr
12
Program
module
Nut/OS
Test name
13
SMS subsystem
Siemens
C35 init test
14
SMS subsystem
SMS
test
15
SMS subsystem
SMS receive
test
16
X10
subsystem
X10 init test
17
X10
subsystem
X10
test
18
X10
subsystem
X10 receive
test
Test description
Nut/OS
thread test
send
send
We switch off the phone,
connects it to the serial port
of the AVR and triggers the
SMS power up code from
the STK500 dev. board
The SMS send code is activated from the STK500
dev. board and an SMS is
sent by the AVR
We send an SMS from a
private phone to the project
phone, and wait for the text
to be displayed in the terminal program connected
to the AVR.
We connect the CM11 interface to a serial port and
the mains supply. We monitor the serial communication to ensure that the
CM11 is programmed correctly
We connect the already initialized CM11 interface to
a serial port and trigger an
X10 event from the AVR
controller. A lamp is connected to the LM11 module
that is also connected to the
mains supply and and has
been confirmed to work
The SM11 X10 controller
and the CM11 interface
is connected to the mains
supply. The AVR is programmed to write to the serial port when it receives a
specific X10 message
Expected results
Results
The Nut/OS is able to
switch
between
two
threads, one writing to a
serial port, another flashing
the LEDs.
The phone is switched on
(PIN code is disabled)
OK
The correct SMS is received at one of our private
phones.
OK
The AVR parses the received SMS and writes the
text and sender number to
the serial port
OK
The AVR is able to initialize the CM11 interface
with the current time and
date
OK (current
date not used.
Preset date used
instead.)
The AVR is able to send
an X10 message to an arbitrary device and the device responds with the correct behaviour
OK
The AVR is able to receive
an X10 message from an
arbitrary control device and
output the message to the
serial port
OK
Table 4.5: MCU test plan, part 2
N.I.
60
Testing
Test
nr
19
Program
module
EtherNAT
subsystem
Test name
Test description
Expected results
Results
Ethernet
controller
communication
test
The AVR is able to write
and read registers of
both ethernet controllers
through the FPGA, and
correct value is displayed
in the terminal
OK
20
EtherNAT
subsystem
Ethernet init
test
The AVR is able to set up
the ethernet controllers correctly according to the configuration. The AVR is able
to receive notification of an
incoming packet
N.I.
21
EtherNAT
subsystem
Ethernet
packet
receive test
EtherNAT
subsystem
Ethernet
packet send
test
The AVR is interrupted by
the FPGA. The AVR is able
to program the FPGA to
transfer a packet to memory, and is able to read the
packet
The AVR is able to program the FPGA to transfer
a packet from memory to
an ethernet controller. The
ethernet controller is able
to transmit the packet to the
network
OK (Note 1)
22
The FPGA is programmed
to allow direct connection
the ethernet controllers.
Register are written to, and
read afterwards. The AVR
will output the register
values to a serial port
The FPGA is programmed
to allow direct connection
the ethernet controllers.
The ethernet controllers are
initialized to the correct operating mode as described
in the CS8900A Data
Sheet. An ethernet packet
is sent to the specified
ethernet address. Registers
are read to confirm that
the packet is received. The
AVR outputs the register
data to a serial port.
The ethernet controllers are
initialized, the ECM in the
FPGA is activated and a
packet is sent from an external ethernet device to the
specified ethernet address.
The ethernet controllers are
initialized, the ECM in
the FPGA is activated and
a FPGA is programmed
to transfer a packet from
memory to an ethernet controller. The ethernet controller is programmed to
transmit the packet, and an
external ethernet device is
programmed to listen for
packets on the LAN.
Table 4.6: MCU test plan, part 3
OK (Note 1)
4.3. Microcontroller test
61
Test
nr
23
Program
module
EtherNAT
subsystem
Test name
Test description
Expected results
Results
Nut/Net Ethernet Transmit test
The ARP packet is transmitted through the correct
ethernet interface.
Not OK
24
EtherNAT
subsystem
Nut/Net
Ethernet
Receive test
The ARP packet is received
by the Nut/Net ARP subsystem, and the ARP entry
is written to a serial port.
Not OK
25
EtherNAT
subsystem
Nut/Net IP
Transmit test
The ICMP ping packet
is transmitted through the
correct ethernet interface
Not OK
26
EtherNAT
subsystem
Nut/Net IP
Receive test
The ARP ICMP ping
packet is received by the
Nut/Net IP subsystem, and
a confirmation is written to
a serial port.
Not OK
27
EtherNAT
subsystem
Packet Routing test
The IP packet is correctly
translated and received by
the other host.
Not OK
28
EtherNAT
subsystem
Packet
Route Create test
A simple ARP packet is
sent from the Nut/Net system to a specified ethernet
address. An external ethernet device is programmed
to listen for packets on the
LAN.
A simple ARP packet is
sent from an external ethernet device to the Bbox.
The Nut/Net system is programmed to listen for packets on the LAN.
A simple ICMP ping
packet is sent from the
Nut/Net system to a
specified IP address. An
external ethernet device is
programmed to listen for
packets on the LAN.
A simple ICMP ping
packet is sent from an
external ethernet device
to the Bbox. The Nut/Net
system is programmed to
listen for packets on the
LAN.
Two hosts are connected to
each of the BBox ethernet
interfaces. An IP packet
matching an existing routing table entry is sent from
one host to the other.
A SYN packet initiating
a new connection is sent
from one host to another
through the BBox. The
BBox is programmed to
write the routing table to
the serial port, before and
after receiving the SYN
packet.
The correct routing table
entry is created and displayed on the connected
terminal, and the correctly
translated SYN packet is
received by the other host.
Not OK
Table 4.7: MCU test plan, part 4
62
Testing
Test
nr
29
Program
module
EtherNAT
subsystem
Test name
Test description
Expected results
Results
Packet
Route Timeout test
A connection is established
between two hosts. The
connection is allowed to
time out. The BBox is programmed to write an acknowledgement to a serial
port when the routing table
entry has been deleted.
A connection is established
between two hosts. The
connection is closed by one
of the hosts. The BBox is
programmed to write an acknowledgement to a serial
port when the routing table
entry has been deleted.
A DHCP Lease request is
sent to the BBox from the
LAN. The BBox is programmed to write lease
data to the serial port.
DHCP lease renewal is also
tested.
The BBox is able to get a
DHCP lease from an external DHCP server on the
WAN interface.
The AVR writes the deleted
routing table entry to the
serial port.
Not OK
30
NAT subsystem
Packet
Route Close
test
The AVR writes the deleted
routing table entry to the
serial port.
Not OK
31
DHCP
Server
subsystem
DHCP
Server test
The DHCP client host is
able to get a DHCP lease
from the BBox. The DHCP
client is also able to get a
DHCP lease renewal.
N.I.
32
DHCP
Client
DHCP
Client test
The BBox requests a
DHCP lease, the DHCP
server responds and the
BBox is configured with
the correct IP settings
according to the DHCP
reply.
The AVR loads the initialisation routine which initialises all subcomponents
(X10/Phone interface Ethernet controllers and IP
subsystem).
OK
33
General
Power
Test
Up
The unit is powered on.
Table 4.8: MCU test plan, part 5
OK (Note 3)
4.3. Microcontroller test
Test
nr
34
Program
module
General
35
63
Test name
Test description
Expected results
Results
Power Failure Test
The Power Failure switch
is activated.
OK (By simulating power
loss)
Home
Control
System
Receive
Event Test
36
Home
Control
System
Modify
event
rule
table
37
Web Interface
HTTP
Request test
38
Web Interface
Web Interface
Access to the requested resource is granted based on
the origin of the request.
The correct configuration
page is displayed, and
the configuration parameters of the BBox are affected by the update.
N.I.
39
HTTP Access Control
test
BBox Configuration
test
40
Web Interface
A HCS Event is generated
and delivered to the HCS
module from the SMS, X10
or Web interface.
A new rule is generated and
added to the event rule table. The new event rule is
tested as above.
A BBox HTTP resource is
requested by an external
host.
An external host attempts
to access a restricted HTTP
resource.
A host originating from
the LAN is able to access the BBox configuration web page (after authorization), and post updates
to the configuration.
A host originating from the
LAN or the WAN (after authorization) is able to access the BBox HCS Control web page and trigger
events and, in the case of
a LAN connection, modify
event rules
The AVR sends an SMS
message. When power returns, the AVR will reload
configuration data.
The HCS module responds
by taking the appropriate
action as described by the
(pregenerated) event rules.
The event rule is added,
and the appropriate action
is triggered by the external
event.
The requested resource is
delivered to the host.
The correct web page is
displayed, and the BBox
triggers
the
specified
events or modifies the
specified rules.
N.I.
HCS Control
test
Table 4.9: MCU test plan, part 6
OK
N.I.
N.I.
N.I.
64
Testing
4.4 System test
4.4.1 Network performance tests
The general network setup used for the basic network tests consists of two standard PCs connected by a hub
to the LAN port, and a third PC connected to the WAN port, as described in table 4.1 (page 64).
Figure 4.1: Network performance test setup
For all the tests, the following BBox setup is used:
• WAN side IP: 129.241.102.201 (dmlab-web1.idi.ntnu.no), mask ff.ff.ff.00
• LAN side IP: 10.0.0.1 (RFC1918 private address space), mask ff.ff.ff.00
• DHCP server active
• BBox MAC: 00 51 C5 0C 7E 75 1
Connectivity test
The BBox is configured as per the above, and the ping command is run at both ends. For the following, R
will denoted the remote (WAN-side) PC, and L the local PC.
Commands:
Expected results:
(R) ping dmlab-web1
(L) ping 10.0.0.1
"dmlab-web1 is alive", etc
Table 4.10: Ping command
Verification of the NAT service
A simple test of the NAT service is done by opening a TCP connection from a PC on the LAN side to one on
the WAN side, using the ’netcat’ utility. Network analyzers ("packet sniffers", in this case ’tcpdump’) are at
1
While technically non-compliant, we did not have $1,650 lying around to register an OUI. Besides, any six octets should do.
4.4. System test
65
both ends to verify the correctness of the translation.
Commands:
Expected results:
(R) nc -vlp 1234
(L) nc -v glenfiona 1234
A connection should be established, and any text written
on one keyboard should appear on the opposite screen.
Table 4.11: NAT verification
Latency test
One of our concerns during the design was whether a low-power microcontroller such as the microcontroller
would be able to adequately handle the task of routing vast amounts of network traffic without causing
noticeable delays. It is well known that at high speeds, protocol overhead often dwarfs the actual network
latency.
Commands:
Expected results:
(L) ping -s dmlab-web1
The round-trip time of a single packet will appear.
Table 4.12: Latency test
To compensate for the latency of the two PCs used, another test run is done with the two PCs connected
back-to-back, and that result is subtracted from the result above.
Performance test
As a rough test of the overall system performance under load, a large file transfer is performed. Again, the
performance is measured with the BBox in place, and using a direct crossed-TP connection.
NAT application level test
A realistic load is simulated by disconnecting the Remote PC, and connecting the WAN port directly to the
Internet (by way of the NTNU Campus Network). Both local PCs are then used to surf the web simultaneously, and the system performance is monitored.
4.4.2 Power
The voltage of the 5V-plane is measured to 5.11V, and for the 3V6-plane the exact value is 3.55. These values
are constant over the entire plane.
The voltages in the power planes start dropping when the input power drops below 8V. We have not tested
the upper limit of the input power since we only have two operational boards.
The current delivered to the box was measured to 330 mA. With a 9V power supply, the power consumption
is thus 3W. It should be noted that the FPGA was operating at a very low frequency, so the consumption may
increase when the box is operated at full speed.
66
Testing
During normal operation the box is connected to an outlet, so the power consumption itself is not a problem.
However, some heat is dissipated in the voltage regulators. Thanks to the relatively large cooling ribs, the
temperature only increases slightly above body temperature.
Chapter 5
Tools
67
68
Tools
5.1. Software used
69
5.1 Software used
5.1.1 Mentor Design Capture/Expedition PCB
Design and layout of PCB board; schematics are drawn in Design Capture. This program supports a modular
design. Several components are available from a library, and new parts can be added to the library. From the
schematics, a netlist can be generated.
This netlist can then be used in Expedition to connect and place the components on the PCB. Traces on the
PCB are then routed, either manually og automatically. Various options concerning the PCB can be selected,
including the number of layers and ground/voltage plane design and placement. Drill holes, vias and the silk
print can be specified. The resulting Gerber files are sent to the PCB manufacturer for production.
5.1.2 Xilinx Foundation 3.1i
The FPGA development was initially done using Xilix Foundation. This turned out to be a bad idea, as the
development environment leaves a lot to be desired. The "Project Manager" seems to be a loose collection
of scripts about to collapse under its own complexity. The individual modules are interdependent, often
circularly. For instance, changing the name of an input pad which has been locked to a physical pin will
cause the implementation engine to fail. Unfortunately, the constraints editor takes its lists of i/o pads from
the output of that engine. Several times, one part of the system managed to delete a file needed by some
other part, leaving only a cryptic "design does not exist" error, with no clue as to which file was missing. In
essence, we were spending more time debugging the GUI rather than the design.
5.1.3 Aldec Active-HDL v4.2
Active-HDL is built from the ground up for VHDL (as the name would imply), and works like any other
development environment. The simulator/debugger is integrated with the editor. Even the parser is better. Where Foundation splurts out a terse "Syntax Error", AHDL will explain exactly what is wrong, and
sometimes even why.
AHDL also has a powerful scripting language (actually at least three: a BASIC variant, Tcl/Tk and Perl),
which enabled us to automate the unit testing and simulation.
The simulation script would crudely parse the entity and architecure descriptions, extracting a list of all
inputs, outputs and signals defined. VHDL comments in a special format would specify what signals were to
be driven by the simulator:
entity Foo is
port (
CLK: in STD_LOGIC;
--&; 40mhz
RESET: in STD_LOGIC;
--&; 0
BONK: in STD_LOGIC_VECTOR(1 downto 0); --&;00
.....
The above lines would cause CLK to be driven by a periodic signal at the given frequency, and sets the initial
value of the other signals to 0. The following script would set the time-varying inputs:
\ --100 reset=1
-- after 100 ns, reset is set to 1
\ --300 bonk=11
-- after a further 300 ns, bonk is set to 11
\ --300 bonk=10 | bonk=01 | bonk=00
-- some more vectors (staggered)
70
Tools
\ --800 done
-- stops the simulator 800 ns after the last input
The implementation was done by running the various Foundation Express tools from the command line using
GNU make, automating the entire process from VHDL code to uploadable bit file.
5.1.4 Atmel AVR Studio
AVR Studio is a complete software environment for assembly programming and software debugging for the
AVR microcontrollers. The software also supports programming of the microcontroller using the SPI og
JTAG interface, and in-circuit emulation using appropriate hardware.
5.1.5 AVR-GCC
AVR-GCC is a free C compiler for the AVR family of microcontrollers. It has support for most of the AVR
product line, including the ATmega128.
At first it was decided that the AVR group should use the IAR Workbench, since we believed that this was the
only tool that would provide a sufficient debugging environment. But because of license dongles sometimes
failing, difficult user interface and the fact that Nut/OS had to be modified to work with IAR, we decided to
go for gcc.
5.2 Hardware used
5.2.1 Atmel STK 500
Figure 5.1: Atmel STK 500
These starter toolkits have been used for testing all sorts of microcontroller code. Experiments include X10
testing, SMS sending and FPGA interfacing. As these boards come with several buttons, LEDs and port
connectors as well as a RS232 serial port they are very flexible. The default microcontroller for these boards
is an AT90S8515. By adding an expansion card, the STK501, we could use the ATmega128.
5.2. Hardware used
71
Figure 5.2: Atmel AVR Embedded Internet Toolkit
5.2.2 Atmel AVR Embedded Internet Toolkit
The AVR Embedded Internett Toolkit is a stand-alone web server on a small PCB, including an AVR microcontroller and a CS8900A ethernet controller chip. This has been useful for learning how the CS8900A
works. Packet sending was tested by reprogramming the on-board microcontroller. We also soldered on an
expansion port so that we could interface with the FPGA test board.
5.2.3 XILINX FPGA test board
The Xilinx FPGA test board contains two FPGAs, an XC3130A and an XC4006E. The board has connectors
for all FPGA pins, and a reasonable collection LEDs and switches for debugging. In our development phase
Figure 5.3: XILINX FPGA test board
we used the XC4006E extensively. The board can be programmed via an XChecker cable.
72
Tools
Figure 5.4: Hewlett Packard Logic Analyzer
5.2.4 Hewlett Packard Logic Analyzer
The HP logic analyzer is a powerful tool for analyzing a digital design. It includes a pattern generator, an
oscilloscope and probably most important: an analyzer. Its pods can be connected directly to the test pods on
our PCB, making it easy to analyze for instance bus data. The analyzer has a powerful PC interface.
5.2.5 DEC VT320 teletype
Figure 5.5: DEC VT320 teletype
This VT terminal has an RS232 interface which makes it practical for connecting to the BBOX. It has been
used extensively for debugging the system.
Chapter 6
Notes
73
74
Notes
6.1. Design flaws
75
6.1 Design flaws
• A pull-up resistor was left unplaced in the PCB design. This was handled by implementing it in the
FPGA, since this device can be set up with internal pull-ups. The resistor in question has the reference
designator R18_1 and is found in appendix B.1.6.
• No DTR pin (Data Terminal Ready) was connected to the RS232 port. This disabled communication
with the phone. The DTR signal was later patched by soldering a wire from the MAX202 chip to the
RS232. See appendix B.1.12.
• In the original design, the output on the left side of the dual-port RAM was enabled as long as the chip
was selected. However, it turned out that this would conflict with the microcontroller as it tried to write
the next address into the latch through the common address/data bus. Both chips would drive the bus,
leading to incorrect data being loaded into the latch. Fortunately, we anticipated errors in the design.
Therefore, the trace from the Output Enable Left pin (OEL), among others, was placed well outside
the memory chip itself on the PCB. Thus, it was fairly easy to cut the trace on the finished board and
solder on a wire to the Read pin (PG[1]) on the microcontroller. See the schematics in appendix B.1.
• The clock signal for the Ethernet controllers is disturbed when two testpods are connected to it. We
believe the reason for this to be that the signal does not have enough driving strength. It was therefore
difficult for us to foresee this. Our solution was to remove the pin with the clock signal from one of
the two testpods to which it is connected.
6.2 Status
6.2.1 MCU
SMS functionality is working. It is possible to send messages to the BBox and to receive a response. Response messages is sent as network alerts and will pop up immidiately on the receivers display. Integration
with the X10 modules is complete. Table of possible SMS command contains only two entrys; LIGHTSON
and LIGHTSOFF but may be extended if new X10 modules are added.
X10 functionality is tested seperatly and found to be working. Using the X10 modules at school has partially
failed because of problems with noise on the electrical system, but X10 commands have successfully been
sent from and received at the Atmel STK501 development board using the ATmega128 microcontroller. After
integration with the SMS part, we have not been able to successfully send/receive X10 commands, although
we believe that the signals sent from the BBox are correct. We believe noise is corrupting the signal and thus
creating situations that are hard to recreate and debug.
6.2.2 FPGA
I/O Module works. Debug output / LED register works. Ethernet control modules work for direct control.
This means that the microcontroller can control the ethernet controllers directly, and therefore send and
receive packets. All data is sent over the BBus. The automatic blitting of packets into SRAM memory is
not fully tested. It should be noted that the current FPGA clock speed is 1 MHz, as the initial testing at
50 MHz produced too many errors. It probably manages more than 1MHz, but the design will have to be
optimized before we can run it at 50MHz again. We could investigate some form of multi-cycle instructions
to increase the maximum clock speed. This way the packet transfers could run at optimal speed, and the
read/write-to-register commands could be allowed to span over multiple cycles.
76
Notes
6.2.3 PCB
The PCB was printed at Elprint in Bergen and has been used to test all components together. The board is
working as planned, but two alterations have been done. A patch wire has been added between the microcontroller and the memory. This was done because of a design error, and the patch has been proved to work
fine. The second modification is a patch wire between the UART driver chip and one of the serial ports. This
is done because the unconnected DTR line on the serial port needs to be set to activate the cell phone’s data
cable.
6.3 Future expansions
6.3.1 More RAM
We have included the possibility of increasing the SRAM memory size twofold to 128KB without changing
the board. The 128KB SRAM chip is pin compatible with the present chip. Addressing 128KB requires 9
address lines, one more than for the present chip. This last line is connected to an extra pin on the microcontroller, thus making it possible to reach the extra 64KB by using this pin for "RAM bank selection."
6.3.2 Expansion Port (’Geek port’)
The unused pins on the FPGA were to be connected to a separate pod for future expansion, ie. a USB
expansion board. This was unfortunately a good idea that was lost in the transition from system design to
PCB design, mainly due to the time constraints involved in getting the PCB design finished, and a focus on
all the other problems that needed to be resolved.
6.3.3 More HCS protocols
The X10 protocol already supported gives the possibility of controlling a wide range of home automation
devices, like alarms, heaters, switches, sensors and dimmers. Other home control systems could also be
implemented. Assuming that these home automation transceivers can be controlled via a serial port, it would
be easy to connect them. The microcontroller still has program space for implementing the control code.
6.3.4 PPPoE
The PPPoE protocol should be implemented if the box were to be mass produced. This should be possible by
extending the network code in the microcontroller. As the PPPoE is the protocol used by the large Norwegian
internet service provider Online (Telenor Internett), this would have to be supported.
Chapter 7
Discussion
77
78
Discussion
7.1. Workflow
79
7.1 Workflow
Because of the heavy workload, we divided the project group into three subgroups:
• PCB group
• AVR group
• FPGA group
We found this grouping the most natural, even though we knew it was not optimal for the learning process.
But in a project of some size, it is impossible for all group members to participate in all activities. We
arranged frequent meetings to organize the work and to exchange ideas and experiences. To arrange the
paperwork we set up a wiki web page. The wiki page works like a blackboard where everybody can add,
change or remove the pages. This way all the information could be shared easily.
In addition to the three subgroups, a few key responsibilities were distributed. A leader for the project was
elected, to keep everything together and make sure it did not dwindle into chaos and disorder. A documentation officer was appointed, to distribute the documentation tasks, and ensure that it was done. Documentation
was regarded as a communal task and responsibility, but one person being responsible for the task, was a
good way of making sure it would be done. Finally, a parts/purchase officer was appointed to make sure we
had all the parts/components we needed for the task, this included both going through what we already had,
and making sure purchases of what we did not have were done.
The PCB group had the hardest time in the beginning because of tight deadlines and a few problems with the
software. This period, the two other groups got to know the tools and hardware they were supposed to use.
None had any experience with PCB layout, so the group had to learn as they went along. After the Gerber
files with the board layout had been sent to Elprint for production, the PCB group could take a deep breath.
It was now up to the AVR and FPGA groups to implement the code needed to make the BBox do something
useful. At first it was decided that the AVR group should use the IAR Workbench, since it was believed
that this was the only tool that would provide a sufficient debugging environment. But because of license
dongle problems, complex user interface and the fact that Nut/OS had to be modified to work with IAR, it
was decided to go for gcc.
The FPGA group also ran into problems with software licenses. In the beginning there were lots of trouble
with the Foundation license server. After finally getting Foundation up and running, the group soon found
out that the Foundation Project Manager environment was very troublesome to use. They decided to abandon
Project Manager and use a makefile instead. Aldec Active-HDL was chosen as the new HDL editor. This
worked much better. The Aldec license also stopped working one Friday evening so the weekend coding had
to be delayed a bit. The guys at IDI network administration even took the license server off the network, but
this was soon fixed this by (somewhat anxiously) taking the matter in our own hands to get it up and running
again.
There were also problems with the computer network at campus because of a disk crash at STUD. The result
was that our wiki pages were gone a couple of days, and that all mails were delayed for about a day. When we
managed to get the files back, we moved them from STUD to IDI. Since then, there have been no problems
with the servers.
A factor that has been slowing us down a bit is the lack of operational computers. In reality, only four
machines have been stable enough for us to use. The rest suffer either from lack of software, instability or
simply head-ache inducing monitors. Because of this we had to bring some of our own hardware to the lab.
Towards the end we got a fifth decent computer for use in the hardware lab.
80
Discussion
The staff had a policy of not giving us very much help, so during the project we have been pretty much on
our own. We were expected to find all answers ourselves. Since there has been no lectures the web has been
our main source of information. We do not know how much this has slowed us down, but we know from
experience that searching for relevant information on the web can be a time consuming process. A simple
search often result in hundreds of hits, and finding just what you are looking for can take hours. Reading
product data sheets and application notes is confusing when you have never seen one before.
To sum it up, this project has been a race against the clock. To design, get parts, build and implement software
for a router from scratch is time consuming. Much more time has been put into this project than expected in
the beginning. There have been late nights for all of us, and other courses have suffered because of this.
7.2 Experiences
7.2.1 General
We have all learned quite a few things from this project. Perhaps most of all how many pitfalls there are.
Software licenses were a constantly returning problem. Even though you own a license it will not always
work. And computer support is not always as easy as it sounds.
Getting all the parts for the box was not trivial either. If it had not been for EIAB, a specialist in providing
urgently needed out-of-stock parts, we would not have managed to get the SRAM somewhat on time. We
learned it is important to follow up your orders and check on the status. Things will usually not arrive when
they are supposed to, you should get the contractors to guarantee delivery by a given date. It would also have
been a good idea to in advance check the availability of parts while being in the process of deciding what
to use. Because we were working under a very specific deadline, availability would have been an important
factor in deciding what parts to use. Finding a second source for all components is also a very good idea
(although it should not be counted upon, the group originally had two sources for the SRAM, and none of
them would have been able to deliver on time).
7.2.2 Tutorials
The only exercises in the course were tutorials for the tools we were going to use. While some of the tutorials
gave a good introduction, others were either unavailable due to license problems, or not consistent with the
actual installed software (e.g. the logic analyzer tutorial). This resulted in some people not finishing the
tutorials on time.
7.2.3 Software development
A lot of time was wasted in the AVR group before any real, working code was produced. A number of
factors contributed to this. First, the group decided to use the IAR compiler. This turned out to be difficult,
as they also wanted to use the Ethernut code, which was only written to support the AVR-GCC and ICCAVR
compiler. Rewriting the code was briefly attempted before switching to the GCC compiler.
Writing the software without being able to test it also proved to be difficult. When dealing with low-level
hardware programming there are a lot of issues to deal with. I.e., getting the cell phone and X10 transceiver
to communicate with the microcontroller was almost taken for granted when we planned the project. Some
of the code that worked perfectly on the STK300 and STK501 development boards did not work "out of the
box" on the BBox board.
7.3. The product
81
7.2.4 Teaching
We would generally have preferred more teaching. It is OK to make the project environment realistic. However, in a real project one would be working together with experienced people from whom to learn. In this
case, we were all freshmen. It is useful to learn how to find the information one needs on the net, but it is
very time consuming. With the limited time available, it is hard to find all the information that is needed. It
also means that we had to divide into subgroups and work separately. The result was that we did not learn
quite as much about the subjects that the others were working on.
As opposed to the previous years’ projects, the group did not have any experience in VHDL coding or PCB
design. The group members were expected to handle a lot of problems on their own. Fortunately some of the
more experienced students were available when we needed answers to difficult questions.
Difficulties, stress and lack of prior experience taken into consideration, it has been an interesting course. As
opposed to classic lecture oriented teaching, working on an actual product and being able to see results of
what you are doing is both fun and interesting. In addition, there are a lot of minor experiences made related
to both the electronics business, and working as a team. Things like, seeing that it is useful having key people
with responsibilities, such as a leader, documentation officer, and a parts/purchase officer, or experiencing
that getting that particular component is not always that easy.
7.2.5 Learning
We have learned quite a bit from this project. None of us were experienced with hardware design before
starting on this project, however we all had interest in the field. We have been taken through the various
steps in the hardware development process. We all gained basic knowledge of the fields of PCB, FPGA and
microcontroller design. As a result of our group structure, each has also acquired a deeper knowledge of their
assigned task. Now we have what it takes to participate and contribute in hardware discussions.
7.3 The product
A picture of the completed BBox is shown in figure 7.1 (page 82).
The box is complete with both the exterior and the interior. In front the logo, the button and the LEDs are
visible. The back contains all connectors and ethernet status LEDs.
The BBox provides all the features Bjarne expect, although not all of them are fully implemented. Going
through the requirements specification we can point out the requirements that are and are not fully met:
• The box is not yet able to share an Internet connection. The hardware allows for it, but the software
is not complete. Therefore many of the network features are not met. However, we have succeeded
in sending and receiving IP packets so we know that the design works. More time would have been
needed for implementing the high-level network software. The web interface, for instance, has not
been prioritized. Following from this, the load meter and mail alert lights are not completed.
• The home control requirements are more or less met. The software is tested alone and is found to be
working, but it is not fully integrated with the rest of the system.
• The non-functional requirements are met, with the exception of the backup power source. As the box
is designed for people having little experience with computers, there is only one button on the front
panel. The rest of the user interface is to be implemented as a simple web page. The design is definitely
appealing. Estimated power consumption during normal operation is less than 4W.
82
Discussion
Figure 7.1: The BBox
• Testability requirements are met. The design is very testable.
Although the lack of fully implemented software, the BBox represents itself in a respectable manner. Given
more time, a complete network software could have been developed.
7.4 Conclusion
All group members have worked together on this project, even though we have been divided into subgroups.
No one has been allowed to tag along without contributing to the work being done and no major disagreements have arised. All in all, we feel that we form a strong group.
We have experienced that a hardware development project is a time-consuming process. Many factors may
slow down development, and there are critical events of which further project progress is dependent. We have
learned about several fields, getting not only technical, but also valuable project experience.
As the BBox is starting to become reality, we look back and think about what we expected when we were
given the assignment of building a broadband router (with extra features) from scratch. Not all of us believed
that we would get as far as we did, but today the BBox is looking quite good, and much of the functionality
is implemented.
"Ambitious, yet realistic!" has been our unofficial motto. This means we have tried to make a working
product with lots of cool functionality and still keeping it at a realistic level. Focus has been on completing
the box, not adding too much extra features. Therefore some ideas were abandoned even though they would
have increased the gadget factor. This, combined with hours of hard work has resulted in a product we are
proud of. As far as we are concerned, the BBox is a success.
Chapter 8
Acknowledgements
83
84
Acknowledgements
85
We would like to give thanks to:
• Our instructor Karstein Kristiansen, Morten Hartmann and Gunnar Tufte for support and follow-up.
• The DM2001 project group for providing us with their PCB design files. We saved quite some work
because we could use some of their footprints and parts of their schematics.
• Asbjørn Djupdal and Geir Svihus for hints and tips on Foundation.
• Gaute Myklebust from Atmel for providing us with the newest Atmel development kits and microcontrollers.
• ’Hatling A/S’ for providing us with the plexiglas sample.
• ’Verkstedteknisk’ in Perleporten for carving the plexiglas BBox logo.
86
Acknowledgements
Chapter 9
Bibliography
87
88
Bibliography
89
[1] Econ Oscillator DS1075M
Data Sheet: http://pdfserv.maxim-ic.com/arpdf/DS1075.pdf
Application Note: http://pdfserv.maxim-ic.com/arpdf/AppNotes/app205.pdf
[2] Microcontroller Atmel ATMega128
Data Sheet: http://www.atmel.com/atmel/acrobat/doc2467.pdf
Application Notes: http://www.avrfreaks.net/Devices/devices.php?action=1&;devid=54
[3] Octal D-type latch with 3-state output Philips 74ALS573B
http://www.elfa.se/images/lw_hires/B12214_1.GIF
[4] Triple 2-channel multiplexer Philips 74HC4053
http://www.elfa.se/images/lw_hires/B12311_1.GIF
[5] Philips LED Shift-Register HEF4894BP
[6] Field Programmable Gate Array Xilinx XC4044XLA
Data Sheet: http://direct.xilinx.com/bvdocs/publications/4000.pdf
Product Specification: http://www.xilinx.com/partinfo/ds015.pdf
[7] JTAG Multilinx
http://www.xilinx.com/xapp/xapp168.pdf
[8] SPROM XC1701L
Data Sheet: http://umwnt1.physics.lsa.umich.edu/alpha/images/xc1701.pdf
[9] Cirrus Ethernet Controller CS8900A
Data Sheet: http://www.cirrus.com/pubs/cs8900a-4.pdf?DocumentID=532
Application Note: http://www.cirrus.com/pubs/An83-3.pdf?DocumentID=635
[10] Cypress Dual Port SRAM CY7C009
Data Sheet: http://www.cypress.com/products/datasheet.cfm?partnum=CY7C008-15AC
Application Notes: http://www.cypress.com/support/app_note_family.cfm?fname=Dual%2DPorts&;
[11] Adjustable Voltage Regulator CS-5203A
Data Sheet: http://www.elfa.se/pdf/73/730/07307705.pdf
[12] RS-232 Level Shifter Maxim MAX202CPE
Data Sheet: http://www.elfa.se/pdf/73/730/07302359.pdf
[13] Manual Reference AT Command Set (GSM 07.07, GSM 07.05, Siemens specific commands) for the
SIEMENS Mobile Phones S35i,C35i, M35i
http://www.my-siemens.com/external/tt/hq/mw/hd/hd/p35/s35i_c35i_m35i_atc_commandset_
[14] SMS messages and the PDU format
http://www.dreamfabric.com/sms/
[15] NutOS
90
http://www.ethernut.de/en/software.html
[16] Perry, Douglas: VHDL, 3rd Edition, McGraw-Hill, 1998.
[17] Elprint
http://www.elprint.no
Bibliography