Design and implementation of a local area network utilizing Intel 310/80286 systems

Rochester Institute of Technology

RIT Scholar Works

Theses

Thesis/Dissertation Collections

11-11-1987

Design and implementation of a local area network

utilizing Intel 310/80286 systems

James Leach

Follow this and additional works at:

http://scholarworks.rit.edu/theses

Recommended Citation

Abstract

Thegoal ofthis work wasto provide the foundation for a course in _networking

by

developing

the hardware and software for a token _ring Local Area Network (LAN). _Any

course work in networking would focus on the _emerging International Standards

Organization _(ISO) Open Systems Interconnections (OSI) model. This model provides a seven

layered structure, where each layer performs some logical aspect of the communication

process. _Thus,thesoftware developed wouldhave toprovidethe

functionality

of a multiple

layereddesign,

implying

multipletasks_{communicating}

by

_operatingsystem primitives. _Also,

asimplified designwould minimize thetime forthose studentstrying toassimilate the basic

work priorto_embarkingonthedesign oftheirown work.

Within an Intel 310system _running the iRMX _operating system, the LAN hardware

and software were developed. The package allows reliable transfer of files to the other

nodeson atoken _{ring LAN} viaaccess

by

user programs to lower layers. In addition, the user

has a reasonable interface to interact with the file system of the home node. Once the

physical configuration of the LAN is established, the software _{is self-initializing} and

self-monitoring for pathological cases. The software runs as an application task on each _node,

TABLE OF

CONTENTS

Abstract

Table ofContents

ListofTables

ListofFigures

n vi vii 1.0 Introduction 1.1 Goals 1.2 Constraints 1 1 2

2.0 Development Environment

2.1 Intel 310 System

2.1.1 8086/80286 Differences 2.1.2 8086 Alternations . 2.1.3 116Board

2.2 DevelopmentSoftware

2.2.1 iRMXV6.0

2.2.1.1 Interrupts

2.2.1.2 System Configuration Files .

2.2.1.3 System Calls

2.2.1.3.1 iRUGCiRMX interface

2.2.1.3.2 LAN System Calls 2.2.2 Languages

2.2.2.1 Intel CCompilerCC86 2.2.2.2 Intel Assembler ASM86 2.2.2.3 iRMXC/AssemblerInterface 2.2.3 Utilities 2.2.3.1 Linker 2.2.3.2 Kermit 4 4 6 9 9 11 11 11 14 14 15 16 18 18 19 21 21 21 21

3.0 iRMX Bugaboos 3.1 Hardware

3.3 File I/O

3.4 Misc

24

24

4.0 The Network Model

4.1 ISO OSI Model

4.2 Layers

25

25

29

5.0 LAN Software

5.1 Overview

5.1.1 Task

Blocking

Mechanisms

5.1.2 InterTask Communication

5.1.3 Software Organization

5.1.3.1 Files/Routines

5.1.3.2 Global Variables

5.2 Human Interface Layer Code

5.2.1

Functionality

5.2.2

Debugging

Capabilities.

5.3 Transport Layer Code

5.4 Data Link Layer .

5.4.1 Overview

5.4.1.1 data packet

5.4.1.2 free token packet

5.4.1.3 resetpacket

5.4.2 Task State Diagram.

5.4.2.1 SenderState

5.4.2.2 SintState

5.4.2.3 RintState . .

5.4.3 Task State Diagram Interaction

5.4.3.1

Sending

A File .

5.4.3.2

Receiving

A File

5.4.3.3

Repeating

A File ....

5.4.4 Software Task Communication Vs Task States

5.4.5

NodeState,

LAN Initialization And Error

Recovery

5.4.6 Data Link LayerCode

5.4.6.1 Overview

5.4.6.2

Key

Decisions ...

5.4.6.2.1 Packet

Handling

and

Routing

5.4.6.2.2 Data

Integrity

5.4.6.2.3 LAN

Resetting

72

75

75

77

77

79

79

6.0 LAN Hardware ... .81

6.1 LAN

Topology

... 81

6.2 Node Environment .81

6.2.1 80286/10 Single Board Computer 81

6.2.2 116 Board ₈₅

6.2.2.1 Programmable Peripheral Interface

(8255)

88

6.2.2.2 Resistor Packs 92

6.2.2.3 Interrupt Mask ... 93

6.2.3 Multibus I ... 93

6.3 IntraNode Hardware 93

. 6.3/1

Cabling

93

6.3.2 Patch Panel ₉₅

6.4 Software Configuration Of Hardware 98

7.0

Debugging

Techniques

7 1 Hardware/Software

Debugging

7.2 Low Level Software

Debugging

7.3 Application Software

Debugging

102

102

103

104

8.0 Conclusions 105

Appendix A

Bibliography

References

Technical Manuals

Intel iRMX Manuals

Appendix D Link and Compile Examples

Appendix E Kermit

Appendix F Source Code

Rint.c

Sint.c

Sender.c

Trans.c

Hi.c

Control.c

Dlutils.c

Cutils.c

Tutils.c

Common.h

LIST

OF TABLES

Table Description

2.1.2 Intel 310 8086/80286 Attribute Comparison

2.1.3 Intel 310 80286 I/O Port Addresses

2.1.4 Intel 310 8086 I/O Port Addresses

2.2.1 8086 Interrupt Level Utilization . .

2.2.2 80286 Interrupt Level Utilization . .

2.2.3 LAN Interrupt Utilization .

2.2.4 Cto iRMX System Call Link Libraries

2.2.5 PL/M and CData Types

2.2.6 LAN Software iRMX System Calls Used

4.1.1 OSI Model Layer

Functionality

4.2.1 LAN Layer

Functionality

5.1.1 Software TaskSource Code Files

5.1.2

Utility

Routine Source Code Files

5.1.3 Global Variables ....

5.2.1 User Commands

5.2.2

Debugging

Commands ....

5.4.1 Rint Task States ...

5.4.2 Rint Task ProcHDR Routine Decisions

6.2.1 8255 Port Addresses ....

6.2.2 1 16 Board Jumpers Removed ....

6.2.3 116 Board Jumpers Added

6.2.4 LAN

Topology

Via Patch Panel . . .

7.1.1 PSCOPE Command Effects On Waveforms

LIST

OF FIGURES

Figure Description Page

2.0 2.1 2.2 4.1 4.2 5.1.1 5.1.2 5.1.3 5.4.1 5.4.2 5.4.3 5.4.4 5.4.5 5.4.6 5.4.7 5.4.8 5.4.9 5.4.10 5.4.10a 5.4.11 5.4.11a 5.4.12 5.4.12a 5.4.13 5.4.14 6.0 6.1 6.2

Development Environment .

8086 ProcessorBoard Standard Configuration

C

Masking

Techniques

The Seven LayerOSI Model

The LAN Model . .

Software Structure

Task

Blocking

Mechanisms

Task Communication .

Data Packet Format

FreeToken Format

Reset Token Format

SenderState Diagram

SintState Diagram

RintState Diagram

File Send

File

Receiving

Task States

Repeat Packet

Send Files

File Send Task States

File Receive

File

Receiving

Task States

Packet Repeat

Repeat Packet Task States

NodeState Diagram ...

Code Task State ...

LAN

Topology

. ....

The LAN/310 Hardware

Generating

The Interrupt

Configuring

The Hardware

6.6 8255 Interconnection

Showing

Patch Panel ... 94

6.6a Patch Panel Partial Schematic 97

6.7 8255 Control Word To Configure LAN

Software

99

6.8 8255 Set Command To Enable INTRb 100

1.0 Introduction

Establishing a Local Area Network _(LAN) involves

integrating

several different

piecesofhardwareand software. The LAN ismade_upofseveral computers,ornodes, linked

by

a communications medium of some sort. Each node consists of the generic system

hardware, the _operating system, and LAN communications software. Information sent

between systems must pass through the system hardware and _operating system. _Thus, to

produce a LAN, the two pieces provided (the system hardware and _operating system) must

be understood prior to _creating the other two pieces (the communication medium and

communications software).

This thesis represents work that went _along those lines. First, in order to

understand the development environment (the two pieces provided), attempts were made

to passdata through the Intel _{iRMX operating} system and 310 system hardware. Although

iRMX _training was available, no support was purchased from Intel. _Thus, at _times,

understanding the environment became a matter of _{experimenting} until solutions were

found, if_theywere found. The discussion ofthis thesiswork mustthen begin with a look at

some oftheproblems encountered _{understanding} theenvironment. Aswill be shown, these

problemsaffectedthedesignofthetwopieces producedforthisthesiswork.

1.1 Goals

The primary goal of the thesis is to provide a basis for subsequent course work in

data communications. To that end, the design was to be straight forward to provide the

studenta basisupon which to do hisown work. The softwarestructure wasto be based on

the International Standards Organization (ISO) Open System Interconnection _(OSI) seven

layermodel,with separate software entitiesperformingeach layers'

file, allowingthe

flexibility

foreach layertoadd orremove its protocolsprior to _passing the

information to the nextlayer. Although thisthesis _{only implements}two _{layers in any}depth

(thephysical and data link layers), thestructure must be provided to

develop

extensive layer

protocols.

To communicate between systems, a physical medium for data transfer must be

developed. After the 310 system peripheral I/O board is selected, some hardware must be

built to connect the separate systems. This intersystem physical connection must be more

thanjustcabling. A feature ofthishardware isthatit allowsan _easymethod to reconfigure

theLAN_topologywithout

disassembling

the310systems.

A personal goal was to utilize Intel's C as the _{primary language.} Intel provides

several compilers (PLVM, C, Fortran, and _such), but uses the Intel _{proprietary language} PL/M

to provide _programming examples (several of which don't work) in the iRMX manuals

However, it was felt that a greater number of people would be familiar with C. _Also, C

provided much more flexible use of pointerswhich were deemed essential _{for any} effective

buffermanagement.

1.2 Constraints

The LAN was to be constrained

by

Computer

Engineering

resources and some

design requirements. The resources consisted of several 310 systems, peripheral boards and

languages. The peripheralsincluded someintelligent _(iSBC544)and dumb_(iSBC534)terminal

support _boards, and the general purpose iSBC116A I/O boards. The 116 board was

finally

selected sinceitprovided one I/O chip forthe LAN _{communications,}and a second _{I/O chip}to

control satellitehardware. Thus, projectsin distributedsystems could be addressed.

A token _{ring topology} was specified. The 116 I/O board dictated an 8 bit parallel

not a requirement, it was of great interest for the software to support both the 8086 and

80286systems.

During development the vast _majority oftime was spent on a small percentage of

the work: _{simply getting} an interrupt. The Intel system _{310 iRMX operating} system proved

to be such a formidable obstacle that _{many blind} alleys were investigated before

finding

a

mechanism to solve a single problem. Due to this, a _primary requirement (for

self-preservation)wastominimize_operatingsystem interaction. Thesystemcallswere limited to

asfewiRMX_operatingsystem primitives aspossible.

A similar desire was to utilize the _{iRMX operating} system as configured

by

the

factory. _{The iRMX operating} system is designed to be configurable, with several utilities to

help

the userchangethesystem to suithimself. However, itwasfeltthatwhatlittle use the

documentationwas would bedilutedwith_anychangesto thesystem asdelivered.

Anotherdesire wasto run all LAN softwareas an applicationtask. Although speed

has dictated that more and more network software be migrated to intelligent board

firmware, It wasfelt that the _primary goal ofthe software was instruction. To that end, as

much has been left visible to the programmer as is possible. Development of firmware

seemed to be impractical due to the increased equipment needs for items such as prom

programmers,in-circuitemulators,and such. Thispackage runs as a usertask.

The overriding commentisthatiRMX and thehardware,toalarge degree,dictated

the LAN software design. While a _top down design is preferred, one must understand the

functionality

of the hardware and system utilities. The design can be based on incorrect

assumptions of these utilities. To discover those errors

during

the later stages of code

developmentcan leadto_lengthyredesigns. Thus,the LANcode developmentshould involve

2.0 Development Environment

This section of the thesis shall describe the development environment used. It is

hoped thatthisskeleton ofinformationand references can providethereader withthe tools

necessaryto

develop

a similarpieceofcode.

Figure 2.0 showseveral nodes connected

by

a ring. These nodes are the Intel 310

system, each of which supports a general purpose development environment (terminal

support, printers, user _interface, compilers, linkers, etc.). Figure 2.0 also shows a VAX and

IBM PC,whichconnectto_{any Intel 310}viaa kermit link. Kermitallowsfile transfer toeither

theVAX orIBMPC.

Each node consists of anIntel 310, witheither an 8086or80286 CPU. Although this

discussion will focuson the80286 based 310, the8086 version pertinent differencesshall be

noted. _{The operating} system, iRMX shall also be discussed, with a brief description of the

system primitives used inthecode. Lastly,thelanguageand system utilities will be discussed

The discussions herewill provide references_using abbreviations in the master index

of the standard set of Intel iRMX documentation. The manuals consist of four volumes

having

several sections(themasterindex is inV4),assummarized in thebibliography.

2.1 Intel 310 System

The Intel 310systems consists of a general purpose chassiswithaMultibus I bus. The

buscan support a variety of _boards,

including

a processor _board, memory, disk controllers,

and assorted peripheral boards. Althoughthedevelopmentsystems used includeda general

purpose system (memory, hard disk,

floppy

drive), the discussion will focus onthe processor

Intel System 3 10

IntelSystem 310

Intel System 310

ASCII Printer

Intel Svstem310

VAX/VMS Environment IBM PC

legend

KermitRS232

Link

There are two configurations of the 310 systems which have either 8086 or 80286

processor board. _{The only differences between} these two systems that will be noted are

those thatpertainto the LANsoftware.

The 310 iRMX real time _operating system is the user development environment.

Theoperatingsystem can be configured andis intended fortheusertomold andincorporate

into a product. Both the system hardware and iRMX software have been _relatively

unchanged fromthe

factory

configuration.

2.1.1 8086/80286Differences

The two different 310 systems have either 8086 or 80286 processor boards. From

the LAN perspective, the processor boards have some significantdifferences and _{similarities,}

as summarizedintable2.1.2 below.

Attribute 8086 80286

Console Device 8251 8274

standard numberofterminal

ports

1 2

iLBXBus no yes

Programmed Interrupt Controller

8259A 8259A

Table 2.1.2 Intel 310 8086/80286 Attribute Comparison

The differentconsole devices means_copingwith differentdata port addresses, and

transmit data _ready (txrdy) and receive _{data ready (rxrdy)} bit definitions in the status port.

Thenumber of standardterminal portsshall becomesignificantwhen _{addressing kermit.}

the backplane, which is now used

by

the iLBX bus _HOWEVER, the 116board places + 12

volts on the TTLcircuitry, whichdestroysthe iLBXbus bufferson theCPU board. The iLBX bus

usesthe lowerthree slotsofthe 80286 310system only. Extensive searches have uncovered

nodocumentationonthisfact.

The 80286 systems have two serial _ports, both driven

by

the Multi-Protocol Serial

Controller_(MPSC),8274. Althoughthesecond portcan be usedtosupport asecond user, the

Department of Computer _Engineering 80286 310's have .5 Mbytes of memory. The user

needs .25 Mbytes(if you wantto enter super user mode), and iRMXwants about

.2 Mbytes.

This leaves around 50 Kbytes for the second user, which is not enough to do much of

anything. Thus, the second serial port can not be used for another terminal unless the

memoryisincreased.

The port addresses used

by

the LAN software are summarized for each system in

PortAddress

(hex)

device

function

OOCO Master PIC Status port, ICW1

00C2 Master PIC interrupt mask

00D8 Serial I/O

(MPSC)

data

port, channel A

OODA Serial I/O

(MPSC)

data port, channel B

OODC Serial I/O

(MPSC)

status _port, channel A

OODE Serial I/O

(MPSC)

status_port, channel B

Table 2.1.3 Intel 310 80286 I/O Port Addresses

Port Address

(hex)

device function

OOCO Master PIC Status _port, ICW1

00C2 MasterPIC interrupt mask

00D8 Serial I/O

(8251)

data port

OODA Serial I/O

(8251)

status port

2.1.2 8086 Alterations

In thediscussion on_interrupts itshall be noted that the8086systems utilize master

interrupt level 4 with the printer. Unfortunately, this interrupt level was also used

by

the

LAN software. The8086 processor board

factory jumpering

(see figure2.1) must be altered

to accommodate the LAN software. The alterations are remove 132/157 and add 157/162

Much ofthedetail ofthis

drawing

will be more evident afterthe hardwaresection hasbeen

reviewed. The detail of figure 2.1 has been included because no drawings of the 8086

processor boards are available in the Department of Computer Engineering. This

drawing

wasgenerated

by

hand fromtheboard itself

Toallow the 8086310's to be used for boththe LAN and printing, a manual switch

could be incorporated inthechassis.

2.1.3 116 Board

The Multibus I peripheral board selected for the communications was the iSBC

108A/116A combination _memory and I/O expansion board. Most of the board

functionality

(16Kbytes RAM, 32Kbytes ROM, 16Kbytes PROM and serial I/O port) will not be addressed.

Instead,the focuswill be on the LAN specific portionsofthe _board, the 48 parallel I/O lines

controlled

by

two Intel 8255A Programmable Peripheral Interface _(PPI) devices. The 310

systems will communicate via a single 8255 PPI. Some hardware shall be developed to

NTO 41

NT1 42

INT2

INT3

IIMT4

INT5

IIMT6

INT7 39

40

37

38

35

36

Multibus

250

-e-132

-Q

63 60

8279A

(PIC)

Figure 2.1 8086 Processor Board Standard Configuration

Parallel

Printer

Port

7438

(U19)

o ₁₈

51 9 8

2.2 Development Software

2.2.1 iRMXV6.0

This section will not attempt to explain _iRMX, but instead focus on the many

undocumented factsneeded to

develop

the LAN code. The information will focus_primarily

on _interrupts, and the C /

Assembly

Language interface to those interrupts. Additional

topics,suchasthesystem_calls, languagesand utilities shall alsobeaddressed.

Intel providesa wealth of documentation on both the _{iRMX operating} system and

the 310 systems. _{Unfortunately,} there was little or _nothing on how to bind the interrupt

software withthehardware. The approached usedwasto look attheschematics and tryand

second guess howthingsworked. Tocomplicate_matters, mostexamples are in PL/M, which

uses special _utilityroutines not available in C. The results ofthis trial and error procedure is

summarizedhere.

2.2.1.1 Interrupts

The Intel documentationon interruptsseems _pretty good. The examplesin nucleus

manual _(NU) are all in PL/M, where an interrupt handler routine is identified

by

an

INTERRUPT inthe proceduredefinition. Notethat the INTERRUPT tellsthe PL/M compiler to

generate a

jump

toassembly languageroutines atthe

beginning

and end oftheactual code.

These assembly language routinessave and restorethe processor state. In_C,thiswill have to

bedone

by

hand.

Thesingle board computershavetwo PICsthatcan betiered with masterand slave

interrupt controllers, but the system comes configured from the

factory

with a single PIC

installed. Thus,all referencestoslave interruptscanbe ignored.

unused interrupt levels must be located Tables 2 2 1 and 2.2.2 show the interrupt level

usageforthe8086and80286 310_{systems, respectively}

Since the 544 boards were not used for the LAN, interrupt level 3 was used.

Interrupt level 4 was taken arbitrarily. Since all _{early development} wasdone on the 80286

310 systems, itwas _{only discovered} much later that the 8086 310 printer usage of interrupt

level 4conflictedwiththe LAN software. The fix forthe printer portisnoted insection 2. 1 2,

anddisplayed in figure2.1.

8259A

pin

interrupt level

(encoded)

hex

description

IRO 8 NPX

IR1 18 system debugger

IR2 28 system clock

(8253

timer

0)

IR3 38 544communications controller

IR4 48 on board line printer

IR5 58 21 5G Winchester

hard drive

controller

IR6 68 system consol USART receiver

(RxReady)

IR7 78 system consol USARTtransmit

(TxReady)

8259A pin

interrupt level

(encoded)

hex

description

IRO 8 counter Oof the 8254 PIT

IR1 18 interrupt button on the

front

panel

IR2 28 unused

IR3 38 544 communications controller

IR4 48 unused

IR5 58 21 5GWinchester

hard drive

controller

IR6 68 310 serial channel A and B

IR7 78 interruptfromslave PIC

Table 2.2.2 80286 Interrupt Level Utilization

It is

interesting

to describe the interrupt vectors this can be _{found in any} 286

hardware reference manual. There are 256 possible interrupt vectors, each

having

a four

byte address. The vectors reside in memory locations 0 to 03FF hex. In table 8-4 (nucleus

manual NU 8-19) note that master interrupts 3 and 4 correspond to the decimal interrupt

table entries 59 and _60, respectively Thus, to locate the hard addresses for master level _4,

compute4*

60-1, or239. This information issummarized intable2 2.3.

master

interrupt level

encoded

interrupt level

interrupt

vector

table

address

(dec)

address

(hex)

sender 3 38H 59 235 EC

2.2.1.2 System Configuration Files

To understand a problem with task _creation, the _{iRMX priority} system must be

addressed. Atask can _only create another task with a _priority the same or higherthan the

original task. _However,a Cmain task iscreated

by

thesystem with a defaultpriority. Itwill

be noted that in the project's code, this original main task is the _{lowest priority} human

interface task. _However, the main task mustspawn other tasks that cannot be of a lower

priority, and yet must be. Also, there _may be a desire tocreate a task to preempt even the

interrupttasks(suchas atimer task). Toaddressthis problem,and toprovide a mechanismto

circumvent the _{iRMX priority} system, a patch to the _operating system was added. _By

manipulating certain iRMX system configuration _files, task priorities can be quite flexible.

SeeappendixCforthedetails.

It should be noted that this patch allows the user to create tasks which will run

beforethe iRMXsystem utilities. Unpredictableresults can occur when thisis done.

2.2.1.3 System Calls

The iRMXdocumentation provides ample system call descriptions,which thissection

will introduce. Of added interest isthe fact that C does not support the iRMX system call

interface, which shall be provided

by

some additional utilities. These utilities were provided

by

iRUG (iRMX UserGroup),and will bediscussedfirst.

As mentioned earlier, iRMX isa layered and configurable _operating system. What

that means isthat there isa _kernel, or nucleus as iRMX calls it. The layers are built on the

nucleus,likeconcentric circles aroundthenucleus. Theupperlayers depend uponsome or all

ofthe layersbelow. Thedocumentation for iRMX is built aroundthose _layers, withseparate

sections on the nucleus, basic I/O system _(BIOS), extended I/O system

(EIOS),

application

In order to utilize _any system call from a particular _layer, a

library

file must be

linkedwiththe Cobjectroutine. Thesefilesaresummarized intable_2.2.4,below.

layername iRMX

library

C

library

nucleus rcifl.lib rpifUib

BIOS icifl.lib ipifl lib

EIOS ecifl.lib epifl.lib

human interface hcifl.lib hpifl.lib

application loader Icifl.lib Ipifl. lib

Table 2.2.4 C Libraries To Access iRMX System Calls

2.2.1.3.1 iRUG C iRMXInterface

Standard iRMX does not provide a system call interface for C. The interface

provided

by

iRUG is arranged _{similarly to} the standard iRMX _{file for any} layer, as shown in

table2.2.4. To usea particularlayer'ssystemcall, theappropriate

library

mustbe linked with

theusercode, ForaCroutine, boththe iRMXand C

library

files mustbelinked.

The standard iRMX documentation can be used to understand system calls from C.

However,all examples and argumentinformationare provided from thePL/M pointof view.

By

understanding the corresponding C and PL/M data types (see table 2.2.5, below), this

documentation becomesquite readable. The information discussion ofthe system callswill

PL/M Data Type C Data Type

token unsigned int

pointer char *

word unsigned int

byte

char

string

string

Table 2.2.5 PL/M and C Data Types

2.2.1.3.2 LANSystemCalls

The LAN software uses a subset of the available iRMX system calls.The iRMX

documentation can be referenced for a detailed discussion of how each system call works.

This section summarizes the calls used in table 2.2 6 All calls are in the nucleus with the

category iRMX call

tasks rq$create$task

rq$get$task$tokens

rq$delete$job

task _{priority rq$get$priority}

rq$set$priority

interrupts rq$set$interrupt rq$signal$interrupt rq$exit$interrupt rq$wait$interrupt rq$enable

time _rq$sleep

mailboxes rq$create$mailbox rq$send$message rq$receive$message

exceptions rq$set$exception$handler rq$get$exception$handler

file I/O rq$s$create$file rq$s$attach$file rq$delete$connection

rq$s$open

rq$s$close

rq$s$read$move rq$s$write$move

2.2.2 Languages

Intel C and 8086 _{assembly language} were used to

develop

the LAN code. The

assembly languagewas straightforward, but this C compiler is not_totally standard. What is

of more interest is the interfaces between C, ASM86 and iRMX. Since the LAN code is

primarily C,getting the iRMXsystem callsfor interrupts proved to be a lotoftrial and error.

Also, the C _calling conventions must be understood to make calls to _{assembly language}

routines.

Other than low level _I/O, two assembly language routines are necessary. A C

interrupt handler is not possible because the processor state can not be saved with C

statements. _Thus,the interrupt _actuallyvectorsto_{assembly language} routineswhich _simply

savetheprocessorstate, call a Croutinetodothework, and then restoretheprocessor state.

2.2.2.1 IntelCCompiler CC86

Although _{reasonably good,} be forewarned that this version of C has some

"wrinkles"

thatcan causedifficulties. The onefound isshown in figure2.2. NotethatAwill

A) if((MASK&data1) = = data2)

do something

B) temp = MASKSdata

if

(temp

= = _data2)

do something

figure2.2 C

Masking

Techniques

The C compiler appends an underscore to each C symbol mentioned in the code.

Thus, thevariabledatawill be thesymbol tableas data All interaction between_assembly

languageand C routines must

keep

thisstraight. A C routine called interrupt$handler must

be called from _assembly code as interrupt$handler This _{becomes necessary} when the

assemblylanguageinterruptroutines calltheCroutinethatdoes thework.

The C compiler manual (iC-86 Compiler User's Guide, order number _122085-002,

1984) outlinestherequirementstogenerate objectcodefor linking. An exampleof a submit

filetocompileCsourceisshown inappendix C.

2.2.2.2 Intel ASM86_AssemblyLanguage

The 8086assemblerwas used. Perhapsworth _commentingon isthe fact that theC

and assemblylanguage routines mustbe madeknowntoeach other. The _{assembly language}

requires an externto import C routine addresses, and a public toexport _{assembly language}

routine addresses. From the file autils.a86, the

following

assembly language code is taken

name proc name

extern rcvrinthandler :far

public rcvrinthandler _;

rcvrinthandler proc far

. . . saveprocessor state . .

call rcvrinthandler

. . restore processorstate . . .

iret

rcvrinthandler _endp

The

following

Ccode interacts with the _{assembly language} routine. Note that the

rq$enter$interrupt call placesthe address ofthe actual _{assembly language interrupt} routine

intotheinterrupt vector.

main()

{

extern rcvr$int$handler _;

. . . initialize. . .

rq$set$interrupt(,,rcvr$int$handler ,,);

forever

loop

}

rcvr$int$handler()

{

. . perform I/O. . .

}

NotethattheCcompilerplaces a single underscore after all symbol names. _Thus,

assembly language symbols must have the underscored there since the assembler does not

place underscores on _{assembly language} symbols. For example, the assembly language

symbol rcvrinthandler pertains to the C rcvr$int$handler, which is a C routine. The

assembly language symbol rcvrinthandler (two underscores) is the procedure

rcvr$int$handler whichCusesinthe extern_statement,and therq$set$interrupt call. The C

2.2.3.3 Assembler/iRMX Interface

The example inthe abovesection also points out howto bind the hard interrupt to

C routine via the _{assembly language} routine. The rq$set$interrupt call _{actually fills} the

interrupt vector with the address ofthe C symbol rcvr$int$handler , orassembly language

symbol

rcvrinthandler_

_

(Caddsanother ). Then, when thehard interrupt_happens, the

CPU vectors to the _{assembly language} routine. That _{assembly language} routine saves the

processor state and calls the C routine. When the C routine ends, the _{assembly language}

routine restorestheprocessorstateand doesa return from interrupt.

2.2.3 Utilities

2.2.3.1 Linker LINK86

The LINK86 linker manual can be found in the utilities manual (iAPX 86,88 _Family

Utilities User's Guide, Order Number 121616-004, 1982). The iRMX submit file used to link

theLAN softwaceisshowninappendix D

2.2.3.2 Kermit

The Department of Computer _Engineering facilities included the 310 systems, IBM

PC's and access to the RIT VAX Cluster. Each of these facilities have compatible version of

kermit,which will allow_transferringofASCIIfiles. Thus, developmentof sourcecodecan be

done in a variety of environments so as to allow the 310's to be used

by

others or the

software development to be done elsewhere. A detailed description of a kermit session is

3.0 iRMXBugaboos

Thissectionchronicles problemswhich werenot solved. One _very

frustrating

aspect

ofa lotofthese problems isthatthere isno way to _verifythe proposed explanations. After

exhausting all possible approaches to these problems, the conclusions that were reached

reflected the _{only remaining} alternative. It is _very possible that another explanation exists

forthese problems, and that the people involved_simply failed to thinkofit. However, these

problems were _{eventuallysimply}worked around.

3.1 Hardware

Theslots intheIntel 80286are not all identical. The bottom threeslots havean iLBX

bus incorporated forfast data transfer. However, the physical slot for the iLBX bus is also

used

by

the 1 16 board for 12volts. Since the iLBX isTTL, a _{buffer chip} on the 80286 single

boardcomputeris destroyed (seesection2.1.1).

The 1 16board edge connectoris designed to goto a _DB50,which servesastheback

panel connectionto the outside world. The DB50 pin _{numbering differs from}the 1 16board

pinouts shown on the schematic. There is a close correspondence in that a cable can be

crimpedfroma 50pin edge connectortoa DB50suchthat the differenceinthe _{numbering is}

only one apart. For instance, pin 1 on the board edge is pin 2 on the DB50. Pin 2 on the

board edge is pin 1 on the DB50. Although this seems like a small _{point, many} cables were

ruinedbecauseof_{Intel's confusing} pin assignment.

Dataisalwayscirculatingon theLAN. EvenaLAN _{sitting in} an idlestate(i.e. no one

issending)requiresthat afreetoken be circulated onthering. Notall ofthe packet need be

received before knowing what to do with that packet. _Thus, the correct approach is to

retransmit each portion ofthepacket received asitarrives. Thus, a particular packetcan be

design all nodes are _continually

handling

data. _However, ifthat data is handled totally at

interrupt level, experience shows that the _{low priority} tasks do not geta chance to run. A

solutionto theproblem lies ineach node

delaying

priorto_{retransmitting}a packetor portion

there of. This

delay

(via an _rq$sleep) allows the lower _priority tasks a chance to function.

Obviously, this serious performance problem can be overcome in a production system

by

building

an_{independent,concurrently executingring} interface.

3.2 Interrupts

Interruptscan not_{be disabled for any}period of time. The system clock is interrupt

driven, and requires that interrupt to update system time counters. System calls such as

rq$sleepsimply never wake_upsince allinterrupthasbeen disabled.

The _operatingsystem queues _up hard interrupts. It wasthought that these queued

interrupts could be manipulated with the rq$disable and rq$enable system calls, since the

calls affecteda single interrupt level. Although any taskcan perform an _{rq$disable, only} the

interrupttaskcan dotherq$enable

Queued interruptposed another problem. Aninterrupthandler makes a system call

rq$exit$interrupt or rq$signal$interrupt, which dequeues that interrupt as far as iRMX is

concerned. If a node is

doing

simultaneous sends and receives, iRMX is queueing and

dequeueing

on two interrupt levels at the same time. It appeared that the system calls to

dequeueonone interrupt level affectstheother _level, sinceinterrupts appeared to get lost.

That is, to dequeue on one interrupt level somehow dequeued the other level also. The

interrupt driven communication would _simply stop, with no reason that could be

determined. After extensive experimentation, no other explanation could be isolated.

By

Any attemptsto talk

directly

to the system Programmable Interrupt Controller_(PIC)

are unsuccessful. _{By sending} the correct data to the appropriate register, interrupts can be

disabled and enabled temporarily. _Eventually, iRMX returns the PIC to its original state.

Apparently there is a _copy ofthe mask registersomewhere in _iRMX, and that_{copy is simply}

restored. Interrupts disabled

by

_writing to the PIC would _{simply become} reenabled all

by

themselves.

3.3 File I/O

C file I/O can not be used for

binary

data. For some unknown reason, C routines

placea carriage return and line feed intothefile when told towrite a carriagereturn. _Every

Croutine wastried: _{fputc, putchar, putw, fputs, fwrite,}and fprintf.

Apparently, onlya Cmainroutine cancreatefilesthataresharable. Ifacreated task

creates its own _file, when anothertask tries to open that _file, the system crashes. _Industry

sourceshavetold methat thejobmustbe an "I/OJob"

Repeated attemptsto_tryand create

an I/Ojob failed. Noteinthedesignthatas a result ofthis,the maintaskcreatesthe chatfile.

3.4 Miscellaneous

The readeris reminded that printf isqueue system I/O. In the case ofthissoftware,

which managed to die with frequent regularity,

debugging

printf's will not appear at the

screen. Arealtime iPrintf(whichwritesto the USART/MPSCdevice) wasdeveloped and must

beusedforall realtimework.

Along that line, when the system _crashes, iRMXsendsa last gasp error code to the

user, via_something analogousto a printf. Ifthe programmerislucky, afewcharactersfrom

the error code appear. This tells you the system detected a failure, and if you are _lucky,

4.0 The Network Model

4.1 ISO OSI Model

The International Standards Organization (ISO) Open System Interconnection (OSI)

model subdivides the _networking task into seven _layers, each of which perform individual

functions. An in depth discussion of this topic can be found in [TAN81], which will be

summarized

briefly

herein.

Figure 4.1 depicts the OSI model. In all node to node communications, there is a

sender, 0ton repeaters and areceiver node. Althoughthereis a logical connection fromthe

sender application (user _interface) layer to the _{corresponding} receiver application (user

interface) layer, it can be seenthat the actual data travelsa more complex route. The data

must filter down through all layers of the sender node, and travel through some layers of

each (if any) repeater node _{before arriving} atthe receiver node. Each of these layers have

specifictasks to perform toinsurethatthedataarrivesintact.

A very brief summary ofthe network layer tasksare shown in table 4.1. Thistable

should give an intuitive feel for the tasks each layer performs. With this background, the

general organization oftheLAN software canbe examined

Assumethe user starts witha file to be sent. Each subsequentlayerwill coordinate

its task

by

_{adding data} to that file. When the file arrives at the receiver _node, the

corresponding layerlooksatthat datatofigure out whatto do _{This piggy}

backing

of layer

information to the actual data is a protocol. For _instance, a transmitted file can have the

destinationfilenamewithintheprotocol data.

In transmission, each layer adds its protocol asthe data is sent to the next lower

Sender Node Repeater Node Receiver Node

application layer

presentation layer

sessionlayer

transportlayer

networklayer

data linklayer

physical layer

presentation

layer

transportlayer

networklayer

data linklayer

physicallayer

application

layer

presentation

layer

transportlayer

networklayer

datalinklayer

physical layer

simply as data. Thus, when the file arrives at the transport _layer, there is application,

presentation,and sessionlayerprotocol information attached toit.

The file arrives atthe transport _layer, where it must be reduced to a manageable

size (thereisalmost guaranteedto bea transmission failure in a fivemegabytefile transfer).

The file is broken _upintoequal sized chunksofdata. A packet isformed when the chunk of

data iscombinedwith protocol information. Thisprotocol informationcan include awealth

of information, such as source node address, destination node address, cyclic _redundancy

check_(crc)or_checksum,andsuch.

The packet is sent to the network _layer, which handles intra-node routing. Each

node transmits the packet via the data link _layer, which provides an error free packet

transmissionmedium.

The packet arrives at a repeater node. This node notices the destination address

and uses algorithms todetermine a route. The packet is then sent to the next node on that

route. When the packet

finally

arrives atthedestination node, the packetisaccepted

by

the

transport layer _There, the multiple packets are reassembled intothe original _file, which is

passed _{up layer} to layer. _During that process, each layer removesthe protocol information

layer task _comments

application

defined

by

user LAN software user

interface

presentation data transformations

medium transformations

i.e. textcompression

i.e.

incompatible

terminals

session provides reliable processto process

communication

transport provides reliable

host

to

host

communications

hides

all network

details

from upperlayers

network _routing

deals

in packets

data

link provides reliable transmission medium

dealsin packets

packet

integrity

via checksum or crc

physical actual data transfer medium

deals in

bit

stream

4.2 LAN Model

The LAN developed for the thesis is

loosely

based on the _{OSI model,} as shown in

figure4.2. The application, presentation and session layers have beencombined intoa single

human interface layer. Sincethe hardware configuration ofthe LAN isa token ring, routing

isa minimal issue (thepacket always goesto the next node on_{the ring),} sothe network layer

hasbeenincorporated intothedata link layer The data linkand physical layersareintact.

In this LAN software,thefeaturesof each layerareoutlinedin table4.2.1 below

layer task comments

application userinterface mustknow LAN logical

node names

transport providesLAN interface

to user

hidesall network details

from upper layers

converts LAN logical

node namesto LAN

addresses

data

link provides reliable transmission medium

deals in packets

routes packetto next

node

packet

integrity

via "crc"

physical actual data transfer medium

deals in

bit

stream

Sender Node _{Repeater Node Receiver Node}

human

interface layer

transportlayer

data link layer

physicallayer

human

interface layer

transportlayer

data link layer

physical layer

human

interfacelayer

data linklayer

physical layer

5.0 LAN SoftwareDesign

Thissection will discussthe LAN software. In figure4.2, ofthe four_layers, three are

software: the humaninterface,transport and data link. The physical layerwill beaddressed

inanother section.

5.1 Overview

The LAN software allowsthe usertosend filesand messagestoanother _node, while

determining thestate ofthe local filesystem. However, beneath this surface the LAN must

administer itself not _only to start _{up correctly,} but to detect failures and correct them if

possible.

Failing

_that,to_notifythe userof_anycatastrophicfailurethatdisablesthe LAN.

To describe the workings of this or _any system, the parts must first be defined

before understanding how those parts interact. This overview shall describe these parts

(software tasks), and the mechanisms that allow the parts to interact (i.e. mailboxes,

software interrupts). _By

interacting

it ismeant howtasksstartand _stop each_other, and how

theycommunicate

The LAN model (figure4.2) providesthe foundation forthesoftwaredesign. Figure

5.1.1 showsthe threesoftware layers fleshed out withthetaskscontained in eachlayer. The

mechanical aspects ofthese tasks (file names, variablesand such) will also be presented so

thatthereader can explorethecodeasthediscussion develops

Itshouldbe notedthatwhile the transportand human interface layersare minimal,

the data link layer isimplemented in some depth. The data link layer is designed as a state

machine,where all ofthe tasksmustbeaware ofthestate oftheothertasks. Thestateflags

for each task are kept in global integer variables. Thus, any tasks can determine and/or

>> <D -Q E o> _Q) 03 a c 0) c (0 .c * t-3 c O k_ 4-V a "O 3 k_ k_ c 0) <1> </> + c _V

J

a

r

-a c 01

;

i

1 ₀₎ Q> >. >. ₀₃ 03 _l .*-k_ >*_ o o Q. 3 01 03

5* _<1)k_ 03

_1

>> 01 01 c _J

>> o C (0

03 o

r w ₀₃

o k.

Ol

u

i/> </l n 01 01k- Q.

v/1 a. <

5.1.1 Task

Blocking

Mechanisms

Figure 5.1.2 shows the four iRMX system primitives used to block the tasks:

rq$wait$interrupt, rq$receive$message, gets, and rq$sleep. The first three are blocked

waiting for an event: an _{interrupt signaling inter-node I/O,} a mailbox message _signaling

inter-task I/O and gets _signaling user _input, respectively. The _last, rq$sleep, is blocked on

time. The control taskwakes_upeverysooften to monitorthe node. The interrupt handlers

arethe traditional interruptroutines which are vectored to upon interrupt.

Task priority isused to determine which runs first. As in mostsystems, the highest

priority (or in iRMX, the lowest numeric _priority) runs first. In

looking

at figure 5.1.2, the

individual task prioritiescan be seen in theupper right corner ofthe task balloon. With the

exceptionoftheinterrupt handlers,the control task runs atthe highestpriority. Blocked on

atimer, control wakes up periodically to monitorthe state ofthe node. Control _simplygoes

backtosleep unlesstheLAN needs_{resetting (timeout,} resettoken, and such). The _remaining

taskswakeupwhen data isreceived.

The handlers run when an interrupt is received, _{signaling input} or output

being

received

by

the next node. These _{handlers simply} make the rq$signal$interrupt call,

notifying their respective interrupt tasks(blocked on a _{rq$wait$interrupt)} that an interrupt

hasbeen received andthe I/Omustbe attendedto.

Thus, the control task blocks on _time, and the handlers on interrupt which signal

intra-node communication. The human interfacetask blocksongets, a C _utilitywhichwaits

foruserinput. The remainingtasksare blocked waitingfor communicationfrom the human

'

\

Ul 00 1/1 ^

f

^

(N .* j=

rsi kJ u

rsi *-> Q. 3 k_ 0) -t-c

k_ \fy _CT>

o> *->

-a 'fa k^

c 5

03 <a^

.c CT

c

^

k.

>

f

\

f

^

V "

/

c rsi rsi rsi rsi 'k.

7

OI Ol 03 iy> 0) E Ol > 3 O-c Oi _I u 01 k. O" I k_ 01 D t-j 01

r

a

/

rsi rsi

A

ro rsi

\

00 ro Q. 0> 03 k.

J

IE

7

3 k-k_ 0) 03 k^ 01

r

^

c t/* o

^A 01 rsi

w _> (N

03 5 01 v* 0> o" i/> k. 01

o

^

ifO

Q.

01 Ol

0} c <&

.c c k. 0) <-> c

V

J

OI V"

J

"5 J cr

-o _oc

J

5.1.2 InterTaskCommunication

As shown above, external inputs to the interrupt handlers orthe human interface

start the system. Information must flow from tasks to task via the iRMX primitives

mentioned as the

blocking

mechanism: rq$wait$interrupt and mailboxes. Figure 5.1.3

showsthemultipletasks thatdoeithera rq$signal$interruptor mailboxsend towake _upthe

blocked tasks.

Theinterrupt handlersarevectoredtovia a _{hard interrupt signaling}data I/O These

handlers then wake _uptheir_{corresponding interrupt} tasks via a rq$signal$interrupt system

call prior to _{going back} to sleep. _Thus, when the data I/O is signaled, the interrupt tasks

awaketodotheactual read or write. In thismannerinterrupttaskssint and rinttakecare of

the physical data_reading and writing.

Itis importantthateachtaskknowswhattodowhenan inputarrives Inthecase of

the mailbox, the receiving task goes

by

the return mailbox token to determine what course

of action to ta^ke. When an rq$signal$interrupt wakes up an interrupt task from a

rq$wait$interrupt, thatinterrupttask knowswhatistobe done

by

various state flags in the

software. Themajor reason forthesenderportion

being

two tasks, sintand sender, isthat a

single task would have to manage both the mailbox and the rq$signal$interrupt from the

trans taskand interrupthandler, respectively.

It will be shown how control resets the LAN. To accomplish this, control does an

rq$signal$interruptto thehandlerswhichinturn passtheresetdowntothe nextlowertask.

In this mannera reset could filter down through all ofthe tasks. However, trans and hi are

not informed since _only the data link layer need provide this dynamic self correction

5.1.3 Software Organization

Figure 5.1.1 showsthe task structure thatwill most _simplify the discussion of how

the LAN functions. _However, one must be able to locate the code that performs these

functions. This section will provide a road _map to enable the reader to locate sections of

code

by

providing fileand routine names.

Secondly, the issue of how the LAN software functions hinges on certain global

variablesthat describe the system. These variables will be listed and their functions

briefly

outlined.

5.1.3.1 Files

The LAN software filesare made _upofC and a small number of_{assembly language}

routines. Inaddition to the tasks infigure 5.1.1,thereare _utilityfileswhich providea

library

of routines. Each task in figure 5.1.1 has a source code _file, as summarized in table 5 1.1.

Eachtask_maycall

library

routinestobe found inotherfiles.

Task File

Name Routine Name Description

rint.c rcvr$int$handler rint

receiver interrupthandler

receiver interrupttask

sint.c sender$int$handler sint

sender interrupthandler

senderinterrupttask

sender.c sender sendertask

control.c control background control task

trans.c trans transportlayertask

hi.c main human interface

task,

also c main

The

library

of routinesis summarized in table 5.1.2 For the most _part, the human interface and transportsubroutines are in cutils.c. The data link subroutines are in dlutils.c.

All

debugging

and _testing subroutines are in tutils.c. The low level _assembly language

Utility

File

Name Routine Name Description

dlutils.c

data

link

layer

_utility routines

docrc

computes

"crc"

CreateFreeToken CreateResetPacket CreatePacket

InitHardware initializes LAN h/w

(PIC, 8255,

etc.)

ProcResetToken processes resettoken

ProcHDR ProcRecEOT ProcRepeatEOT ProcDelEOT

cutils.c human interface/transport layer

utiltityroutines

GetSegment gets 16bitsegment register value

DetermineEnvironment 8086or80286system

"

CreateResources mailboxes, tokens

CreateTasks

InitExceptionStructures createslocal exception handler

structurefor inline error

handling

LanDir user "dir" command GetChatFile user "chat" command

GetArg

isolatesargumentfromcommand

line

ParseCommand Parse command line

DisplayFile displaysan ASCII file

WriteFile writestext intoan ASCII

file

iPrintf doesreal time print

tutils.c iPutbyte iPrintPacket iPrintPacketHDR iPrintResetPacket iPrintFreePacket iPrintDataPacket

debugging

utility routines- _all

display

real time

autils.a86 assemblerlow level routines

rcvrinthandler actual interruptroutines

senderinthandTer writestoconsol USART/MPSC poll

ConsolOutput_

ready

bit

readsfrom

hard

address

5.1.3.2 Global Variables

There are several types of global variables. These include task tokens, mailbox

tokens, task state variables, and certain hardware information. Also, there are quite a few

debug

flags used to drive the debugging. These global variables are defined in the main

routine, hi.c.

First, every iRMX entityhasatoken, or unique 16bit number, which identifiesthat

entity. The token value is used

by

iRMX in system _calls, error codes and debuggers. The

token identifiesthe tasks and mailboxes. These iRMX tokens should not be confused with

theLANtokensofthe token _{ring network; they} are_{entirely different} entities.

The collection ofthe task statevariablesare used todefine the state ofthe system.

The data linklayer is defined as a state machinewhich functionsbased on thestate variable

values. The discussionsofthedatalink revolve aroundtheinteractionofthevariables.

The hardware information includes the different system console port USART or

MPSCforthe 8086or80286, respectively. Both theportaddressesand thestatusregisterare

different, and must be resolved at _powerup before _any intelligent I/Ocan take place Also,

the transmit _ready and receiveready bitsare _different,sothe masksto isolatethese bits are

set.

System wide _debugging flags are used to enable and disable

displaying

of _any

informationthe user wishestosee in real time. RintTiK issetto zero_everytime the receiver

interrupttaskwakesup, soshould RintTik exceed some maximumtime the node realizesthe

networkis_{probably down.} Debug variables_{FreeTokenDelay}and timeoutallow _slowing and

speedinguptheLANsoftwaresoitcan beviewed ata _veryslowpace

by

the user,if desired.

There are inputand output packet buffers. The software uses the pointers inhead

and outheadtolocatethe packets within the buffers, allowing dynamic packet utilization.

Miscellaneous items includethe node, packet senderand packet receiver addresses.

All tasks will set a single bit in ResetACKto acknowledgethe task has returned to an initial

state. When all taskshave doneso,the controltask knowsthenode isup and running.

type global name description

Task Token RintToken receiver interrupttask token SintToken senderinterrupttask token

SenderToken

sendertask token

TransToken transportlayertask token HiToken

human

interface task token ControlToken background control task token

MailboxToken RintMbox SintMbox SenderMbox TransMbox

HiMbox TimerMbox

individual task mailboxes

State Variable RintState individual data linktaskstate

SintState variables

SenderState NodeState

Hardware Data costat consol status port address

codata consol data port address

txrdy

consol transmit _ready

bit

mask

(status

port)

rxrdy consol receive _{ready bit}mask (status port)

Debug

Flags ShowProtocol various

binary debug

flags

_vary ShowPackets

debugging

outputto screen ShowState

GoodCRC

FreeTokenDelay

delay

before

_relaying

free

token timeout time until timeout

declared

Time RintTik time countersetto zero each time

packet is received

Packet Pointers outp pointer intooutput packet

outhead pointerto head of output packet

inp

pointer into inputpacket

inhead pointerto head of inputpacket

Miscellaneous NodeAddress address of node SourceAddress

file

sender address DestAddress

file

receiveraddress

ResetAck eachtasksacknowledges reset

by

setting a single bit

5.2 Human Interface Layer

5.2.1 _{Functionality}

The LAN software provides two types of capabilities to the user: internode

(between nodes) and intranode (within a single node). Intranode refers to the user

interaction withthe system on whichhe/she isworking. _{This includes items}such as_getting a

directory,and_typinga particularfile

Internode refers to

interacting

with another _node, such as _sending a file there.

Basically, intranode is handled

by

the human interface while internode requires all of the

layers. Theeffects oftheinternode commandswill betracedthrough thetransportand data

link layers in the subsequent sections. _However, for now the commands will be addressed

fromtheuserpoint ofview,assummarized intable5.2. 1

command type description example

:

dir intra showfiles in a

directory

dir

dir/user/world/mydir

type intra

display

ASCII

file

to

console

type filename

type /user/filename

help

intra displayson line

help

screen

exit intra terminatesLAN software

copy inter copies

file

to another

node(which gives

default

file

name)

copy

filename

[to]

:nodename:

copy /user/filename

[to]

:nodename:

chat inter usercreates message

dispalysat

Notethatintable 5.2. 1[ ] indicatesoptional,and intheiRMXtradition :: indicatesa

device.

The _{dir, type,}

help

and exit commands seem _relatively self-explanatory. On the

surface, copy and chatseem _equallystraight forward. However, the implementation ofthe

mechanism_enabling thesecommands represents a significantportion ofthedata link layer.

The copycommand allows _{sending any}ASCII file in any

directory

to another node.

Once at thedestination node, the file must go into a default

directory

under a default file

name. _{Once there,} the file contents will be displayed on the screen. The destination node

user canalso examine thefileviatheuser typecommand.

The chatcommand is_slightlydifferentinthat theusercomposestheASCII fileatthe

screen. That ASCII file is automatically sent to the destination node where the file is

displayed_similarlyto thecopyfile.

5.2.2 _{Debugging Capability}

The debugging code wasincorporated intothe LAN software _during development.

However,

by

creating userdefined _binaryswitchtosuppress or allow

debugging

information

toappearatthe screen, developmenttimewas reduced enormously. Thiscode has been left

intact so as to

help

anyone who should wish to use the LAN software as a base for

development.

There aretwo basicdebugging commands: set and show. Show allows

displaying

packets, protocol and/or state information while the LAN runs. The set command allows

defining

theFreePacketDelay,timeoutorcrcgood/bad flag.

The various test utilities in tutils.c allow view the packets

during

debugging. In

addition, certain LAN state variables can be displayed. The ShowState and ShowProtocol

Toview _{any information} real _time, the usermustslow the data transmission down

to be viewed.

Setting

the timeout or _{FreePacketDelay} accomplishes that. The timeout

determines how

long

the node waits until

declaring

the LAN has failed since data has not

arrived inacertainamountoftime. The_{FreePacketDelay}determines how

long

the node will

hold afreetoken _{before relaying it. Thus,} each node on the LAN must set the timeout value

quite high to _stop the LAN from resetting. Once that is _done, the

FreeTokenDelay

is

increased toallow theusertoreadtheinformation

being

displayedatthe screen.

Thetimeoutnumber isin units of1/10of a second. Thisis determined

by

thecontrol

task _calling rq$sleep(TIK,&status), where TIK is defined in common.h as 10. Laborious

searches in the Intel documentation will reveal that the _rq$sleep argument TIK has units of

10milliseconds.

The _{FreeTokenDelay} is used _similarly

by

rint.c to

delay

before

doing

_any packet

output. The rq$sleep(FreeTokenDelay,&status)call ismadetoallowthelower_{priority hi}and

controltasks a little time to run. However,

by

letting

the user redefine this _delay, the LAN

can be slowed down to allow _viewing of the packet and protocol information

FreeTokenDelayis_originallysetto4 (milliseconds).

To summarize the time issues for debugging, first, the timeout must be reset to

around 10seconds (100units), and then the

delay

toaround 2 seconds(200 units). _Thus, the

datathatappears atthe userscreen will remain 2*

nseconds(wherethereare n nodes).

command

argument(if

any) description

show packets

display

all packets

show protocol

display

protocol information

show state

display

state information

show all same as show_packets, protocol and

state

show none

display

no

debug

information

show

display

set of all

debug

variables

settimeout n * 10 msec settime until node timesout

set

delay

n * 1 msec set

delay

before _any packet issentto

next node

set crc good

bad

normal situtation

forces all packetsto

be

sentwith a

bad data

integrity

check

Table 5.2.2

Debugging

Commands

5.3 Transport Layer

As mentioned earlier, the transport layer provides a reliable host to host link, and

hides all details of the LAN from the human interface layer. First, the reliable link involves the correct _handling of files moving to and from other nodes. _{This routing} of files is the transport tasksprimary function. Secondly,

filtering

all LAN specificdetailsfrom the human interface includes itemssuch asconverting the human interface logical node namesto hard

addresses used

by

the lower layers.

As implemented in this LAN, the _primary task of trans is to serve as a message

A message from the hi task include the token of a file which contains the ASCII

command line input

by

the user. Hi _{has already} parsed the command line for accuracy, so

trans need _onlyvalidatethatthedestination node logical nameexists. Ifitexists, the logical

name isconvertedtoa hard address, and a mailbox messagetransmitted tothe sendertask.

If thenodedoesnotexist, the useris informed and the transaction isterminated.

Amessagefrom rintindicatesa file has been received. Thatfile isthendisplayed. In

the pathological case that the node is

being

reset, trans acknowledges the reset and goes

5.4 Data Link LayerState Machine

The LANsoftware performsthreefunctions: send, receive or_relaypacket. First, the

formatof those packetswill be defined. With those formatsasa background, the software

will be examined from different viewpoints: high level state diagrams, software task

diagrams and code. These formats will be related to each other, as the explanation moves

froma high level totheactual code. Lastly, the LAN initialization and error _recoverywill be

addressed.

5.4.1 Overview

There aretwo typesof packets: userand _ringcontrol. The user packets are used for

data transfer, while the _ring control packets are used to administer the LAN. The user

packets consist ofthefree and datapackets. The _ringprotocol packetisthereset packet.

5.4.1.1 Data Packet

The data packet format isshown in figure 5.4.1. The reserved characters _{SOH, STX,}

ETX and EOT are used

by

the rint interrupt task to drive some action. Note that these

reserved characters are FF, FE, FDand FC(hexidecimal) respectively Since onlyASCII filesare

transferred,there isnoconflictbetween dataand reserver characters. Thisis due to the fact

thatASCII characters all have the high data bit 0 while the reservered characters have the

high bitas1.

The SOH drivesrinttostartreceivinga packet. _Anydata received priortoaSOHwill

bediscarded. All data received aftertheSOH is buffered. The STX tells rinttheentire header

has been received, and that routining decisions can be made. Based on the source and

SOH control

byte

source

address

dest

address

STX

data

CRCH CRCL ETX TR /TR EOT

FF FE 124bytes FD FC

User Packet

TokenType

0 Free

1 _Busy

Last Packet

0 No 1 Yes

unused

/ACK FF

/NAK FE

/ACK FF

/NAK FE

The ETX signals that the previoustwo words contain thedata

integrity

check code

The EOT signals the end of packet transmission. Since the LAN code buffers the entire

packet, theEOTsignalstherinttask tostarttheappropriateactionswiththepacket.

The packetis of fixed length, as defined in a C structure. _Thus, the code provides

symbolssuch as p->SourceAddress,which makethe code much more readable. Itshould be

noted that the pointersinhead and outhead are passed as arguments to routines which use

them a pointersto the packet structure. Lint(C'ssemantic _checking program)will show this

asanerror.

5.4.1.2 Free Token Packet

The free token packet format is shown in figure 5.4.2. This minimal packet has

enough information (SOH, STX and _EOT) to allow the rmt interrupt task to change states

correctly.

The free token circulates when the _ring is idle. Thus, when a data packet transfer

ends, a free token is placed ontothe ring. Thisfree token insures the _{ring integrity.} Ifthe

free token s