Ohjelmat mikroprosessorilaitteiden suunnitteluun. Mikroprosessorit. Operaattorit ja operaatiot

Mikroprosessoritiedonkeruujärjestelmän on täytettävä seuraavat vaatimukset: oltava korkea suorituskyky ja yksinkertainen toteuttaa, varmistaa vakaa ja häiriötön toiminta, olla suhteellisen halpa ja kuluttaa vähän resursseja. Määrättyjen tehtävien suorittamiseen ja perusvaatimusten mukaisesti K1816BE51-sarjan mikro-ohjain sopii.

Kuva 3 - Mikroprosessorin tiedonkeruujärjestelmän lohkokaavio.

mikroprosessoriohjelmaalgoritmi siru

Mikroprosessorijärjestelmä (MPS) koostuu seuraavista lohkoista: mikro-ohjain (MC), hajasaantimuisti (RAM), lukumuisti (ROM), ohjelmoitava ajastin (PT), ohjelmoitava rinnakkaisliitäntä (PPI), analoginen-digitaalinen muunnin (ADC), digitaali-analogiamuunnin (DAC), multiplekseri (MUX), ohjelmoitava keskeytysohjain (PIC).

MK muodostaa osoiteväylän (ABA), dataväylän (SD) ja ohjausväylän (CC). Väyliin on kytketty RAM-, ROM-, PT-, PPI-, PKP-lohkot.

RAM on suunniteltu tallentamaan anturimittaustietoja sekä välitietoja. ROM on suunniteltu tallentamaan ohjelmakoodia ja erilaisia ​​vakioita.

PT on suunniteltu laskemaan aikaväli, joka tarvitaan MK-komentojen suorittamiseen. Ennen toimenpiteen suorittamista PT käynnistetään. Jos toimenpide onnistuu, MK nollaa PT:n. Jos MC:ltä ei vastaanoteta laskennan nollauskomentoa (pysähdys on tapahtunut), PT generoi aikavälin laskennan lopussa MC-nollaussignaalin.

PPI on tarkoitettu liittämistä varten ulkoisia laitteita. ADC, diskreetti multiplekseri ja DAC on kytketty SPI:hen.

ADC on suunniteltu muuntamaan antureista tuleva analoginen signaali ja digitaalinen koodi, joka syötetään MK:hen PPI:n kautta. Analogiset anturit on kytketty ADC:hen analogisen multiplekserin kautta.

Data erillisiltä antureilta vastaanotetaan erillisen multiplekserin kautta.

DAC on suunniteltu luomaan ohjaustoimintoja.

Ohjauspaneeli on suunniteltu palvelemaan ulkoisia keskeytyksiä.

Mikroprosessorijärjestelmien suunnittelun vaiheet

Mikroprosessorijärjestelmät voivat monimutkaisuudeltaan, vaatimuksiltaan ja toiminnaltaan poiketa merkittävästi luotettavuusparametreista, tilavuudesta ohjelmisto, olla yhden prosessorin ja moniprosessori, rakennettu yhden tyyppiseen mikroprosessorisarjaan tai useisiin jne. Tältä osin suunnitteluprosessia voidaan muokata järjestelmien vaatimusten mukaan. Esimerkiksi ROM-sisällöltään toisistaan ​​poikkeavien MPS:ien suunnitteluprosessi koostuu ohjelmien kehittämisestä ja ROMien valmistamisesta.

Suunniteltaessa moniprosessorimikroprosessorijärjestelmiä, jotka sisältävät useita erilaisia ​​mikroprosessorisarjoja, on tarpeen ratkaista muistin organisointiin, prosessorien vuorovaikutukseen, järjestelmälaitteiden ja ulkoisen ympäristön välisen vaihdon järjestämiseen, eri toimintanopeuksilla olevien laitteiden toiminnan koordinointiin jne. Alla on likimääräinen vaihesarja, joka on tyypillinen mikroprosessorijärjestelmän luomiseen:
1. Järjestelmävaatimusten formalisointi.
2. Järjestelmän rakenteen ja arkkitehtuurin kehittäminen.
3. Järjestelmälaitteistojen ja -ohjelmistojen kehittäminen ja tuotanto.
4. Kattava virheenkorjaus ja hyväksymistestaus.

Vaihe 1. Tässä vaiheessa laaditaan ulkoiset spesifikaatiot, listataan järjestelmän toiminnot, virallistetaan järjestelmän tekniset spesifikaatiot (TOR) ja kehittäjän suunnitelmat esitetään virallisesti virallisessa dokumentaatiossa.

Vaihe 2. Tässä vaiheessa määritellään yksittäisten laitteiden ja ohjelmistojen toiminnot, valitaan mikroprosessorisarjat, joiden perusteella järjestelmä toteutetaan, määritetään laitteiston ja ohjelmiston välinen vuorovaikutus sekä yksittäisten laitteiden ja ohjelmien ajoitusominaisuudet. .

Vaihe 3. Laitteiston toteuttamien toimintojen ja ohjelmien toteuttamien toimintojen selvittämisen jälkeen piirisuunnittelijat ja ohjelmoijat alkavat samanaikaisesti kehittää ja valmistaa prototyyppiä ja ohjelmistoa. Laitteiden kehitys ja valmistus koostuu rakenne- ja piirikaavioiden kehittämisestä, prototyyppituotannosta ja off-line -virheenkorjauksesta.
Ohjelmistokehitys koostuu algoritmien kehittämisestä; lähdeohjelmien tekstin kirjoittaminen; lähdeohjelmien käännökset objektiohjelmiksi; offline-virheenkorjaus.

Vaihe 4. Katso Kattava virheenkorjaus.

MPS-suunnittelun jokaisessa vaiheessa ihmiset voivat tehdä virheitä ja tehdä virheellisiä suunnittelupäätöksiä. Lisäksi laitteessa voi esiintyä vikoja.

Virheiden lähteet

Tarkastellaan virhelähteitä suunnittelun kolmessa ensimmäisessä vaiheessa.

Vaihe 1. Tässä vaiheessa virhelähteitä voivat olla: vaatimusten looginen epäjohdonmukaisuus, puutteet, algoritmin epätarkkuudet.

Vaihe 2. Tässä vaiheessa virhelähteitä voivat olla: toimintojen puuttuminen, laitteiden ja ohjelmien välisen vuorovaikutuksen protokollan epäjohdonmukaisuus, virheellinen mikroprosessorisarjojen valinta, algoritmien epätarkkuudet, teknisten vaatimusten virheellinen tulkinta, joidenkin tietovirtojen puuttuminen.

Vaihe 3. Tässä vaiheessa virhelähteitä voivat olla: laitteiston kehittämisen aikana - joidenkin toimintojen puuttuminen, teknisten vaatimusten virheellinen tulkinta, viat synkronointipiireissä, suunnittelusääntöjen rikkominen; prototyypin valmistuksen aikana - komponenttien toimintahäiriöt, asennus- ja kokoonpanovirheet; ohjelmistoa kehitettäessä - joidenkin toimintojen puuttuminen toimeksianto, algoritmien epätarkkuuksia, koodausvirheitä.

Jokainen lueteltu virhelähde voi aiheuttaa suuren määrän subjektiivisia tai fyysisiä vikoja, jotka on paikallistettava ja poistettava. Virheiden havaitseminen ja vian paikallistaminen on vaikea tehtävä useista syistä: ensinnäkin vikojen suuresta määrästä johtuen; toiseksi se johtuu siitä, että erilaiset viat voivat ilmetä samalla tavalla. Koska subjektiivisista vioista ei ole malleja, tätä tehtävää ei ole formalisoitu. Virheiden havaitsemiseen ja fyysisten vikojen paikallistamiseen tarkoitettujen menetelmien ja työkalujen luomisessa on edistytty jonkin verran. Näitä menetelmiä ja työkaluja käytetään laajasti erillisten järjestelmien toimintakunnon tarkistamiseen ja vikojen diagnosointiin niiden suunnittelun, tuotannon ja käytön aikana.

Subjektiiviset toimintahäiriöt eroavat fyysisistä siinä, että havaitsemisen, lokalisoinnin ja korjaamisen jälkeen niitä ei enää esiinny. Kuitenkin, kuten virhelähteiden luettelo antaa ymmärtää, subjektiivisia vikoja voi esiintyä järjestelmäspesifikaatiota kehitettäessä, mikä tarkoittaa, että jopa järjestelmän perusteellisimman testauksen jälkeen sen ulkoisten spesifikaatioiden perusteella, järjestelmässä voi silti esiintyä subjektiivisia vikoja.

Suunnitteluprosessi on iteratiivinen prosessi. Hyväksymistestivaiheessa havaitut häiriöt voivat johtaa spesifikaatioiden korjaamiseen ja sitä kautta koko järjestelmän suunnittelun aloittamiseen. Viat tulee havaita mahdollisimman varhaisessa vaiheessa, tätä varten on tarpeen valvoa projektin oikeellisuutta jokaisessa kehitysvaiheessa.

Suunnitelman validointi

Tärkeimmät menetelmät suunnittelun oikeellisuuden valvontaan ovat seuraavat: todentaminen - muodolliset menetelmät suunnittelun oikeellisuuden osoittamiseksi; mallinnus; testaus.

Ohjelmiston, laiteohjelmiston ja laitteiston tarkistamisessa on paljon työtä. Nämä teokset ovat kuitenkin luonteeltaan teoreettisia. Käytännössä objektien käyttäytymisen mallintamista ja testausta käytetään edelleen.

Projektin oikeellisuuden valvomiseksi jokaisessa suunnitteluvaiheessa on tarpeen suorittaa mallinnus järjestelmän abstraktin esityksen eri tasoilla ja varmistaa tietyn mallin oikea toteutus testaamalla. Vaatimusten formalisointivaiheessa oikeellisuuden valvonta on erityisen tarpeellista, koska monet suunnittelutavoitteet eivät ole formalisoituja tai niitä ei voida periaatteessa formalisoida. Asiantuntijaryhmä voi tarkastella toiminnallista eritelmää tai simuloida ja testata sen määrittämiseksi, saavutetaanko halutut tavoitteet. Kun toimintaspesifikaatio on hyväksytty, aloitetaan toiminnallisten testiohjelmien kehittäminen järjestelmän oikean toiminnan selvittämiseksi sen toiminnallisen spesifikaation mukaisesti. Ihannetapauksessa kehitetään testejä, jotka perustuvat kokonaan tähän spesifikaatioon ja tarjoavat mahdollisuuden testata mitä tahansa sellaisen järjestelmän toteutusta, jonka väitetään pystyvän suorittamaan spesifikaatiossa määritellyt toiminnot. Tämä menetelmä on täysin päinvastainen kuin muut, joissa testit rakennetaan tiettyjen toteutusten suhteen. Toteutusriippumaton toiminnallinen verifiointi on yleensä houkutteleva vain teoreettisesti, mutta sillä ei ole käytännön merkitystä sen suuren yleisyyden vuoksi.

Testiohjelmien kirjoittamisen tylsän työn automatisointi ei ainoastaan ​​lyhennä suunnittelu-/virheenkorjausaikaa luomalla testiohjelmia suunnitteluvaiheessa (koska ne voidaan luoda heti järjestelmävaatimusten luomisen jälkeen), vaan myös antaa suunnittelijalle mahdollisuuden muuttaa määrityksiä ilman tarvetta murehtia kaikkien testiohjelmien uudelleenkirjoittamisesta. Käytännössä testikehitys on kuitenkin usein alempi prioriteetti kuin suunnittelu, joten testiohjelmat ilmestyy paljon myöhemmin kuin sen valmistuminen. Mutta vaikka yksityiskohtaiset testit osoittautuvat valmiiksi, on usein epäkäytännöllistä ajaa niitä simulaattorilla, koska yksityiskohtainen mallintaminen vaatii suuria kustannuksia ohjelman kehittämiseen ja laskenta-aikaan, minkä seurauksena suurin osa virheenkorjaustyöstä on lykättävä prototyyppijärjestelmän luomiseen.

Kun virhe on havaittu, sen lähde on lokalisoitava, jotta korjaus voidaan suorittaa sopivalla järjestelmän abstraktiotasolla ja sopivassa paikassa. Virheen lähteen väärä tunnistaminen tai korjausten tekeminen järjestelmän abstraktin esityksen toisella tasolla johtaa siihen, että järjestelmää koskevat tiedot ovat ylemmät tasot muuttuu virheelliseksi, eikä sitä voida käyttää lisävirheenkorjaukseen järjestelmän tuotannon ja käytön aikana. Jos esimerkiksi kokoonpanokielellä kirjoitetun ohjelman lähdetekstiin tuodaan toimintahäiriö ja korjaus suoritetaan objektikoodissa, ohjelman lisävirheenkorjaus suoritetaan objektikoodissa; tässä tapauksessa kaikki ohjelman kirjoittamisen edut kokoonpanokielellä vähenevät.

Laitteen lohkokaavio on esitetty liitteessä A.

Tämä mikroprosessorijärjestelmä koostuu seuraavista lohkoista: mikroprosessori, RAM, ROM, ohjelmoitava rinnakkaisliitäntä, analogia-digitaalimuunnin, ajastin, näyttö.

Antureilta tulevat analogiset signaalit saapuvat ADC:hen sisäänrakennetun analogisen multiplekserin tuloihin, jotka jokaisella aikavälillä kytkevät yhden signaalin analogia-digitaalimuuntimen tuloon.

Analogi-digitaalimuunninta käytetään analogisen signaalin muuntamiseen digitaaliseksi koodiksi, jolla mikroprosessori toimii.

Mikroprosessori käyttää ADC:tä ohjelmoitavan rinnakkaisliitännän kautta. Lukee tiedot ADC-lähdöistä ja tallentaa ne RAM-muistisoluun. Lisäksi MP laskee säädösvaikutuksen aseman ulostulon öljynpaineanturista saatujen tietojen perusteella. Tämä määrä muodossa digitaalinen koodi toimilaite lähetetään.

RAM-muistia käytetään antureilta vastaanotetun tiedon ja mikroprosessorilaskennan välitulosten väliaikaiseen tallentamiseen.

Järjestelmäohjelmisto on tallennettu ROM-muistiin (vain lukumuisti). Lukutoimintoa ohjaa mikroprosessori.

Ohjelma, joka on tallennettu ROM-muistiin, tarjoaa seuraavat järjestelmätoiminnot:

Antureiden peräkkäinen kysely;

Analogisen signaalin analogisesta digitaaliseksi muuntamisen ohjaus;

Öljynpaineen säätely;

Ilmaisu ja hälytys;

Reaktio tehohäviöön.

Järjestelmäalgoritmin kehittäminen

Algoritmin lohkokaavio on esitetty liitteessä B.

Alustus

Tässä vaiheessa ohjaussanat kirjoitetaan ohjelmoitavan rinnakkaisliitännän RUS:iin. PPI DD10 toimii nollatilassa. Portit toimivat seuraavasti: portti A - tulo, portti B - lähtö, portti C - lähtö. PPI DD1 toimii nollatilassa. Portit toimivat seuraavasti: portti A - lähtö, portti B - lähtö, portti C - lähtö.

Anturikysely

Analogiset anturit pollaavat ADC. Mikroprosessori pollaa PPI 1:n portin A kautta kulkevia erillisiä antureita.

Tallennetaan RAM-muistiin

Antureiden kyselyn jälkeen saadut tulokset syötetään hajasaantimuistilaitteeseen väliaikaista tallennusta varten.

Hallitse toimintaa

Mikroprosessorijärjestelmä analysoi vastaanotetut tiedot ja luo digitaalisen ohjaustoiminnon.

Kaaviokaavion kehittäminen

Laitteen kaaviokuva on esitetty liitteessä D.

Osoiteväylä muodostetaan puskurirekisterin ja väyläohjaimen avulla. Rekisterin valinta tapahtuu mikroprosessorin ALE-signaalilla. Väyläohjainta tarvitaan lisäämään osoitteen korkean tavun kuormituskapasiteettia.

Dataväylä muodostetaan käyttämällä väyläohjainta, joka valitaan käyttämällä DT/R- ja OE-signaaleja.

Järjestelmäväylä muodostetaan DD10-dekooderin kautta käyttämällä M/IO-, WR-, RD-signaalien yhdistelmää.

Taulukko 1 - Ohjaussignaalit

ROM, RAM ja muut laitteet valitaan käyttämällä osoiteväylän linjoja A13-A15 dekooderin kautta. ROM-solut sijaitsevat osoitteessa 0000h.

Taulukko 2 - Laitteen valinta

			Laite

PPI-ohjaussanan portin tai rekisterin valinta suoritetaan osoiteväylän linjojen A0, A1 kautta. Erilliset anturit syötetään PPI DD12:n portin A PA0-PA7 tuloihin; portin B tuloihin - ADC:stä; LEDit on kytketty portin C tuloihin.

Analogisen multiplekserin avulla valitaan laite, josta tietoja luetaan. Analoginen multiplekseri on sisäänrakennettu ADC:hen. ADC:n leveys on sama kuin dataväylän leveys ja on 8 bittiä.

Vastuksia R2-R4 käytetään muuntamaan yhtenäinen 4...20 mA virtasignaali 1...5 V jännitteeksi.

Napsauta "Lataa arkisto" -painiketta, lataat tarvitsemasi tiedoston täysin ilmaiseksi.
Ennen lataamista tästä tiedostosta Ajattele niitä hyviä tiivistelmiä, testejä, tutkielmia, väitöskirjoja, artikkeleita ja muita asiakirjoja, joita ei ole lunastettu tietokoneellasi. Tämä on sinun työtäsi, sen pitäisi osallistua yhteiskunnan kehitykseen ja hyödyttää ihmisiä. Etsi nämä teokset ja lähetä ne tietokantaan.
Me ja kaikki opiskelijat, jatko-opiskelijat, nuoret tutkijat, jotka käyttävät tietopohjaa opinnoissaan ja työssään, olemme erittäin kiitollisia sinulle.

Jos haluat ladata asiakirjan sisältävän arkiston, syötä viisinumeroinen luku alla olevaan kenttään ja napsauta "Lataa arkisto" -painiketta

Samanlaisia ​​asiakirjoja

Suunnitteluratkaisuvaihtoehtojen analysointi ja optimaalisen ratkaisun valinta sen perusteella. Mikroprosessorijärjestelmän toiminnallisen kaavion synteesi lähdetietojen analysoinnin perusteella. Mikroprosessorijärjestelmän laitteiston ja ohjelmiston kehitysprosessi.

kurssityö, lisätty 20.5.2014


Teoreettinen perusta mikro-ohjaimeen ja lukulaitteeseen perustuvan mikroprosessorijärjestelmän kehittäminen e-kirjoja, niiden teknisten ja taloudellisten indikaattoreiden analyysi ja vertailu analogeihin. Työsuojelun perusstandardit tietokoneen kanssa työskennellessä.

opinnäytetyö, lisätty 13.7.2010


MP-laitteen käyttökelpoisuus. Mikroprosessorijärjestelmän arkkitehtuuri. LSI VT:n rakennejärjestely eristetyillä linja-autoilla. Mikrokontrollerin sisältö ja mahdollinen fokus. Yksinkertaisen sulautetun mikro-ohjaimen yleinen rakenne.

tiivistelmä, lisätty 28.4.2011


Mikroprosessorijärjestelmän rakenne, sen ohjauksen ja signaalinsiirron algoritmi. Osoitteen jakelukartta. Sähköalan kehitys kaaviokuva ja elementtipohjan valinta. Virrankulutuksen laskenta, virtalähde, ohjelmisto.

kurssityö, lisätty 22.1.2014


Toimintojen jako mikroprosessorijärjestelmän laitteisto- ja ohjelmisto-osien välillä. Mikro-ohjaimen valinta, rakenne-, toiminta- ja piirikaavion kehitys ja kuvaus. Ohjelmointiympäristön valinta, algoritmikaavio ja ohjelmalistaus.

kurssityö, lisätty 17.8.2013


Mikroprosessoriohjausjärjestelmän tarkoitus ja suunnittelu. Mikroprosessoriohjausjärjestelmän toimintakaavion kuvaus. Mittauskanavan staattisten ominaisuuksien laskenta. Algoritmin kehittäminen mikroprosessoriohjausjärjestelmän toimintaa varten.

kurssityö, lisätty 30.8.2010


Yleiskäsite mikrokontrollereista, niiden käyttö ja tarkoitus. Mikroprosessoritiedonkeruujärjestelmäprojektin kehittäminen SDK 1.1- ja SDX 0.9 -telineiden avulla. Ohjelmiston luominen ja lataaminen laboratoriotelineeseen SDK-1.1.

kurssityö, lisätty 31.1.2014

Laadulliset ja määrälliset muutokset VT-laitteiden alkuainekannassa ovat johtaneet

muuttaa niiden suunnittelun vakiintuneita periaatteita (kuten jäykkä

rakenne, johdonmukainen keskusjohto, linjaorganisaatio

muisti ja kyvyttömyys mukauttaa tietokoneen rakennetta erityispiirteisiin

ongelma ratkaistaan).

Klassiset Von Neumann -periaatteet tietokonejärjestelmien organisoinnissa korvattiin ajatuksilla MPS:n ongelmaorientaatiosta, rinnakkais- ja liukuhihnakäsittelystä, taulukkomuotoisten tietojenkäsittelymenetelmien käytöstä, MPS-rakenteiden säännöllisyyden ja homogeenisuuden periaatteista; tulee todelliseksi

mahdollisuus luoda mukautuvasti uudelleenkonfiguroitavia järjestelmiä sekä

ohjelmistotoimintojen laitteistototeutus. Siksi tällä hetkellä

MPS:ään perustuvien tietokonejärjestelmien suunnittelussa

niin sanotun "3M"-periaatteen soveltaminen: modulaarisuus, kanavat,

mikroohjelmoitavuus.

Modulaarisen organisaation periaate sisältää laskennallisten ja

MPS:n ohjaus moduulien perusteella: rakenteelliset, toiminnalliset ja

sähköisesti täydellisiä tietokonelaitteita, joiden avulla voit itsenäisesti

tai yhdessä muiden moduulien kanssa tämän luokan ongelmien ratkaisemiseksi. Modulaarinen

lähestymistapa mikrotietokoneiden ja järjestelmien suunnitteluun sallii (kun se toteutetaan kuten

yleiset ja erikoistuneet moduulit) perheiden luomisen varmistamiseksi

(rivejä) MPS, eri toiminnallisuutta ja ominaisuudet,

kattaa laajan valikoiman sovelluksia, auttaa vähentämään

suunnittelukustannuksia ja yksinkertaistaa myös kapasiteetin laajentamista ja

järjestelmien uudelleenkonfigurointi, viivästyttää tietojenkäsittelyn vanhenemista

Tietojenvaihdon selkärankamenetelmä toisin kuin järjestäytymistapa

mielivaltaiset yhteydet ("kaikki kaikkien kanssa" -periaatteen mukaisesti) mahdollistavat järjestämisen ja

minimoida MPS:n yhteyksien määrän. Se helpottaa tietojen vaihtoa välillä

eri tasojen toiminnallisia ja rakenteellisia moduuleja käyttäen

tulo- ja lähtöväylät yhdistävät moottoritiet. On yksi, kaksi,

kolmi- ja monilinjaiset liitännät. On tarpeen huomioida suhde

piirisuunnittelu ja toteutusvaiheessa ilmenevät rakenteelliset ratkaisut

tätä menetelmää vaihtoa erityisen kaksisuuntaisen puskurin luomisen muodossa

kaskadit, joissa on kolme vakaata tilaa ja tilapäisten käyttö

vaihtokanavien multipleksointi.

Laiteohjelmiston ohjaus tarjoaa suurimman joustavuuden organisaatiossa

monitoimimoduuleja ja mahdollistaa ongelmaorientaation

MPS, ja käytä niissä myös makrotoimintoja, mikä on tehokkaampaa kuin käyttö

vakiorutiineja. Lisäksi ohjattujen sanojen siirto muodossa

salatut koodisekvenssit vastaavat minimointiehtoja

VLSI-nastojen määrä ja moduulien yhteenliitäntöjen määrän vähentäminen.

Edellä lueteltujen MPS-suunnittelun pääominaisuuksien lisäksi sen pitäisi olla

Huomaa säännöllisyyden periaate, joka edellyttää luonnollista

MPS:n rakenteen elementtien ja niiden välisten yhteyksien toistettavuus. Tämän soveltaminen

periaatteen avulla voit lisätä integraalitiheyttä, vähentää sidosten pituutta

on-chip, vähentää topologista ja piirin suunnitteluaikaa

suunnittelu LSI ja VLSI, vähentää risteysten ja tyypit toiminnallinen

ja rakenneosat.

MPS-arkkitehtuuria (järjestelmävaihetta) kehitettäessä on tarpeen ratkaista seuraavat asiat

Kuvaa järjestelmän toiminnallisen käyttäytymisen käsitteellinen rakenne

käyttäjän edut huomioon ottaen sen rakentamisen ja organisoinnin aikana

laskentaprosessi sen sisällä;

Selvitä rakennusohjelmiston rakenne, nimikkeistö ja ominaisuudet

mikroohjelmatyökalut;

Kuvaile tietovirtojen sisäisen organisoinnin ja ohjauksen piirteitä

tiedot;

Suorita analyysi fysiikan toiminnallisesta rakenteesta ja ominaisuuksista

järjestelmälaitteiden toteutus ohjelmistotasapainon näkökulmasta,

mikroohjelma ja laitteisto.

MPS:n suunnittelun päävaiheet on esitetty kuvassa. 3.1.

Suunnittelun alkuvaiheessa MPS voidaan kuvata yhdessä

seuraavat käsitteelliset tasot: "musta laatikko", rakenne, ohjelma,

looginen, piiri.

"Mustan laatikon" tasolla MPS on kuvattu ulkoisilla eritelmillä, joissa

ulkoiset ominaisuudet on lueteltu.

Riisi. 3.1. MPS-suunnittelun vaiheet

Rakennetason luovat MPS:n laitteistokomponentit, jotka

kuvataan yksittäisten laitteiden toiminnoilla, niiden keskinäisillä liitännöillä ja tiedolla

purot.

Ohjelmistotaso on jaettu kahteen alatasoon (prosessoriohjeet ja

kieli) ja MPS tulkitaan operaattorien sarjaksi tai

komennot, jotka aiheuttavat yhden tai toisen toiminnon tietyssä tietorakenteessa.

Looginen taso on ominaista yksinomaan diskreeteille järjestelmille ja on jaettu

kaksi alatasoa: kytkentäpiirit ja rekisterisiirrot.

Ensimmäisen alatason muodostavat portit (yhdistelmäpiirit ja muistielementit) ja niiden pohjalta rakennetut tietojenkäsittelyoperaattorit. Toiselle alatasolle on ominaista korkeampi abstraktio ja se edustaa kuvausta rekistereistä ja tiedonsiirrosta niiden välillä. Se sisältää kaksi

osat: tiedot ja valvonta: ensimmäinen muodostuu rekistereistä,

operaattorit ja tiedonsiirtoreitit, toinen tarjoaa riippuen

aikasignaalit, jotka käynnistävät tiedonsiirron rekisterien välillä.

Piiritaso perustuu erillisten laiteelementtien toiminnan kuvaukseen.

MPS:n, kuten minkä tahansa erillisen järjestelmän, elinkaaressa on kolme vaihetta:

suunnittelu, valmistus ja käyttö.

Jokainen vaihe on jaettu useisiin vaiheisiin, joissa on rakenteellisten tai fyysisten vikojen todennäköisyyttä. Viat luokitellaan syidensä mukaan: fyysiset, jos syynä on elementtien vika, ja subjektiiviset, jos syynä on suunnitteluvirhe.

Subjektiiviset viat jaetaan suunnitteluun ja interaktiivisiin. Design

toimintahäiriöt johtuvat järjestelmään eri vaiheissa tulleista puutteista

alkuperäisen tehtävän toteuttaminen. Vuorovaikutteisia vikoja tapahtuu

työn aikana huoltohenkilöstön (käyttäjän) syyn vuoksi. Lopputulos

toimintahäiriö on virhe, ja yksi toimintahäiriö voi

aiheuttaa useita virheitä, ja sama virhe voi aiheutua

monia toimintahäiriöitä.

On myös käsite vika - fyysinen muutos parametreissa

järjestelmän osia, jotka ylittävät sallitut rajat. Vikoja kutsutaan

epäonnistumisia, jos ne ovat tilapäisiä, ja epäonnistumisia, jos ne ovat pysyviä.

Vikaa ei voida havaita ennen kuin olosuhteet täyttyvät

siitä johtuvan toimintahäiriön esiintyminen, jonka seurauksena pitäisi olla sen

jono, joka välitetään tutkittavan kohteen ulostuloon, jotta se voidaan tehdä

havaittava toimintahäiriö.

Vian diagnosointi on prosessi, jossa määritetään virheen syy

testitulokset.

Vianetsintä on prosessi, jossa havaitaan virheitä ja määritetään

niiden ulkonäön lähteet MPS:n suunnittelun aikana suoritettujen testien tulosten mukaan.

Vianetsintätyökalut ovat laitteita, komplekseja ja ohjelmia. Joskus alla

Vianetsintä tarkoittaa vikojen havaitsemista, paikallistamista ja poistamista. Menestys

virheenkorjaus riippuu siitä, miten järjestelmä on suunniteltu, onko

ominaisuuksia, jotka tekevät siitä kätevän virheenkorjauksessa, sekä käytetyistä työkaluista

virheenkorjausta varten.

Virheenkorjauksen suorittamiseksi suunnitellun MPS:n on oltava

hallittavuuden, havaittavuuden ja ennustettavuuden ominaisuudet.

Ohjattavuus - järjestelmän ominaisuus, jossa sen käyttäytyminen on herkkä

hallinta, ts. Järjestelmän toiminta on mahdollista pysäyttää sisään

tiettyyn tilaan ja käynnistä järjestelmä uudelleen.

Havaittavuus– järjestelmän ominaisuus, jonka avulla voit seurata sen toimintaa

järjestelmä, sen sisäisten tilojen muutoksen takana.

Ennustettavuus– järjestelmän ominaisuus, joka mahdollistaa järjestelmän asentamisen

tila, josta kaikki seuraavat tilat voidaan ennustaa.

MPS voi vaihdella huomattavasti monimutkaisuuden, vaatimusten ja toimintojen osalta

toimintaparametrit, ohjelmiston määrä, tyyppi

mikroprosessorisarja jne. Tässä suhteessa suunnitteluprosessi voi

vaihtelevat järjestelmän vaatimusten mukaan.

Suunnitteluprosessi on iteratiivinen prosessi. Hyväksymistestivaiheessa havaitut viat voivat johtaa spesifikaatioiden korjaamiseen ja

siksi koko järjestelmän suunnittelun alkuun. löytö

viat on havaittava mahdollisimman aikaisessa vaiheessa; tätä varten sinun täytyy hallita

projektin oikeellisuudesta jokaisessa kehitysvaiheessa. Seuraavat menetelmät ovat olemassa

suunnittelun oikeellisuuden valvonta: todentaminen (muodolliset menetelmät

todiste projektin oikeellisuudesta); mallinnus; testaus.

Viime aikoina ohjelmiston todentamisen parissa on tehty paljon työtä

ohjelmisto, laiteohjelmisto, laitteisto. Nämä teokset ovat kuitenkin edelleen

luonteeltaan teoreettinen. Siksi käytännössä mallinnusta käytetään useammin

objektien käyttäytyminen ja testaus eri abstrakteilla tasoilla

järjestelmäesitykset.

Järjestelmävaatimusten virallistamisvaiheessa seurataan projektin oikeellisuutta

erityisen tarpeellista, koska monia suunnittelutavoitteita ei ole muotoiltu tai

ei voida periaatteessa formalisoida. Toiminnallinen eritelmä voi

asiantuntijaryhmän analysoima tai simuloitu ja testattu

kokeellisesti haluttujen tavoitteiden saavuttamisen tunnistamiseksi. Hyväksynnän jälkeen

toiminnallinen määrittely aloittaa testiohjelmien kehittämisen,

suunniteltu varmistamaan järjestelmän oikea toiminta

sen määrittely. Ihannetapauksessa testit kehitetään kokonaan

tämän spesifikaation perusteella ja mahdollistaa minkä tahansa

järjestelmän toteuttaminen, joka on julistettu kykeneväksi suorittamaan toiminnot

spesifikaatiossa määritelty. Tämä menetelmä on täysin päinvastainen kuin muut,

jossa testit rakennetaan tiettyihin toteutuksiin. Käytännössä kuitenkin

testikehitys on usein asetettu alhaisemmaksi kuin

projekti, joten testiohjelmat ilmestyvät paljon myöhemmin kuin se