Introduction to Microcomputer Systems - Final Project | CPSC 462, Study Guides, Projects, Research of Microcomputers

Download Introduction to Microcomputer Systems - Final Project | CPSC 462 and more Study Guides, Projects, Research Microcomputers in PDF only on Docsity!

Microcomputer Systems

Final Project

Spring 2005

CPSC 462

Paul Krizak

William Wolfe

Table of Contents

Abstract

The EB63 ARM-based embedded platform offers a wide range of opportunities for

automated robots. Our CPSC 462 final project was to automate the behavior of an R/C

car by integrating multiple system components:

 Relay system for controlling the steering and drive systems, signaled by general I/

O pins on the EB

 USB host controller for connecting high-speed peripherals to the EB

 USB webcam for gathering visual data

 Ultrasonic sensors for reactive sensing of obstacles and distance calculations

The goal of our project was to fully automate the RC car by having it drive on its own

until it located an obstacle. The car would then stop, position itself an optimal distance

from the obstacle, then activate the USB controller and camera. The camera would snap

a picture of the obstacle. This picture would then be interpreted to see if it was a “road

sign” indicating the car’s next move (right turn, left turn, or stop). This next move would

be executed and the car would continue until locating another obstacle.

In the end, we successfully built a connection of relay systems that could interface the

EB63 to the drive and steering systems of the R/C car. The USB controller was also

completed, however the webcam driver, appropriate algorithms for manipulating the

downloaded images, and the ultrasonic sensor controls were not completed due to time

constraints.

Project Plan

This project required a great deal of planning. There were a large number of

components, some of which had dependencies. For example, the USB controller required

a newer version of MMLite, which in turn required that the ultrasonic sensor code be

completely redone to work with the new version.

Task Division

To best utilize our available resources, we decided to split the project into two major

components, then combine these components at the end into the finished product. Since

the car could be programmed to drive itself without the webcam or USB controller, we

decided on the following task breakdown:

 Paul

o USB Controller

o Webcam driver

o Image recognition code

 Will

o Research existing car implementation

o Upgrade ultrasonic sensor code to MMLite v.

o Add steering and driving functionality to existing car code

o Add distance calculation and distance finding capabilities to existing car code

Schedule

With so many tasks to complete, it was important to have a reference timetable so that we

did not get bogged down on menial details of one particular aspect of the project. We

developed a Gantt chart during the first week of the project to help us budget our time.

This chart is in Appendix A.

Team Communication

In addition to meeting once a week in our scheduled lab time, the team communicated via

a blog on Paul’s server. Progress updates and project minutiae could be posted to quickly

share information between team members.

Component Selection

It was important with this project that we leverage the past work of as many people as

possible. With that in mind, we chose the following components for the various parts of

the project:

R/C car

We decided to build on the existing R/C car platform developed by TJ Wittliff, Rene

Franco, and Brinson Holliday for their CPSC 462 Fall 2004 final project. The “RTB car”

had working forward-looking ultrasonic sensors and a rudimentary drive control already

in place. Its original objective was to drive by the original remote control, and to be able

USB Controller

The Cypress SL811HS USB host controller was chosen due to a prototype driver already

being integrated into the v.96 version of MMLite. The chip is also ideally suited for use

with the EB63, as it uses a similar reading and writing protocol as the EB63’s EBI bus.

Additionally, the SL811HS requires a minimal amount of support hardware to function

properly.

Photo 3 - The SL811HS host controller

Webcam

The original webcam we purchased was a Dynex WXWC100 from Best Buy. Being a

“generic” camera, we expected it to have a “generic” chip inside that would be easy to

locate either a datasheet or an existing open-source driver. It was eventually discovered

that the Dynex camera’s sensor was a PixArt PAC207BCA-32, which has no known

available documentation or code. This camera was abandoned in favor of a Logitech

QuickCam Express that Paul had at home. This camera is based on a STV0600 ASIC

USB controller connected via an I2C bus to a HDCS1000 CMOS image sensor. This

camera has many open-source driver implementations and both the ASIC and the

HDCS1000 sensor are fairly well understood.

Computation Platform

The Atmel EB63 platform was chosen due to its existing use on the RTB car, an existing

code base in the MMLite v.96 operating system for the USB controller, and general ease

of use for manipulating general I/O pins.

Photo 4 - The EB

Power Distribution

There are many different voltages to supply in our project:

Component Voltage

EB63 7.5v

SL811HS 3.3v

RLYF71C05 5v

USB devices 5v

Steering motor 5v

Drive motor 9v

Ultrasonic sensors 3.3v

The R/C car as we received it had a voltage splitting system that took 9v as input from

either the onboard batteries or an external source, and then provided a 7.5v signal for the

EB63 (using a voltage divider) and a 3.3v signal for the TTL components (using a

voltage regulator).

This arrangement was augmented by two voltage regulators on the USB/steering

protoboard. The board takes 9v input (either external or from the onboard battery pack)

and provides 5v for the steering and drive relays as well as the USB devices. There is

also a 3.3v regulator for the TTL ICs associated with the USB controller.

If your board boots successfully with the E7 strap in the STD position, then you’re ready

to build a v.96 MMLite tree and flash that version of the OS to the STD side of the chip.

Create the MMLite v.96 tree

First, make a copy of the entire \inv directory called \inv30. You will be needing the

inv30 directory frequently, so don’t destroy it in any way!!

Open up the mmlite-0.96.zip file that you downloaded from the MMLite homepage.

Extract the conf, doc, include, samples, src, and tests directories, as well as the files

files.xml, makefile, mkall.bat, mkdoc.bat and mkdep.bat into the \inv directory. Say

“yes” to overwrite all files.

Next make a copy of the \inv\tools\tools\arm_gnu directory in \inv\tools; i.e. you

should have a populated \inv\tools\arm_gnu after the copy.

Edit the mkall.bat file: REMark out pretty much the entire file except for the first two

nmake commands. The first one builds the i386 version, then second builds the ARM

version. Everything else except the :out label can safely be deleted.

At this time you’ll also need to modify the eb63big.c file to make it start the srfs driver

at boot-up. Simply erase the current contents of /inv/conf/package/eb63big.c and

replace it with the following code:

/* Copyright (c) Microsoft Corporation. All rights reserved. / #include #include #include #include extern PIUNKNOWN Db161CobMain(void); extern PIUNKNOWN HostfsCobMain(void); extern PIUNKNOWN SerplexCobMain(void); const struct PRECOB ThePreCobTable[] = { {_T("eb63usart.cob"), SerialCobMain }, {_T("sernet.cob"), SerNetCobMain }, {_T("serplex.cob"), SerplexCobMain }, {_T("hostfs.cob"), HostfsCobMain }, {_T("db161.cob"), Db161CobMain }, BASIC_NET_COBS BASIC_SOAP_COBS PRIVATE_SOAP_COBS {0,0} }; / Select root "fs" file system */ PINAMESPACE BoardInitRomFs(void); PINAMESPACE BoardInitHostFs(void); EXTERN_C void ConfigureDrivers( PIMODULE pModule, _TCHAR *ConfigurationFileName, BOOL LoadDllDrivers ); PRIVATE SCODE Configure(_TCHAR Name) { PIMODULE pCurMod; GetCurrentModule(&pCurMod); ConfigureDrivers(pCurMod, Name, FALSE ); if (pCurMod) pCurMod->v->Release(pCurMod); return S_OK; } PINAMESPACE BoardInitFileSystem(void) { PINAMESPACE ns; printf("Initializing the srfs driver...\n"); Configure("srfs"); / Use RomFs with eb63big: it's a flashed standalone image / printf("Attempting to mount the RomFS...\n"); ns = BoardInitRomFs(); if (!ns) { / not there / printf("RomFS didn't load...using HostFS instead.\n"); ns = BoardInitHostFs(); / use hostfs instead */ } printf("File system initialized.\n\n"); return ns; }

done.

CheckSum=x1ee9966 (32414054). > eb_flash.exe -std 1000000 fs/eb63fs.flp 180000 {Did you remember this one?} E7 == STD assumed Checking FLASH @ ManufacturerId: x1f DeviceId: xc Flash was recognized, type AT49BV1604/ None of the sectors are locked. Did you make sure that Strap E7 is in the STD position? y FLASHing file fs/eb63fs.flp at offset 180000. Erasing sector 32 [offset x180000] ...done. ################################################################ Erasing sector 33 [offset x190000] ...done. ################################################################ Erasing sector 34 [offset x1a0000] ...done. ################################################################ Erasing sector 35 [offset x1b0000] ...done. ################################################################ Erasing sector 36 [offset x1c0000] ...done.

done.

CheckSum=xfff124 (16773412). >

Finally, shut down serplexd and rename \inv to \inv30, and rename \inv96 to \inv.

Move strap E7 back to the USER position and fire up serplexd from \inv. If MMLite

v.96 flashed properly, you should get a message that looks like this:

Console Thread ... Initializing the srfs driver... Attempting to mount the RomFS... File system initialized. Done initializing. >

Congratulations! You’ve installed MMLite v.96!

USB Controller

Hardware Design - Breadboard

Before even thinking about doing image recognition, the SL811HS chip had to be

connected to the EBI bus of the EB63. The schematics for the USB controller were

based on both the reference design in the SL811HS datasheet and work done by Nathan

Lynch. See the “as-built” schematics in Appendix B.

For initial testing, the entire USB controller was prototyped on a breadboard. The 28-pin

PLCC socket was wire-wrapped to a 28-pin SIP header corresponding to the pin

numbers. It was later discovered that the connections from the base of the socket to the

interior pins did not follow the expected pattern on the exterior pins. Thus the

breadboard prototype never functioned properly. However, many important things were

learned from the breadboard phase.

Photo 5 - The PLCC28 socket being wire-wrapped to the breadboard

Photo 6 - The completed breadboard

Hardware Design - Protoboard

When it was discovered that wire wrapping on the PLCC28 socket was incorrect, it was

decided to go ahead and solder the protoboard together. This process took about 8 hours

in the lab.

Photo 7 - The completed protoboard – bottom

Photo 8 - The completed protoboard – top

The only significant change from the reference design originally done on the breadboard

and the one that actually got implemented on the protoboard was the clock circuit. It was

determined soon after completing the protoboard that the 12Mhz clock described in the

SL811HS datasheet was wholly inadequate for even low-speed USB transfers. The

circuit based on the 48Mhz crystal was installed instead and works fine. The inductor

required for the 48Mhz circuit is located on the back of the protoboard; it is a surface-

mount device.

There are two DIP switches on the board. These are for switching the two voltage

regulators on and off. Switch #1 controls the 9v input to the 5v regulator, so switching it

off effectively turns off the entire board, since the 3.3v regulator is driven from the 5v

regulator. Switch #2 controls the 5v input to the 3.3v regulator. There are LEDs in front

of both regulators that indicate which rails are powered. Both LEDs must be lit for the

USB system to work properly.

Interconnect with the EB

Connecting the USB controller to the EB63 requires 15 wires. 14 of these wires are

collected in a ribbon cable that splits into two block connectors. The 8-pin block is the 8-

bit data bus. Pin 1 goes on P1B23. The larger block connector houses the address line

and the various control lines. Pin 1 goes on P1B1. There is one longer wire that “breaks

away” from the ribbon cable. This is the interrupt request line, which must be connected

to P3A4. Finally, a ground wire must be connected between the EB63 and the USB

controller. In the final product, this ground connection would have been made via the

steering control headers, but during debugging and development, pin P3A1 can be

connected to the SL811HS pin 27 (the 28-pin SIP header on the protoboard corresponds

to the 28 pins of the SL811HS, with pin 1 on the left, pin 28 to the right).

Photo 9 - EBI bus connections: note pin one indicators on block connectors

Test programs

MMLite v.96 comes with a driver for the SL811HS as well a suite of drivers ranging

from keyboards and mice to hubs and USB storage devices. The sources for these drivers

are located in \inv\src\drivers\serial\usb\master. If you updated the MMLite v.

sources as described in the sections above, you should be able to run the following tests

to verify that the USB controller is functioning properly.

Testing RAM (starting at byte 16) RamTest PASS {This is what you’re looking for} Mem[000]: 0 10 4 1 0 0 31 20 0 4 20 9 12 60 20 0 Mem[016]: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f Mem[032]: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f Mem[048]: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f Mem[064]: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f Mem[080]: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f Mem[096]: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f Mem[112]: 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 80 Mem[128]: 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f Mem[144]: 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f Mem[160]: a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af Mem[176]: b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf Mem[192]: c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf Mem[208]: d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df Mem[224]: e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef Mem[240]: f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe 0 --Counters: { ^-- This dump should count in order starting at reg. 16} Flips = - Interrupts = 0 StartOfFrame = 0 Insertions = 0 A-done = 0 Loopy = 0 >

If the RAM test passes, this indicates that the control, data, and address lines are

connected and working properly, and that the EB63 is programmed with the appropriate

timing parameters on chip select #2.

Complete functionality test

The next test is to start a chip monitoring thread and verify that USB transactions work as

expected.

> sl811test.exe P {Starts an ISR that listens for USB transactions} Current RAM contents: Mem[000]: 0 10 4 1 0 0 31 20 0 4 20 9 12 60 20 0 Mem[016]: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f Mem[032]: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f Mem[048]: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f Mem[064]: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f Mem[080]: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f Mem[096]: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f Mem[112]: 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f Mem[128]: 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f Mem[144]: 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f Mem[160]: a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af Mem[176]: b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf Mem[192]: c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf Mem[208]: d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df Mem[224]: e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef Mem[240]: f0 f1 f2 f3 f4 f5 f6 f8 f8 f9 fa fb fc fe fe ff 0-th dump repetition failed (at byte 96) {Again, ignore} Reg 0: 0 10 4 1 0 0 31 20 0 4 20 9 12 60 20 0 Reg 16: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f Reg 32: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f

Reg 48: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f Reg 64: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f Reg 80: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f Reg 96: 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 Reg112: 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f 81 Reg128: 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f 90 91 Reg144: 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e a0 a1 a Reg160: a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af b0 b1 b Reg176: b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be c0 c1 c2 c Reg192: c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf d0 d1 d2 d Reg208: d4 d5 d6 d7 d8 d9 da db dc dd de e0 e2 e3 e4 e Reg224: e6 e7 e8 e9 ea eb ec ed ee ef f1 f2 f3 f4 f5 f Reg240: f7 f8 f9 fa fb fc fd ff 10 4 1 0 0 31 20 0 1-th dump repetition failed (at byte 64) {Ignore…} 2-th dump repetition failed (at byte 64) 3-th dump repetition failed (at byte 64) 4-th dump repetition failed (at byte 32) 5-th dump repetition failed (at byte 32) 6-th dump repetition failed (at byte 32) 7-th dump repetition failed (at byte 96) 8-th dump repetition failed (at byte 32) 9-th dump repetition failed (at byte 64) HCR_A 0 = HBA_A 10 = b HBL_A 4 = b STATUS_A 1 = ACK TC_A 0 = CTRL1 0 = INTEN 31 = DONE_A SOF Insert SAR 20 = b HCR_B 0 = HBA_B 4 = b HBL_B 20 = b STATUS_B 9 = ACK Sequence TC_B 12 = b1 b ISTATUS 60 = Insert Detect REV 20 = b SOF_HI 0 = Starting interactive testing (with real ISR) Type '?' for help. Command [?|c|d|D|r|i|p|s|z|1|2|e]: ISTATUS 40 = Detect No device or no power Device removal detected {Plug in a Logitech USB optical mouse now} ISTATUS 0 = Low speed device connected Device attachment detected DeviceDescriptor:12 1 10 1 0 0 0 8 6d 4 c c0 10 21 1 2 0 1……… Client address is now x1 (was x0) ConfigDescriptor: 9 2 22 0 1 1 0 a0 32 9 4 0 0 1 3 1 2 0……… ReportDescLength: 52 MaxPower: 100 mA SetConfig. ReportDescriptor: 5 1 9 2 a1 1 9 1 a1 0 5 9 19 1 29 3 15 0 8 95 3 18 81 6 c0 c ReportLengths: InSize 23 OutSize 0 Feature 0 [0]GetString: 4 3 9 4 1 {Press “1” to get the DeviceDescriptor string} DeviceDescriptor:12 1 10 1 0 0 0 8 6d 4 c c0 10 21 1 2 0 1