Bitmanipulatie voor een real-time kernel in Modula-2
Citation for published version (APA):Neerrijnen, van, M. L. J. (1988). Bitmanipulatie voor een real-time kernel in Modula-2. (TH Eindhoven. Afd. Werktuigbouwkunde, Vakgroep Produktietechnologie : WPB; Vol. WPA0545). Technische Universiteit Eindhoven.
Document status and date: Gepubliceerd: 01/01/1988
Document Version:
Uitgevers PDF, ook bekend als Version of Record
Please check the document version of this publication:
• A submitted manuscript is the version of the article upon submission and before peer-review. There can be important differences between the submitted version and the official published version of record. People interested in the research are advised to contact the author for the final version of the publication, or visit the DOI to the publisher's website.
• The final author version and the galley proof are versions of the publication after peer review.
• The final published version features the final layout of the paper including the volume, issue and page numbers.
Link to publication
General rights
Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain
• You may freely distribute the URL identifying the publication in the public portal.
If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, please follow below link for the End User Agreement:
www.tue.nl/taverne
Take down policy
If you believe that this document breaches copyright please contact us at:
openaccess@tue.nl
Onderzoeksopdracht:
Bitmanipulaties voor een real-time kernel in Modula-2.
Door M.L.J. van Neerrijnen WPA-rapport 545 juni 1988
SAMENVATTING
Om een machine te besturen met een computer z~Jn primitieven nodig die de communicatie tussen de computer en de machine regelen. Die primitieven zorgen voor de nodige bitmanipulaties en vormen een onderdeel van een kernel voor machinebesturing. Zij staan bij
elkaar in een programma. Dat programma moet aan twee soorten eisen voldoen: algemene eisen en specifieke eisen. Onder de algemene eisen vallen begrippen als gebruikersvriendelijkheid,
systeemonafhankelijkheid, structuur en een hoge snelheid. De specifieke eisen bepalen de inhoud van het programma. Hierbij
staan begrippen als het aansturen van enkele bits en het aansturen van meerdere bits gekoppeld met logische functies als AND en OR. Tevens moet een besturingsprogramma dat met dit pakket is gemaakt gesimuleerd en getest kunnen worden. Al deze eisen zijn
geimplementeerd in een programma geschreven in Modula-2. In
Modula-2 is vooral de keuze van procedures en functies van belang. Deze zullen de gebruiksmogelijkheden van het programma bepalen. Daarnaast speelt natuurlijk de wijze van implementatie een rol. Het geheel wordt getest op een PC met als interface een BaseBoard I/O kaart. Voer het aansturen van machines met andere systemen moet nog onderzoek worden verricht.
TECHNISCHE UNIVERSITEIT EINDHOVEN Faculteit der Werktuigbouwkunde Vakgroep WPA 24-9-1987 Onderzoekopdracht Afstudeerhoogleraar Begeleiders Onderwerp Toelichting M.L.J. van Neerrijnen Prof.dr.ir. J.E. Rooda Ir. D.A. van Beek
Het ontwikkelen van een ROSKIT module ter ondersteuning van bit manipulaties.
ROSKIT 1s een real time operating system dat wordt toegepast voor het aansturen van machines in industr1~le produktieprocessen. ROSKIT wordt herschreven in Modula-2. Rierbij wordt gebruik gemaakt van de Modula-2 faciliteiten om patallelle processen te beschrijven. In ROSKIT zijn primi-tieven aanwezig ter ondersteuning van input/output op bit niveau. Er is een sterke koppeling aanwez1g met de onderliggende hardware.
Opdracht
Maak een module in Modula-2, die abstracte datatypes definieert ten behoeve van input/output op bit niveau.
Onderzoek welke mogelijkheden voor bit operaties in deze module geboden zouden moeten worden. Implementeer en test de module.
Verslag, etc:
Ret memorandum "Aanwijzingen voor het afstuderen" is bij de secretaresse verkrijgbaar.
VOORWOORD
Dit is het verslag van een onderzoek, uitgevoerd in het kader van een onderzoeksopdracht in de vakgroep productietechnologie en -automatisering van de faculteit Werktuigbouwkunde van de Technische Universiteit Eindhoven.
Het onderzoek heeft plaatsgevonden aan de Technische Universiteit en is begeleid door prof.dr.ir. J.E. Rooda en ire D.A. van Beek. Graag wil ik hierbij bovengenoemde personen bedanken voor hun
adviezen, die ik gedurende het onderzoek heb gekregen. Tevens gaat mijn dank uit naar de studenten op het besturingslaboratorium voor de opbouwende kritieken.
Marc van Neerrijnen Eindhoven, juni 1988.
INHOUDSOPGAVE SAMENVATTING
ONDERZOEKSOPDRACHT 1
VOORWOORD 2
HOOFDSTUK 1 INLEIDING 4
HOOFDSTUK 2 HET EISENPAKKET 5
2.1 Algemene eisen 5
2.2 Specifieke eisen 6
2.3 De eisen samengevat 7
HOOFDSTUK 3 FUNCTIONELE BESCHRIJVINGEN 8
3.1 Algemene ideeen 8
3.2 Initialisatieprocedures en functies 9 3.3 Besturingsprocedures en functies 12 HOOFDSTUK 4 IMPLEMENTATIE MOGELIJKHEDEN 15
4.1 Real-time besturing 15
4.2 Overige implementaties 16
HOOFDSTUK 5 TESTFASE 17
HOOFDSTUK 6 CONCLUSIES EN AANBEVELINGEN 19
HOOFDSTUK 7 LITERATUUR 20
INHOUDSOPGAVE BIJLAGEN 21
HOOFDSTUK 1 INLEIDING
Tegenwoordig worden steeds meer computers gebruikt voor
machinebesturing. Machinebesturing kan gezien worden als het samenwerken van twee soorten processen: besturingsprocessen en te besturen processen. Een voorbeeld hiervan is een
koppeling van een computer aan een machine. De
besturingsprocessen bevinden zich binnen de computer, de te besturen processen zijn buiten de computer te vinden. Binnen de computer wordt een besturingsproces omschreven met behulp van een computertaal. Zo'n taal heeft zijn beperkingen. Een gebruiker raakt snel verstrikt in problemen van
programmatische aard, die niets met zijn besturing te maken hebben. Om die problemen te omzeilen heeft de gebruiker gereedschappen nodig die het modelleren en formaliseren van de besturing eenvoudig maken. Zo'n gereedschap heet een kernel, het vormt een kern van te gebruiken commando's.
Een deel van dat gereedschap is ook nodig als de communicatie tussen computer en machine geregeld moet worden. Deze
communicatie kan op verschillende manieren gebeuren. De
bepalende factor hierbij is de hardware, waarbij de keuze van de computer en de interface tussen computer en machine een beslissende rol speelt. Een goed gereedschap zorgt ervoor dat een verschil in hardware geen invloed heeft op het
besturingsprogramma.
Veelal wordt er als interface een parallelle I/O kaart gebruikt. Dit is een kaart waarmee acht bits (byte) of
zestien bits (word) tegelijk aangestuurd kunnen worden. Voor ieder bit in het byte/word heeft de parallelpoort een I/O lijn welke gekoppeld is aan een machine. Eventueel wordt daarbij het signaal getransformeerd van 5V naar 24V.
Het doel van dit onderzoek was het verkrijgen van idee en over en het maken van een programma, IOKIT genaamd, dat de
communicatie tussen computer en machine zou regelen. Hierbij werd uitgegaan van Modula-2 als programmeertaal, dit vanwege de overzichtelijke structuur en het gebruik van
(pseudo)parallelle processen.
In dit verslag komen allereerst de eisen aan de orde die men aan bovenstaand programma kan stellen, gevolgd door een
aantal mogelijke procedure- en functiedefinities met de bijbehorende consequenties. Daarna worden de mogelijke
implementaties besproken en tenslotte wordt het eindresultaat getest.
HOOFDSTUK 2 HET EISENPAKKET Algemene eisen
Aan de basis van ieder programma ligt een pakket eisen. Dit pakket bestaat uit twee delen: een algemeen deel en een specifiek deel. In het algemene deel staan eisen die onafhankelijk zijn van de gewenste functies van het programma.
Een van die eisen is reeds aangeduid in de inleiding: de systeemonafhankelijkheid. Er zijn verschillende computers waarop een besturingsprogramma ontworpen kan worden. Evenzo zijn er verschillende interfaces mogelijk tussen computer en machine. Iedere combinatie van computer en interface heeft zijn eigen kenmerken. Bijvoorbeeld: de BaseBoard kaart in een IBM PC werkt met steeds 8 bits, de PDP 11 echter hanteert 16 bits. Toch moet op be ide systemen hetzelfde
besturingsprogramma gebruikt kunnen worden.
Een tweede eis is de gebruikersvriendelijkheid. De gebruiker heeft daarbij een aantal bouwstenen nodig waarmee hij zijn programma kan opbouwen. Er dient een compromis gevonden te worden voor het aantal bouwstenen. Ten behoeve van de eenvoud en het overzicht dient dat aantal klein te zijn. Toch mag het aantal bouwstenen niet zo klein zijn dat de gebruiker
gelimiteerd wordt in zijn mogelijkheden.
De derde eis hangt nauw samen met de gebruikersvriende-lijkheid, namelijk het zorgen voor structuur in het gebruikersprogramma. Door een goede structuur wordt het programma overzichtelijk en eenvoudig te begrijpen. De structuur hangt behalve van de gebruiker zelf ook van de gebruikte kernel af. Een goede naamgeving van de
verschillende o~~erdelen speelt hierbij een grote rol, evenals de definities van de versch~llende functies en procedures.
De laatste eis is de snelheid. Een machinebesturing op een real-time basis moet natuurlijk snel genoeg zijn om de
verschillende operaties uit te kunnen voeren. Het veranderen van de waarde van een bit op de machine mag op z'n hoogst enkele milliseconden duren. Hier geldt dus: hoe sneller, hoe beter. Dit betekent vaak weI een vergroting van de lengte van het programma. Dit is met de huidige computers niet zo erg, hun geheugen is dermate groot dat de lengte van een programma te verwaarlozen is.
2.2 Specifieke eisen
Naast de algemene eisen moeten er ook eisen z~Jn die de inhoud van een programma bepalen. Daarvoor is het nodig om vooruit te kijken naar het gebruikersprogramma. Wat wil een gebruiker voor gereedschap hebben? Er zijn dan een aantal functies die voor bitmanipulaties vereist zijn. Deze worden hieronder behandeld. Daarnaast spelen bij de verschillende manieren van implementatie nog andere overwegingen een rol. Deze secundaire eisen worden later behandeld.
De eerste eis is het aansturen van een bit. Een machine bevat een aantal componenten die bestuurd worden door ze aan of uit te zetten. De toestand van zo'n component is te beschrijven door een bit. Een bit kan ook slechts twee waarden hebben: hoog/laag, 011.
Bij een besturingsprogramma zijn er dan twee basisfuncties te onderscheiden. In de eerste plaats moet de waarde van een bit gelezen worden. Gedacht wordt aan het uitlezen van de stand van een schakelaar of bijvoorbeeld de waarde van een sensor die kijkt of een product is gearriveerd. Tevens moet het mogelijk zijn een bit een waarde te geven. Bijvoorbeeld een lamp die aan- of uit gezet wordt, of een lopende band die gaat lopen of stopt.
Dit levert twee eisen op die aan een kernel gesteld worden. Allereerst een mogelijkheid om bits te lezen en ook een mogelijkheid om de waarde van een bit te veranderen. Omdat dit vaak voorkomt moet dit snel gebeuren. Snelheid speelt hier dus een grote rol.
Een verdere eis is de mogelijkheid tot multiple bit
operaties. De twee basisoperaties die op een bit uitgevoerd kunnen worden zijn het uitlezen en veranderen van bitwaarden. Dit is niet altijd genoeg. Vaak wil men combinaties van bits uitlezen en veranderen. Bijvoorbeeld:
Men wil weten of er van een serie van acht schakelaars er een ingedrukt is.
Door het geven van een commando, het zetten van een bit gebeuren gelijktijdig verschillende andere
dingen zonder dat het besturingsprogramma dat aan moet gegeven, zoals bijvoorbeeld het aangaan van een bijbehorende controlelampje.
In het besturingsprogramma wordt er in het eerste voorbeeld gevraagd naar de uitkomst van een AND-operatie op de waarden van twee bits. In het tweede voorbeeld krijgen twee bits op hetzelfde moment een bepaalde waarde. Geeist wordt nu van de kernel dat meerdere bits gelijktijdig veranderd kunnen worden en tevens dat het resultaat van een logische operatie op
meerdere bits gevraagd kan worden. Een logische operatie moet minstens inhouden AND en OR, maar misschien zijn er nog meer operaties nodig.
Een heel belangrijke functie is de koppeling van de computer aan zijn omgeving. Machine besturing bestaat zoals gezegd uit processen binnen de computer en processen buiten de computer. Tot zover is er aIleen gekeken naar processen binnen de
computer. De koppeling tussen computer en machine dient
echter ook in een besturingsprogramma beschreven te zijn. Als de gebruiker in zijn programma een bit een waarde geeft moet deze informatie ook doorgegeven worden aan de machine. Ook als om de waarde van een bit gevraagd wordt moet die
informatie van de machine komen. Deze in- en uitvoer dient goed gemodelleerd te worden.
Als de gebruiker zijn programma geschreven heeft wil hij het testen. Daarbij wil hij de computer in eerste instantie niet aan de machine koppelen, voor het geval dat er een fout in zijn programma zit. Hij koppelt de computer los van zijn omgeving. Hierbij wordt de invoer en/of de uitvoer door software nagebootst. Als het programma de test doorstaan heeft gaat de gebruiker de computer aan de machine koppelen. Samengevat wordt er geeist dat de koppeling van computer aan machine eenvoudig moet worden geregeld en voor zowel invoer als uitvoer instelbaar moet zijn op besturing en simulatie.
ROOFDSTUK 3
FUNCTIONELE BESCHRIJVINGEN
3.1 Algemene ideeen
Nu de eisen bekend zijn, worden de mogelijkheden bekeken om ze te implementeren in een programma. Dit gebeurt in twee fasen. In dit hoofdstuk komen de definities naar voren. Bij het vinden van de juiste formulering van de procedures en functies moet er voor gezorgd worden dat de gebruiker zoveel mogelijk bewegingsruimte krijgt. Dit levert de definitie module van IOKIT op. In het volgende hoofdstuk komen
implementatie mogelijkheden naar voren waar de gebruiker geen kijk op heeft. Deze mogelijkheden leiden tot de implementatie module van IOKIT. Maar eerst worden enkele basisideeen
bekeken. Deze komen voort uit de eisen en bepalen de ruwe vorm van een definitie module. Alles blijft nog wat vaag, er komt (nog) niets specifieks naar voren. Er worden slechts wat afspraken gemaakt die de opbouw mogelijk maken.
Allereerst wordt een abstract data type ingevoerd. Een variabele vandit type representeert een bit. De primaire functie van zo'n variabele is het bijhouden van de waarde van een bit. Daarom wordt het abstract data type een BOOLSTORE genoemd, afgeleid van BOOLEANSTORAGE. Voor de gebruiker
blijft de precieze definitie van een boolstore onbekend. Ret enige wat hem interesseert is het gebruik ervan. Hij kan met een boolstore werken alsof het een bit is. Een tweede
abstract data type is de ROBOOLSTORE, een !ead-Qnly-BOOLSTORE. De naam zegt het aI, dit is een boolstore die aIleen gelezen kan worden. De gebruiker kan de waarde niet veranderen, aIleen lezen. Waarom een roboolstore
geintroduceerd is, wordt later duidelijk gemaakt.
Voortaan is een bit een echt bit buiten de computer, dus op een I/O kaart of in de machine. Een bit binnen de computer, in de software wordt vanaf nu een boolstore of roboolstore genoemd.
Het gebruikersprogramma is in principe in twee delen te
splitsen: een initialisatiedeel en een besturingsdeel. In het initialisatiedeel worden variabelen aangemaakt en krijgen deze een beginwaarde. Dit deel wordt maar een keer doorlopen. De snelheid waarmee dit gebeurt speelt geen rol. In het echte real-time besturingsdeel des te meer. Hierin staan de
verschillende operaties die bij de besturing nodig zijn. Ook treedt hier vaak herhaling van programmadelen op.
Door de tweedeling van het gebruikersprogramma ontstaan in IOKIT ook twee soorten procedures en functies. Het
onderscheid tussen deze twee soorten wordt bepaald door hun functie en door de plaats waar ze in het gebruikersprogramma aangeroepen worden.
Een andere algemene eis is de systeemonafhankelijkheid. Het is moeilijk om een programma te schrijven dat totaal
onafhankelijk is van de te gebruiken hardware. Eigenlijk vereist iedere combinatie van hardware een aparte module. Door het groot aantal mogelijke combinaties is dit niet mogelijk. Daarom wordt dit ondervangen door het gebruik van een aantal instelmogelijkheden.
De belangrijkste instelling is het onderscheid tussen de aansturing door middel van een I/O kaart in een PC en de
aansturing van overige systemen. In het eerste geval wordt de waarde van een byte of een word direct op het adres van de I/O kaart gezet. In het tweede geval wordt een door de gebruiker zelf geschreven procedure aangeroepen, de
updateprocedure. In deze procedure bepaalt de gebruiker zelf hoe de communicatie tussen computer en machine plaatsvindt. Zo is iedere vorm van communicatie mogelijk.
Voor dit soort hardware afhankelijke procedures is een aparte module geschreven, IOKITSPC genaamd. In deze module staat behalve de updateprocedure ook bijvoorbeeld een procedure voor de initialisatie van de I/O kaart. Als een hardware combinatie gebruikt wordt waarbij de aansturing of de
initialisatie niet overeenkomt met de procedures in IOKITSPC dan kan de gebruiker zelf zijn eigen gelijknamige module schrijven of een procedure vervangen door een andere
gelijknamige procedure. Iedere hardware combinatie kan zo zijn eigen module krijgen. Zo ontstaat een bibliotheek van specifieke modules.
Behalve deze module zijn er nog meer instelmogelijkheden. Zo kan de logica per bit ingesteld worden. Deze kan positief of negatief zijn. Bij negatieve logica wordt op de uitgang een logische 0 gezet als de boolstore TRUE is en een logische 1 als de boolstore FALSE is. Bij positieve logica is dit
omgekeerd. Ook kan ingesteld worden of er op byte (8 bits) of op word (16 bits) basis gewerkt wordt.
Initialisatieprocedures en functies
IOKIT bestaat uit een aantal procedures en functies. De
precieze definities hiervan zijn belangrijk. Dit betekent dat er goed gekeken moet worden welke taken vervuld moe ten
worden, of dit door procedures of functies moet gebeuren en welke parameters daarvoor nodig zijn. Stap voor stap worden zo de verschillende eisen en dus de verschillende taken doorlopen. Dit alles resulteert dan in de definitie module van IOKIT.
Er zijn reeds twee abstracte data typen ingevoerd. De
gebruiker wil variabelen van zo'n type aan kunnen maken. Voor de boolstore gebeurt dit in de vorm van een functie. De
gebruiker kent de boolstore enkel als een type die de waarde van een boolean bewaart. Daarom is er bij het aanmaken van een boolstore maar een parameter nodig namelijk een
beginwaarde. Een functie die een nieuwe boolstore produceert ziet er als voIgt uit:
PROCEDURE NewBoolstore
Zo gauw een boolstore aangemaakt is kan er mee gewerkt
worden. Het is echter aIleen nog een boolstore, een variabele binnen in de computer. Er is nog geen verbinding met een bit buiten de computer. Deze verbinding kan in principe op drie verschillende manieren gelegd worden.
De eerste manier is direct, via het sturen van een byte of word naar een I/O kaart. Deze manier wordt voortaan aangeduid met de term "connected". De kaart wordt in de computer
aangesloten op de bus van de CPU. Er vandaan gaan de
verschillende verbindingen met de machine. Het sturen van een byte of word naar een van de adressen resulteert dus in het aansturen van de machine, het vragen van de inhoud van een van deze adressen geeft dus de waarden van acht of zestien bits.
De tweede manier is indirect. Hoe de communicatie hierbij geschied staat in een door de gebruiker geschreven procedure. Omdat de communicatie dan vaak via geheugenplaatsen of
adressen plaatsvindt wordt deze manier "virtuaIConnected"' genoemd. Ais eerste voorbeeld kan de PDP 11 computer genomen worden, waarop een programma voor de besturing van treinen loopt. De waarde van bits kan hierbij niet rechtstreeks ingelezen worden. Om de waarden van de wissels in te lezen wordt op het ene adres een waarde gezet waarna op het andere adres de waarde van de bits uitgelezen kan worden. Een tweede voorbeeld is de koppeling van twee computers aan elkaar. Dit kan gebeuren door verschillende bytes of words samen met enige extra gegevens (aangeven begin, einde, redundancy) aan elkaar te koppelen, dit geheel door een kabel naar een andere computer te sturen, die de boodschap vervolgens weer
decodeert en verwerkt.
De derde manier heet "ignoreConnect". De boolstore is dan weI gekoppeld aan een bepaald bit, maar doet daar voorlopig niets mee. Hiermee is het mogelijk om het besturingsprogramma te controleren en te simuleren voordat een machine aangestuurd wordt.
Dit alles resulteert in het volgende. Een boolstore kan op drie manieren gekoppeld zijn: connected, virtualConnected en ignoreConnect. Samen levert dit de CONNECTMODE waarin de boolstore verkeert. Om een boolstore te koppelen aan een bit zijn twee procedures beschikbaar, een voor boolstores die met mode "connect" en een voor "virtuaIConnected". Met twee
procedures kunnen er overzichtelijk zowel "connect" als
"virtual" gekoppelde boolstores gelijktijdig in het programma gebruikt worden. Beide procedures hebben een aantal
parameters gemeen. Allebei vragen ze om een te koppelen boolstore en aan welke bit die boolstore gekoppeld moet worden. Bovendien dient ook meegegeven te worden of de
boolstore voor input of voor output gegevens dienst doet en of de logica positiefof negatief is. Tevens is een
beginstand voor de connectmode nodig, waarmee ingesteld kan worden of de boolstore bij de initialisatie op
"ignoreConnect" ingesteld is of direct al op "connect" of "virtuaIConnected".
Daarnaast is voor de aansturing van een I/O kaart een extra parameter nodig die het offset adres van de poort aangeeft. Voor virtualConnected is een extra parameter van het type ADDRESS gewenst. Hiermee kan elke extra informatie meegegeven worden die nodig zou kunnen zijn in de updateprocedure van de gebruiker. Om aIle parameters in te kunnen geven worden
enkele typen gedefinieerd. Het totaal wordt: IOUNIT IOSELECT LOGIC BITINDEX
=
= = = byte, word ); in, out ); pos, neg); O•. 15 ]; PROCEDURE ConnectBsToAddress ( b o o l s t o r e BOOLSTORE logic LOGIC mode CONNECTMODE offsetbitnumber BITINDEX inOutput IOUNIT datastore ADDRESS ); PROCEDURE ConnectBsToIO ( boolstore logic mode o"ffsetbi tnumber inOutput IOaddress BOOLSTORE LOGIC CONNECTMODE BITINDEX IOUNIT CARDINAL ) ;Hierbij z~Jn de volgende beperkingen aangenomen. Een boolstore is nooit zowel aan een inputpoort als aan een outputpoort gekoppeld. Direct doorgeven van signalen is dus niet mogelijk. Ook is een boolstore nooit zowel "connected' als "virtuaIConnected".
Twee bijkomende procedures veranderen de connectmode van een respectievelijk aIle boolstores, dit zowel voor input als output gescheiden. De stand van de bits wordt op dat moment gelijk aan de waarden van de respectievelijke boolstores. Het zijn: PROCEDURE SetMode bs mode PROCEDURE SetModeAl1 ( inmode outmode BOOLSTORE CONNECTMODE CONNECTMODE CONNECTMODE ) ; ) ;
Afhankelijk van de hardware kan er op byte basis (acht bits) of op word basis (zestien bits) gewerkt worden. De default waarde is op byte basis. Dit is in te stellen door de
volgende procedure:
PROCEDURE ChangeIOword
3.4 Besturingsprocedures en functies
De twee basisoperaties op een boolstore zijn het uitlezen en veranderen van de waarde. Eigenlijk is er maar een
mogelijkheid om dit te implementeren. Andere mogelijkheden zijn of te ver gezocht of een verbastering van het volgende:
PROCEDURE Get ( boolstore PROCEDURE Put ( boolstore value BOOLSTORE BOOLEAN; BOOLSTORE BOOLEAN ) ;
Anders is het als er met meerdere boolstores tegelijk gewerkt wordt. Hierbij wil de gebruiker eigenlijk een variabel aantal parameters meesturen, afhankelijk van het aantal te
veranderen boolstores. Dit kan in Modula-2 niet. Dit probleem wordt omzeild door een array mee te sturen waar aIle
informatie in zit: MoreBs = RECORD bs value "END BOOLSTORE; BOOLEAN PROCEDURE PutMore ( putarray: MoreBs );
MoreBs staat voor meer boolstores. De gebruiker maakt eerst een array van MoreBs vol met boolstores en hun waarden.
Daarna kan deze array in PutMore gebruikt worden. Het is weI zo dat bij "connect" de boolstores per byte/word veranderd worden. Een consequentie hiervan is dat als de bits op hetzelfde byte/word aangesloten zijn ze allemaal precies gelijktijdig veranderen. Als de bits niet op hetzelfde byte/word aangesloten zijn, kunnen ze niet precies
gelijktijdig veranderd worden. Er zal een kleine periode tussen zitten.
Er zijn meer moeilijkheden als de gebruiker boolstores gaat combineren samen met een logische functie. De resulterende waarde staat in een roboolstore. Hierbij krijgt een
roboolstore een waarde afhankelijk van de waarden van meerdere andere boolstores.
Voorbeeld : lampentest : om te testen of een lamp het doet wordt de roboolstore lamp het resultaat van
twee boolstores switch en controle, verbonden door een or-functie. Als een van beide boolstores TRUE is, gaat de lamp aan. Zie ook onder.
switch
controle
_ _lOR
opdrachtWat ook mogelijk moet z~Jn is het automatisch verbinden van een roboolstore aan een andere (ro)boolstore. Hiermee krijgen verschillende roboolstores gelijktijdig een waarde
afhankelijk van de waarde van een enkele boolstore. Voorbeeld : Als een schakelaar omgezet wordt, gaat
automatisch de bijbehorende lamp aan. Door de boolstore switch te veranderen verandert
automatisch de roboolstore lamp.
Bij het eerste voorbeeld is er sprake van een koppeling van boolstore door logische functies, bij de tweede mogelijkheid van gelijke (equal) of geinverteerde (invert) boolstores. Als logische functies gebruikt gaan worden, rijst de vraag welke logische functies. In principe is elke combinatie te maken met een NOR-opdracht (een invert en een OR). Toch is het makkelijk om ook een AND opdracht te kunnen gebruiken, temeer omdat deze optie standaard in Modula-2 aanwezig is. Voorts is uit het testen gebleken dat een XOR opdracht in IOKIT eenvoudig te implementeren is, maar in het
gebruikersprogramma moeilijk(er). Nog meer functies zijn niet nodig, de functies AND, OR en XOR zijn genoeg. Samen met
equal en invert is iedere combinatie te bouwen en hebben we toch niet te veel bouwstenen.
Door het gebruik van logische functies, equal en invert ontstaat al snel een ingewikkeld schema van (ro)boolstores, temeer omdat deze met dezelfde functies gekoppeld kunnen worden tot nieuwe (ro)boolstores. Op deze wijze ontstaat een vertakte structuur (zie hiervoor ook bijlage C):
power -- powerlam motor1 motor2 <> ready down XOR r -p AND
--
OR-
I
-
busy lamp1 lamp2 lamp3 lamp4 switch1 switch2 switch3 switch4fig.2 : Een voorbeeld van een boomstructuur
Hoe zou een gebruiker nu zo'n boomstructuur op kunnen zetten? Met andere woorden : hoe zou het definitie module van IOKIT eruit moeten zien? Er zijn drie mogelijkheden die hieronder beschreven worden.
Bij de eerste mogelijkheid is er voor iedere gewenste
koppeling een aparte procedure met een vast aantal parameters en een vaste logische functie.
Voorbeeld : NewAnd4 ( boolstore1, ,boolstore4) koppelt vier boolstores met een AND functie aan elkaar tot een roboolstore. NewOr3 (boolstore1, ,boolstore3)
koppelt drie boolstores aan elkaar met een OR-functie.
Voordelen van deze methode z~Jn het overzichtelijk gebruik in het gebruikersprogramma en de eenvoud. Een groot nadeel is het aantal bouwstenen dat op deze manier nodig is. Voor
iedere combinatie is een aparte procedure nodig.
Bij de tweede mogelijkheid wordt een procedure maar een keer aangeroepen, met daarin voor iedere gewenste koppeling een variabel aantal parameters en een logische functie. Dit kan volgens hetzelfde principe als de definitie van de PutMore.
Voorbeeld : NewROBoolstore ( array of boolstores,and ) produceert een roboolstore als resultaat van de koppeling van boolstores in de array met een AND-functie.
Met deze methode kunnen alle combinaties met maar een procedure worden gemaakt. Tevens blijft het
gebruikersprogramma overzichtelijk. Een nadeel van deze
methode is het groot aantal declaraties en initialisaties van de te gebruiken variabelen.
Bij de laatste mogelijkheid wordt een procedure steeds herhaald, met daarin steeds een boolstore en een logische functie. Deze boolstore wordt bij iedere aanroep gekoppeld aan de reeds eerder gekoppelde boolstores.
Voorbeeld AddBoolstore (roboolstore boolstl and AddBoolstore ( roboolstore , boolst2 , and AddBoolstore ( roboolstore , boolst3 , or )
produceert een roboolstore waarbij eerst een nieuwe roboolstore aangemaakt wordt en vervolgens boolstorel, daarna
boolstore2 en dan boolstore3 gekoppeld worden met de bijbehorende logica.
boolstl boolst2 boolst3 AND ~ ~ AND
--
---OR roboolstorefig.3 : Koppeling met AddBoolstore Hiermee is iedere combinatie te maken en vallen de declaraties mee. Deze methode werkt echter enorm
onoverzichtelijk voor de gebruiker. Dit betekent dat fouten snel op zullen treden. Het totaal is dus gebruikersonvriende-lijk.
Alternatief twee is gekozen vanwege de goede combinatie van overzichtelijkheid en aantal mogelijkheden.
Als een gebruiker toch alternatief 1 wil hebben, kan hij zelf de benodigde procedures schrijven met behulp van de
procedures van IOKIT. Omgekeerd, procedures van alternatief 2 schrijven uitgaande van alternatief 1, kan niet.
HOOFDSTUK 4
IMPLEMENTATIE MOGELIJKHEDEN
4.1 Real-time besturing
Tijdens de real-time besturing ontvangt de computer signalen van de machine en geeft ook signalen terug. Het moment waarop de computer de input verwerkt is nog niet duidelijk.
Hetzelfde geldt ook voor de output. Dit alles gaat intern in
de software. Immers, er zijn verschillende (rolboolstores aan
in- en outputpoorten gekoppeld. De waarden van deze
(ro)boolstores moeten wijzigen als de machine een signaal
daartoe geeft (input) of als het besturingsprogramma dat eist
(output). Een voorbeeld: een bit op d~ machine verandert van
waarde. De boolstore die aan dit bit gekoppeld is, verandert
ook van waarde. Maar deze boolstore is weer verbonden met een roboolstore. Deze kan dus ook van waarde veranderen.
Tenslotte kan deze roboolstore verbonden zijn met een lamp op de machine. Ook deze lamp dient aangestuurd te worden.
Het is dus nodig dat een netwerk van boolstores, roboolstores
en poorten gecontroleerd en veranderd wordt. Een hulpmiddel
hierbij kan de interne klok zijn. Deze genereert interrupts op vaste tijdstippen en kan zo gebruikt worden om cyclische aansturing van bits mogelijk te maken. Deze timer wordt bij de eerste twee van het totaal van vier mogelijke
implementaties gebruikt.
Bij de eerste mogelijkheid worden aIle inputpoorten elk
interval gelezen. De hieraan gekoppelde boolstores worden op hun waarde gecontroleerd. Als de nieuwe waarde verschilt van de oude waarde wordt pas naar eventueel verbonden boolstores
gekeken. Op hun beurt, als die van waarde veranderen, wordt
het signaal op de eventueel bijbehorende outputpoort gezet. Deze methode is niet snel, ook is het voor de gebruiker niet duidelijk wat er precies gebeurt.
Bij de tweede mogelijkheid worden ook aIle inputpoorten gelezen, maar nu worden aIle roboolstores en aIle
outputpoorten veranderd en aangestuurd, ook al is hun waarde
niet gewijzigd. Dit is veel langzamer, maar duidelijker.
Bij bovenstaande mogelijkheden leveren of veranderen een Get opdracht respectievelijk een Put opdracht altijd de waarde
van die ene (ro)boolstore. Een Get opdracht do en niets met
andere (ro)boolstores of met de poorten. Een Put opdracht zet
de waarde van die boolstore en de waarden van eventueel hieraan gekoppelde roboolstores op de betreffende
outputpoorten.
De twee volgende implementaties gebruiken geen klok. Er wordt pas actie ondernomen als een Get of Put procedure aangeroepen wordt.
Bij de derde mogelijkheid wordt een inputpoort pas gelezen als er door een Get opdracht om de waarde van een boolstore gevraagd wordt die aan die poort gekoppeld is. De betreffende boolstore en al de betreffende roboolstores worden
gecontroleerd en zo nodig gewijzigd, samen met de eventuele outputpoort. Een Put opdracht werkt hetzelfde. Een boolstore wordt veranderd en aIle roboolstores en hun outputpoorten zo nodig veranderd.
Deze methode is gebruikersvriendelijk en handig. De snelheid ligt hoger dan bij het gebruik van de interne klok.
Bij de laatste mogelijkheid werkt een Get opdracht hetzelfde als bij alternatief drie. Het grote verschil is dat
roboolstores nu niet meer gekoppeld kunnen worden aan
outputpoorten. Zij kunnen nu aIleen gebruikt worden om met een Get opdracht een bepaalde gebeurtenis te signaleren. Het besturingsprogramma kan na het optreden van zo'n gebeurtenis dan actie ondernemen, zoals een Put opdracht op een bit.
Deze mogelijkheid is het snelste van aIle vier alternatie~en.
Een groot nadeel is de bovengenoemde beperking die er de gebruiker opgelegd wordt.
Al deze alternatieven hebben hun voor- en nadelen. Van de twee eerste mogelijkheden kan nog gezegd worden dat constant controleren en wijzigen niet erg rendabel werkt en ten koste gaat aan de snelheid van andere processen. Er is voor
alternatief vier gekozen. Deze is dan ook in de implementatie gebruikt.
Overige implementaties
Er is in de initialisatie procedures en functies een automatische controle op fouten geimplementeerd. Deze
controleert of een boolstore voordat hij gebruikt wordt in een procedure al aangemaakt is met NewBoolstore. Als dat niet gecontroleerd werd en er zou een nog niet gedefinieerde
boolstore gebruikt worden dan zou het programma gewoon doorgaan maar af en toe vreemde resultaten geven. De
gebruiker zou de bron van die fouten heel moeilijk kunnen ontdekken. Met een controle gebeurt dit niet, IOKIT zal dan een foutmelding geven.
Deze controle vergt natuurlijk tijd. Daarom vindt geen
controle plaats bij de procedures in het besturingsgedeelte, enkel bij initialisatie- en declaratieprocedures
NewROBoolstore en Connect procedures.
Bij de implementatie zijn de procedures SetMode en SetModeAl1 zo gebouwd dat een aanroep hiervan resulteert in een directe aansturing van de machine volgens de waarden van de
HOOFDSTUK 5 TESTFASE
Na het implementeren van aIle voorgestelde procedures moest IOKIT getest worden. Dit gebeurde allereerst op een CIRP computer waarin een BaseBoard kaart bevestigd was. Aan de kaart was een liftensysteem bevestigd. Dit systeem is een in Fisher Technik nagebouwd model van twee samenwerkende liften in een gebouw met vier verdiepingen. In het verleden is er een besturingsprogramma voor geschreven ("Besturingen in de lift" : Jos Geraerds). Een test van IOKIT hoeft niet zo ver te gaan als het schrijven van een compleet
besturingsprogramma. Een simpele test van de verschillende procedures is genoeg.
Bovendien is IOKIT getest op een Atari Mega-ST. HetzeIfde testprogramma werd gebruikt, echter zonder de mogelijkheid om de koppeling van computer aan een machine te testen omdat er geen mogelijke interface aanwezig was. Daarom is aIleen op softwarebasis getest.
De snelheid werd getest door middel van de ingebouwde timer van de computer. VIak voor de instructie Get of Put werd de timer gestart, vlak erna gestopt en uitgelezen. Het resultaat was ronduit slecht. Varierend welke boolstore gemeten werd, kreeg men een tijdsduur van 10 tot 40 millisec. Dit werd oa. veroorzaakt door de gekozen Get en Put procedures, met name de update duurde lang.
Om de snelheid op te voeren werd IOKIT opnieuw gecompileerd, met een andere instelling van de compiler. Hierdoor werden procedure aanroepen gemiddeld zo'n vier milliseconden
HOOFDSTUK 6
CONCLUSIES EN AANBEVELINGEN
Na het implementeren moet er gekeken worden in hoeverre aan de algemene eisen is voldaan.
Wat de onafhankelijkheid van de hardware betreft, voorzover getest is er geen beperking in de hardware gevonden waardoor IOKIT niet meer werkt. Op ieder systeem waar Modula-2 op draait, kan IOKIT gebruikt worden. De verschillende instel-mogelijkheden maken dit ook bij andere hardware
onwaarschijnlijk. Het is weI zo dat verschillen in de versies van Modula-2 vereisen dat sommige delen in een aparte,
hardware afhankelijke module geplaatst worden. Zo kent de memory-mapped Atari niet de commando's INBYTE, OUTBYTE, INWORD, OUTWORD. Dit is omzeild door deze in de module IOKITSPC te zetten.
Het programma is vriendelijk genoeg voor de gebruiker. Er zijn verschillende voorzieningen ingebouwd die het programmeren gemakkelijk maken, zoals de verschillende koppelingen met de omgeving en eenvoudige aanmaak van
(rolboolstores. Ook bijvoorbeeld de ingebouwde foutenmelding hoort daarbij." Tevens is de overzichtelijke structuur van het gebruikersprogramma een pluspunt voor de gebruiker.
De structuur in een testprogramma is duidelijk. Met de procedures van IOKIT, wordt de gebruiker wel gedwongen om gestructureerd te werken. Dit wordt ondermeer bevorderd door het splitsen van het gebruikersprogramma in twee delen, de eenvoudige en overzichtelijke manier om een logisch schema van boolstores op te zetten en de verschillende
koppelingsmogelijkheden met de omgeving. Als men het testprogramma bekijkt, valt direct de structuur Ope
Er is echter een algemene eis niet gehaald, de snelheid van IOKIT. Om een real-time besturing te kunnen maken, is een hoge snelheid vereist. Dit geldt echter aIleen voor de
procedures Get, Put en PutMore, bij de anderen speelt de tijd slechts een kleine role Maar een operatie als het lezen van een schakelaar (bit) en het veranderen van de stand van een lamp, moet snel gebeuren. Daarbij duren enkele tientallen milliseconden te lang.
Om dit resultaat te verbeteren kan gedacht worden aan
enerzijds een andere manier van implementatie. Ondermeer kan men de vraag stellen of het automatisch veranderen van de waarden van de roboolstores niet teveel gevraagd is. Ook de wijze waarop dit gebeurt kan gewijzigd worden. Als dit
allemaal niet genoeg helpt moet overdacht worden of de
multiple bitoperaties op deze manier gebruikt moeten worden of misschien geschrapt.
Resumerend kan het volgende gezegd worden. IOKIT is een
handig, bruikbaar gereedschap om de koppeling van software en hardware tot stand te brengen. Het werkt overzichtelijk en eenvoudig. Het gebrek aan snelheid beperkt echter de
toepassingsmogelijkheden. Bovendien is het pakket niet
volledig. Voordat er werkelijk iets mee bestuurd zal worden, zijn nog verschillende dingen nodig
*
*
*
Een onderzoek naar het gebruik van virtuele I/O, vooral de koppeling van meerdere computers aan elkaar en de toepassingen daarvan. Hierbij is het mogelijk dat er nog enkele procedures toegevoegd worden die het versturen van gegevens tussen twee computers regelen.
Vergroting van de snelheid waarmee bits aangestuurd worden.
Aanvulling van het pakket procedures met enkele nodige faciliteiten als :
WaitFor (boolstore,TRUE) : wacht tot een bepaalde boolstore een bepaalde waarde krijgt.
Message's en gueue's : vergelijkbaar met message's en queue's uit de Proces Interactie Benadering.
Na deze aanvullingen en/of W1Jz1gingen kan IOKIT met een practische toepassing nogmaals goed getest worden.
HOOFDSTUK 7 LITERATUUR
BaseBoard Installation Guide Users Manual, Scientific Solutions Inc., Solon (1985). Christian K.,
"A Guide to Modula-2" ,
Springer Verlag, Berlin (1986). Ford G., Wiener R.,
"Modula-2, a software developement approach", John Wiley
&
Sons, New York (1985).Geraerds J.,
"Besturingen in de lift",
WPA-nr. 0473 Fac. der Werktuigbouwkunde, T.U. Eindhoven, Eindhoven (1987).
Rooda J.E., Boot W.C.,
"Procescomputers, Basisbegrippen",
Academic Service, 's Gravenhage (1984). Rooda J.E., Boot W.C.,
"Procescomputers 2",
Dictaat 4635 T.U.E., Eindhoven (1987). Thalmann D.,
"Modula-2, An Introduction", Springer Verlag, Berlin (1985).
BIJLAGE A BIJLAGE B BIJLAGE C BIJLAGE D
INHOUDSOPGAVE BIJLAGEN
DEFINITIE MODULE IOKIT
LOGISCH SCHEMA TESTPROGRAMMA HARDWARE KOPPELING TESTPROGRAMMA 22 24 25 26
BIJLAGE A
DEFINITIE MODULE IOKIT DEFINITIE MODULE IOKIT;
FROM SYSTEM IMPORT ADDRESS; TYPE BOOLSTORE
ROBOOLSTORE
=
BOOLSTORE; (* Read Only boolstore *) inv );(* positieve of negatieve logica *)
and, or, xor, equal, byte, word ); in, out ); pos,neg ); LOGICFUNCTION = IOUNIT = IOSELECT = LOGIC = BITINDEX = BOOLSTOREMODE = MoreBs = [ 0 .. 15 ]; ( ignoreConnect, connected, virtualConnected ); RECORD bs : BOOLSTORE; newvalue : BOOLEAN END; (* --- initialisation part --- *) PROCEDURE NewBoolStore
{ inivalue : BOOLEAN BOOLSTORE; PROCEDURE NewEqual ( b s BOOLSTORE ROBOOLSTORE; PROCEDURE NewInvert { b s BOOLSTORE ROBOOLSTORE; PROCEDURE NewROBoolstore { m u l t i B s ARRAY OF BOOLSTORE;
logicfunction : LOGICFUNCTION ROBOOLSTORE; PROCEDURE ConnectBsToAddress ( b o o l s t o r e BOOLSTORE; logic LOGIC; mode BOOLSTOREMODE; offsetbitnumber BITINDEX; inOutput IOSELECT; datastore ADDRESS);
PROCF~aRE ConnectBsToIO ( boolstore logic mode offsetbitnumber inOutput IOaddress BOOLSTORE; LOGIC; BOOLSTOREMODE; BITINDEX; IOSELECT; CARDINAL ) ; (* --- control part --- *) PROCEDURE Get ( bs : BOOLSTORE BOOLEAN; PROCEDURE Put ( bs : BOOLSTOREi newvalue : BOOLEAN ); PROCEDURE PutMore
( putArray : ARRAY OF MoreBs );
(* --- *) PROCEDURE ChangeIOword ( IOword : IOUNIT); PROCEDURE SetModeAll ( inmode BOOLSTOREMODE; outmode : BOOLSTOREMODE ); PROCEDURE SetMode ( bs BOOLSTORE; mode : BOOLSTOREMODE ); END IOKIT.
BIJLAGE B
LOGISCH SCHEMA TESTPROGRAMMA
boolstores roboolstores : power - - powerlam motorl motor2 <> ready down XOR r -p AND
--
OR -busy lampl lamp2 lamp3 lamp4 switchl switch2 switch3 switch4XOR : eXclusiveOR : Geeft TRUE als er precies 1 boolstore TRUE is.
Verbindingsstreepjes tussen (ro}boolstores geven equal aan. De verbinding tussen busy en ready is een invert ( <> ).
Verbindingssteepjes tussen een logische functie en een (ro)-boolstore geven aIleen het resultaat aan.
AIle variabelen die onderstreept zijn, zijn gekoppeld aan een input- of outputpoort. De boolstores (links) zijn zijn
gekoppeld aan een inputpoort. De roboolstores (rechts) zijn aan een outputpoort gekoppeld. De boolstore "down" is niet onderstreept en dus ook niet gekoppeld.
Om de liftmotor te besturen zijn twee roboolstores (motorl en motor2) nodig, dit om de drie stadia van de liftmotor
(omhoog, omlaag, stop) te kunnen bereiken. Met een
roboolstore zouden slechts twee stadia bereikt worden. Als beide roboolstores een gelijke waarde hebben (beiden TRUE of beiden FALSE) staat de lift stile Anders, als motorl TRUE is gaat de lift omlaag, als motorl FALSE is, gaat hij omhoog. Dit alles is in de hardware door twee relais geregeld.
motorl motor2 lift
TRUE FALSE omlaag
FALSE FALSE stop
TRUE TRUE stop
BIJLAGE C HARDWARE KOPPELING
Aan de inputpoorten zijn gekoppeld bitnr.
o
1 2 3 4 5 6 7 Poort C ( adres 529 ) power Poort A ( adres 531 ) switch1 switch2 switch3 switch4Aan de outputpoorten zijn gekoppeld : bitnr.
o
1 2 3 4 5 6 7 Poort C ( adres 533 ) motor1 powerlamp lamp3 Poort A ( adres 535 ) ready motor2 busy lamp2 lamp1 lamp4Het programma test zorgt ervoor dat
1 de liftschakelaars en powerschakelaar een bijbehorend lampje aan en uit zetten en
2 de motor gaat lopen als er zowel een liftschakelaar als de powerschakelaar is ingedrukt
BIJLAGE D TESTPROGRAMMA MODULE Test;
FROM IOKIT IMPORT NewBoolStore, NewEqual, Newlnvert,
NewROBoolstore, ConnectBsToIO, Get, Put, PutMore, ChangeIOword, SetModeAll,
SetMode, BOOLSTORE, ROBOOLSTORE,
LOGICFUNCTION, IOUNIT, IOSELECT, LOGIC, BOOLSTOREMODE, MoreBs;
FROM InOut IMPORT WriteString, ReadCard, WriteLn, WriteCard;
FROM Timer IMPORT StartPulsCount, ReadPulsCount, Quit; FROM Terminal IMPORT KeyPressed;
VAR switch1, switch2, switch3, switch4, power, down: BOOLSTORE;
psw1, motor1, motor2, busy, ready, lampl, lamp2, lamp3,
lamp4, powerlamp : ROBOOLSTORE;
pseudo2 ARRAY [0 .. 1] OF ROBOOLSTORE; pseudo4 ARRAY [0 .. 3] OF ROBOOLSTORE; allarray ARRAY[1 .. 6] OF BOOLSTORE; bsrec ARRAY[0 .. 6] OF MoreBs;
mode, base, number, counter, length: CARDINAL; dummy, m1, m2 : BOOLEAN;
PROCEDURE WriteSwitch(wordarray : ARRAY OF CHAR; bs : BOOLSTORE ); BEGIN WriteString(wordarray) ; IF Get(bs) THEN WriteString('TRUE ') ELSE WriteString('FALSE ') END; END WriteSwitch; PROCEDURE Display; BEGIN
WriteString (CHR(12)); (* scherm wissen *) WriteSwitch('l : Down? ',down);
WriteString('7 : connected-connected'); WriteLn;
WriteSwitch('2 : Power : ' ,power);
WriteString('8 : connected-ignoreConnect'); WriteLn;
WriteSwitch('3 : switch1 : ' ,switch1); WriteString('9 : ignoreConnect-connected'); WriteLn;
WriteSwitch('4 : switch2 : ' ,switch2);
WriteString('10 : ignoreConnect-ignoreConnect'); WriteLn;
WriteSwitch('5 : switch3 : I ,switch3);
WriteString('ll : Display values on screen'); WriteLn;
Wri teSwi tch ( '6 : swi tch4 : ' ,swi tch4) ; WriteString('O : End of program Test'); WriteLn;
WriteLn;
Wri teSwi tch ( ' l a m p 1 ' , lamp1) ; WriteLn;
WriteSwitch(' lamp2 ',lamp2); WriteLn;
WriteSwitch(' lamp3 ',lamp3); WriteLn;
WriteSwitch(' lamp4 ',lamp4); WriteLn;
WriteSwitch(' motor 1 ',motor1); WriteLn;
WriteSwitch(' motor 2 ',motor2); WriteLn;
WriteSwitch(' busy ',busy);
WriteLn;
WriteSwitch(' ready ',ready); WriteLn; WriteSwitch(' and psw1 ',psw1); WriteLn; WriteLn; m1 := Get(motor1); m2 := Get(motor2); WriteString(" Elevator '); IF m1 AND NOT(m2) THEN WriteString('Down') ELSIF m2 AND NOT(m1) THEN WriteString('Up') ELSE WriteString('Stop') END;
Wri teString ( , Mode' ) ; WriteCard(mode,l) ;
WriteLn;
WriteString('---'); WriteLn;
WriteString('Which Boolstore to modify? ') END Display; (* --- initialisation part --- *) BEGIN mode := 10; base := 528; switchl := NewBoolStore(FALSE);
ConnectBsToIO(switch1, pos, ignoreConnect, 1, in, base+3); switch2 := NewBoolStore{FALSE);
ConnectBsToIO{switch2, pos, ignoreConnect, 3, in, base+3); switch3 := NewBoolStore{FALSE);
switch4 := NewBoolStore(FALSE);
ConnectBsToIO(switch4, pos, ignoreConnect, 5, in, base+3);
down := NewBoolStore(TRUE);
power := NewBoolStore(TRUE);
ConnectBsToIO(power, pos, ignoreConnect, 5,in, base+1);
powerlamp := NewEqual(power);
ConnectBsToIO(powerlamp, neg, ignoreConnect, 5, out,
base+5) ;
lamp1 := NewEqual(switch1);
ConnectBsToIO(lamp1, neg, ignoreConnect, 4, out, base+7);
lamp2 := NewEqual(switch2);
ConnectBsToIO(lamp2, neg, ignoreConnect, 3, out, base+7);
lamp3 := NewEqual(switch3);
ConnectBsToIO(lamp3, neg, ignoreConnect, 6, out, base+5);
lamp4 := NewEqual(switch4);
ConnectBsToIO(lamp4, neg, ignoreConnect, 5, out, base+7);
pseudo4[0] .- switch1;
pseudo4[1] := switch2;
pseudo4 [2] := swi tch3 ;
pseudo4[3] := switch4;
busy := NewROBoolstore(pseudo4, or);
ConnectBsToIO(busy, neg, ignoreConnect, 2, out, base+7);
ready := NewInvert(busy);
ConnectBsToIO(ready, neg, ignoreConnect, 0, out, base+7);
pseudo2[0)' := busy;
pseudo2[1] := power;
psw1 := NewROBoolstore(pseudo2, and);
motorl := NewEqual(down);
ConnectBsToIO(motor1, neg, ignoreConnect, 4, out, base+5);
pseudo2[0] := pswl;
pseudo2 [1] :
=
down;motor2 := NewROBoolstore(pseudo2, xor);
ConnectBsToIO(motor2, neg, ignoreConnect, 1, out, base+7);
allarray[l] .- down; allarray[2] .- power; allarray [3] :
=
swi tch1; allarray[4] := switch2; allarray[5] .- switch3; allarray[6] .- switch4; number := 10; (* --- control part --- *) WHILE number<>O DO IF number = 7THEN mode := 7; SetModeAll(connected,connected)
ELSIF number
=
8THEN mode := 8; SetModeAll (connected, ignoreConnect)
ELSIF number
=
9THEN mode := 9; SetModeAll(ignoreConnect,connected)
ELSIF number<7 THEN
StartPulsCount; (* voor het meten *)
dummy := NOT(Get(allarray[number]»; (* van de *)
WriteCard (ReadPulsCount () ,1);WriteLn; (* snelheid *)
WriteCard(ReadPulsCount() ,1); WriteLn; StartPulsCount;
Put (allarray[number] ,dummy);
WriteCard(ReadPulsCount() ,1); WriteLn; WriteLn
ELSIF number
=
10THEN mode := 10; SetModeAll(ignoreConnect,ignoreConnect)
ELSIF number
=
11THEN Display ELSE
counter := 10;
length := 0;
WHILE (number MOD counter>O) AND (number MOD counter<7) DO
bsrec[length] .bs := allarray[number MOD counter];
bsrec[length].newvalue := NOT(Get(allarray[number MOD
counter]»;
number := (number-(number MOD counter» DIV 10;
INC (length) ; END; WHILE length
<
7 DO bsrec[length] := bsrec[O]; INC (length) END; PutMore{,bsrec) END; IF mode=
7 THENWHILE NOT (KeyPressed(»
DO FOR counter := 1 TO 6 DO dummy := Get(motor2); dummy .- Get(ready); dummy := Get(motor1) END END; mode := 10 ELSIF mode
=
8 THENWHILE NOT (KeyPressed(»
DO
FOR counter := 1 TO 6
DO
dummy := Get (motor2) ; dummy := Get (ready) ;
dummy := Get(motor1) END; Display END; mode := 10 ELSIF mode
=
10THEN Display END; ReadCard(number) END;
Quit END Test.
