Програми проектування мікропроцесорних устройств. Мікропроцесори. Опепранди та операції

Мікропроцесорна система збору даних повинна задовольняти наступним вимогам: забезпечувати високу швидкодію та бути простою у виконанні, повинна забезпечувати стійку та безвідмовну роботу, бути порівняно дешевою та споживати невеликі ресурси. Для виконання поставлених завдань і відповідно до основних вимог підходить мікроконтролер серії К1816ВЕ51.

Малюнок 3 – Структурна схема мікропроцесорної системи збору даних.

мікропроцесорна програма алгоритм мікросхема

Мікропроцесорна система (МПС) складається з наступних блоків: мікроконтролера (МК), оперативного запам'ятовуючого пристрою (ОЗУ), постійного запам'ятовуючого пристрою (ПЗУ), програмованого таймера (ПТ), паралельного програмованого інтерфейсу (ППІ), аналого-цифрового перетворювача (АЦП), цифро-аналогового перетворювача (ЦАП), мультиплексора (MUX), програмованого контролера переривань (ПКП).

МК формує шину адреси (ША), шину даних (ШД) та шину управління (ШУ). Блоки ОЗП, ПЗП, ПТ, ППІ, ПКП підключені до шин.

ОЗП призначене для зберігання даних опитування датчиків, а також проміжні дані. ПЗУ призначена для зберігання коду програми та різних констант.

ПТ призначений для відліку інтервалу часу, який буде потрібний для виконання команд МК. Перед виконанням операції ПТ запускається. При успішному виконанні операції МК скидає ПТ. Якщо МК не надходить команди скидання рахунку (відбулося зависання), ПТ по закінченні відліку інтервалу часу виробляє сигнал скидання МК.

ППІ призначене для підключення зовнішніх пристроїв. До ППІ підключено АЦП, дискретний мультиплексор та ЦАП.

АЦП призначений для перетворення аналогового сигналу з датчиків та цифровий код, який через ППІ подається до МК. Аналогові датчики підключаються до АЦП через аналоговий мультиплексор.

Через дискретний мультиплексор надходять дані дискретних датчиків.

ЦАП призначений для формування керуючого впливу.

ПКП призначений обслуговування зовнішніх переривань.

Етапи проектування мікропроцесорних систем

Мікропроцесорні системи за своєю складністю, вимогами та функціями можуть значно відрізнятися надійними параметрами, об'ємом. програмних засобівбути однопроцесорними і багатопроцесорними, побудованими на одному типі мікропроцесорного набору або декількох, і т.д. У зв'язку з цим процес проектування може змінюватись в залежності від вимог, що пред'являються до систем. Наприклад, процес проектування МПС, що відрізняються одна від одної змістом ПЗП, складатиметься з розробки програм та виготовлення ПЗП.

При проектуванні багатопроцесорних мікропроцесорних систем, що містять кілька типів мікропроцесорних наборів, необхідно вирішувати питання організації пам'яті, взаємодії з процесорами, організації обміну між пристроями системи та зовнішнім середовищем, узгодження функціонування пристроїв, що мають різну швидкість роботи, і т. д. Нижче наведено зразкову послідовність етапів , Типові для створення мікропроцесорної системи:
1. Формалізація вимог до системи.
2. Розробка структури та архітектури системи.
3. Розробка та виготовлення апаратних засобів та програмного забезпечення системи.
4. Комплексне налагодження та приймальні випробування.

Етап 1. На цьому етапі складаються зовнішні специфікації, перераховуються функції системи, формується технічне завдання (ТЗ) на систему, формально викладаються задуми розробника в офіційній документації.

Етап 2. На даному етапі визначаються функції окремих пристроїв та програмних засобів, вибираються мікропроцесорні набори, на базі яких буде реалізована система, визначаються взаємодія між апаратними та програмними засобами, часові характеристики окремих пристроїв та програм.

Етап 3. Після визначення функцій, що реалізуються апаратурою, та функцій, що реалізуються програмами, схемотехніки та програмісти одночасно приступають до розробки та виготовлення відповідно дослідного зразка та програмних засобів. Розробка та виготовлення апаратури складаються з розробки структурних та принципових схем, виготовлення прототипу, автономного налагодження.
Розробка програм складається із розробки алгоритмів; написання тексту вихідних програм; трансляції вихідних програм до об'єктних програм; автономного налагодження.

Етап 4. див. Комплексне налагодження.

На кожному етапі проектування МПС людьми можуть бути внесені несправності та прийняті неправильні проектні рішення. Крім того, в апаратурі можуть виникнути дефекти.

Джерела помилок

Розглянемо джерела помилок перших трьох етапах проектування.

Етап 1. На цьому етапі джерелами помилок можуть бути: логічна неузгодженість вимог, упущення, неточність алгоритму.

Етап 2. На даному етапі джерелами помилок можуть бути: упущення функцій, неузгодженість протоколу взаємодії апаратури та програм, неправильний вибір мікропроцесорних наборів, неточності алгоритмів, неправильна інтерпретація технічних вимог, упущення деяких інформаційних потоків.

Етап 3. На цьому етапі джерелами помилок можуть бути: при розробці апаратури - упущення деяких функцій, неправильна інтерпретація технічних вимог, недоробка у схемах синхронізації, порушення правил проектування; при виготовленні прототипу - несправності комплектуючих виробів, несправності монтажу та складання; при розробці програмних засобів - упущення деяких функцій технічного завдання, неточності в алгоритмах, неточності кодування

Кожен із перелічених джерел помилки може породити велику кількість суб'єктивних або фізичних несправностей, які необхідно локалізувати та усунути. Виявлення помилки та локалізація несправності є складним завданням з кількох причин: по-перше, через велику кількість несправностей; по-друге, через те, що різні несправності можуть виявлятися однаковим чином. Оскільки відсутні моделі суб'єктивних несправностей, це завдання не формалізована. Є певні успіхи у галузі створення методів та засобів виявлення помилок та локалізації фізичних несправностей. Ці методи та засоби широко використовуються для перевірки працездатного стану та діагностики несправностей дискретних систем при проектуванні, виробництві та експлуатації останніх.

Суб'єктивні несправності відрізняються від фізичних тим, що після виявлення, локалізації та корекції більше не виникають. Однак, як випливає з переліку джерел помилок, суб'єктивні несправності можуть бути внесені на етапі розробки специфікації системи, а це означає, що навіть після ретельних випробувань системи на відповідність її зовнішнім специфікаціям в системі можуть бути суб'єктивні несправності.

Процес проектування – ітераційний процес. Несправності, виявлені на етапі приймальних випробувань, можуть призвести до корекції специфікацій, а отже, до початку проектування всієї системи. Виявляти несправності необхідно якомога раніше, для цього треба контролювати коректність проекту на кожному етапі розробки.

Перевірка правильності проекту

Основні методи контролю правильності проектування: верифікація - формальні методи доказу коректності проекту; моделювання; Тестування.

Існує багато робіт з верифікації програмного забезпечення, мікропрограм, апаратури. Однак ці роботи мають теоретичний характер. На практиці поки що використовують моделювання поведінки об'єкта та тестування.

Для контролю коректності проекту кожному етапі проектування необхідно проводити моделювання різних рівнях абстрактного представлення системи та перевірку правильності реалізації заданої моделі шляхом тестування. На етапі формалізації вимог контроль коректності особливо необхідний, оскільки багато мети проектування не формалізуються чи може бути формалізовані у принципі. Функціональна специфікація може аналізуватись колективом експертів або моделюватись та перевірятись у дослідному порядку для виявлення, чи досягаються бажані цілі. Після затвердження функціональної специфікації починається розробка функціональних тестових програм, призначених встановлення правильності функціонування системи відповідно до її функціональної специфікацією. В ідеальному випадку розробляються тести, що повністю засновані на цій специфікації і дають можливість перевірки будь-якої реалізації системи, яка оголошується здатною виконувати функції, обумовлені специфікацією. Цей спосіб - повна протилежність іншим, де тести будуються стосовно конкретних реалізацій. Незалежна від реалізації функціональна перевірка зазвичай приваблива лише в теоретичному плані, але практичного значення немає через високий рівень спільності.

Автоматизація стомлюючої роботи зі складання тестових програм не тільки скорочує тривалість періоду конструювання/налагодження за рахунок отримання тестових програм на етапі конструювання (оскільки вони можуть бути згенеровані відразу після формування вимог до системи), але й дозволяє проектувальнику змінювати специфікації, не переймаючись переписуванням усіх тестових програм. програм наново. Однак на практиці розробці тестів часто надають нижчий пріоритет у порівнянні з проектом, тому тестові програмиз'являються значно пізніше його завершення. Але навіть якщо детальні тестивиявляються підготовленими, часто практично недоцільно запускати їх на імітаторі, так як детальне моделювання вимагає великих витрат коштів на розробку програм і часу на обчислення, в результаті більшість роботи з налагодження повинна відкладатися до створення прототипу системи.

Після виявлення помилки має бути локалізовано її джерело, щоб провести корекцію на відповідному рівні абстрактного представлення системи та у відповідному місці. Помилкове визначення джерела помилки або проведення корекцій на іншому рівні абстрактного подання системи призводить до того, що інформація про систему на верхніх рівняхстає помилковою і не може бути використана для подальшого налагодження під час виробництва та експлуатації системи. Наприклад, якщо несправність внесена у вихідний текст програми, написаної мовою асемблера, а корекція проведена в об'єктному коді, то подальше налагодження програми ведеться в об'єктному коді; при цьому всі переваги написання програми мовою асемблера зводяться нанівець.

Структурна схема пристрою представлена ​​у додатку А.

Дана мікропроцесорна система складається з наступних блоків: мікропроцесор, ОЗП, ПЗП, програмований паралельний інтерфейс, аналого-цифровий перетворювач, таймер, дисплей.

Аналогові сигнали з датчиків надходять на входи аналогового мультиплексора, вбудованого в АЦП, який кожен інтервал часу комутує один із сигналів на вхід аналого-цифрового перетворювача.

Аналого-цифровий перетворювач служить перетворення аналогового сигналу в цифровий код, з яким оперує мікропроцесор.

Мікропроцесор звертається до АЦП через програмований паралельний інтерфейс. Зчитує інформацію з виходів АЦП, заносить її до осередку пам'яті ОЗУ. Крім того, МП на основі інформації, отриманої від датчика тиску нафти на виході станції, обчислює регулюючий вплив. Ця величина у вигляді цифрового кодупередається виконавчий механізм.

ОЗУ служить для тимчасового зберігання інформації, одержуваної з датчиків, та проміжних результатів розрахунків мікропроцесора.

Програмне забезпечення системи зберігається в ПЗУ (постійному пристрої). Операцією читання управляє мікропроцесор.

Програма, що зберігається у ПЗУ, передбачає такі операції системи:

Послідовне опитування датчиків;

Управління аналогово-цифровим перетворенням аналогового сигналу;

регулювання тиску нафти;

Індикація та сигналізація;

Реакція втрату харчування.

Розробка алгоритму системи

Структурна блок-схема алгоритму представлена ​​у додатку Б.

Ініціалізація

На цьому етапі відбувається запис керуючих слів у РУС програмованого паралельного інтерфейсу. ППІ DD10 працює у нульовому режимі. Порти працюють так: порт А - введення, порт В - висновок, порт С - висновок. ППІ DD1 працює у нульовому режимі. Порти працюють так: порт А - висновок, порт В - висновок, порт С - висновок.

Опитування датчиків

Опитування аналогових датчиків здійснює АЦП. Дискретні датчики через порт А ППІ 1 опитуються мікропроцесором.

Збереження у ОЗУ

Отримані після опитування датчиків результати заносяться в оперативний пристрій для тимчасового зберігання.

Керуючий вплив

Мікропроцесорна система аналізує дані, що надійшли, і виробляє цифровий керуючий вплив.

Розробка принципової схеми

Принципова схема пристрою представлена ​​у додатку Д.

Шина адреси формується за допомогою буферного регістра та шинного формувача. Вибір регістру здійснюється за допомогою сигналу мікропроцесора ALE. Шинний формувач необхідний підвищення навантажувальної здатності старшого байта адреси.

Шина даних формується за допомогою шинного формувача, вибір якого відбувається подачею сигналів DT/R та OE.

p align="justify"> Формування системної шини відбувається через дешифратор DD10 подачею поєднання сигналів M/IO, WR, RD.

Таблиця 1 - Управляючі сигнали

Вибір ПЗП, ОЗП та інших пристроїв відбувається за допомогою ліній А13-А15 шини адреси через дешифратор. Осередки ПЗУ розташовуються з адреси 0000h.

Таблиця 2 - Вибір пристроїв

			Пристрій

Вибір порту чи регістру керуючого слова ППІ здійснюється через лінії A0, A1 шини адреси. На входи порту А PA0-PA7 ППІ DD12 подаються дискретні датчики; на входи порту В – з АЦП; на входи порту С підключено світлодіоди.

Аналоговий мультиплексор служить вибору пристрою, з якого відбувається зчитування інформації. Аналоговий мультиплексор вбудований АЦП. Розрядність АЦП збігається із розрядністю шини даних і становить 8 біт.

Резистори R2-R4 служать перетворення уніфікованого струмового сигналу 4…20 мА в напругу 1…5В.

Натиснувши на кнопку "Завантажити архів", ви завантажуєте потрібний вам файл безкоштовно.
Перед скачуванням даного файлузгадайте про ті хороші реферати, контрольні, курсові, дипломні роботи, статті та інші документи, які лежать незатребуваними у вашому комп'ютері. Це ваша праця, вона повинна брати участь у розвитку суспільства та приносити користь людям. Знайдіть ці роботи та відправте в базу знань.
Ми та всі студенти, аспіранти, молоді вчені, які використовують базу знань у своєму навчанні та роботі, будемо вам дуже вдячні.

Щоб завантажити архів з документом, введіть п'ятизначне число в поле, розташоване нижче, і натисніть кнопку "Завантажити архів"

Подібні документи

Аналіз варіантів проектних рішень та вибір на його основі оптимального рішення. Синтез функціональної схеми мікропроцесорної системи з урахуванням аналізу вихідних даних. Процес розробки апаратного та програмного забезпечення мікропроцесорної системи.

курсова робота , доданий 20.05.2014


Теоретичні основирозробки мікропроцесорної системи на основі мікроконтролера та пристрою для читання електронних книг, аналіз їх техніко-економічних показників та порівняння з аналогами Основні норми з охорони праці під час роботи з комп'ютером.

дипломна робота , доданий 13.07.2010


Доцільність застосування МП-пристрою. Архітектура мікропроцесорної системи. Структурна організація БІС ВТ із ізольованими шинами. Зміст та можлива спрямованість мікроконтролера. Узагальнена структура простого мікроконтролера, що вбудовується.

реферат, доданий 28.04.2011


Структура мікропроцесорної системи, алгоритм її управління та передачі сигналів. Карта розподілу адрес. Розробка електричної принципової схемита вибір елементної бази. Розрахунок споживаного струму, блоку живлення, програмного забезпечення.

курсова робота , доданий 22.01.2014


Розподіл функцій між апаратною та програмною частинами мікропроцесорної системи. Вибір мікроконтролера, розробка та опис структурної, функціональної та принципової схеми. Вибір середовища програмування, схема алгоритму та лістинг програми.

курсова робота , доданий 17.08.2013


Призначення та влаштування мікропроцесорної системи контролю. Опис функціональної схеми мікропроцесорної системи контролю. Розрахунок статичної характеристики каналу виміру. Розробка алгоритму функціонування мікропроцесорної системи контролю.

курсова робота , доданий 30.08.2010


Загальне поняття про мікроконтролери, їх використання та призначення. Розробка проекту мікропроцесорної системи збирання даних з використанням стендів SDK 1.1 та SDX 0.9. Створення програмного забезпечення та його завантаження до лабораторного стенду SDK-1.1.

курсова робота , доданий 31.01.2014

Якісні та кількісні зміни елементної бази засобів ВТ призвели до

зміни сформованих принципів їх проектування (таких, як жорстка

структура, послідовне центральне управління, лінійна організація

пам'яті та відсутність можливості адаптації структури ЕОМ до особливостей

розв'язуваної задачі).

На зміну класичним фоннейманівським принципам організації обчислювальних систем прийшли ідеї проблемної орієнтації МПС, паралельної та конвеєрної обробки інформації, використання табличних методів обробки даних, принципи регулярності та однорідності структур МПС; стає реальною

можливістю ідея створення адаптивно-перебудовуваних систем, а також

апаратна реалізація функцій програмного забезпечення Тому в даний час

час під час проектування обчислювальних систем на основі МПС отримав

застосування так званий принцип «3М»: модульність, магістральність,

мікропрограмність.

Принцип модульної організаціїпередбачає побудову обчислювальних та

керуючих МПС на основі набору модулів: конструктивно, функціонально та

електрично закінчених обчислювальних пристроїв, що дозволяють самостійно

або разом з іншими модулями вирішувати завдання даного класу. Модульний

підхід при проектуванні мікроЕОМ та систем дозволяє (при реалізації як

універсальних, так і спеціалізованих модулів) забезпечити створення сімейств

(рядів) МПС, що відрізняються функціональними можливостямита характеристиками,

що перекривають значний діапазон застосувань, сприяє скороченню

витрат на проектування, а також спрощує нарощування потужності та

реконфігурацію систем, що відсуває час морального старіння обчислювальних

Магістральний спосіб обміну інформацієюна відміну способу організації

довільних зв'язків (за принципом «кожен з кожним») дозволяє впорядкувати та

мінімізувати кількість зв'язків у МПС. Він забезпечує обмін інформацією між

функціональними та конструктивними модулями різного рівня за допомогою

магістралей, що поєднують вхідні та вихідні шини. Розрізняють одно-, дво-,

три- та багатомагістральні зв'язки. Необхідно відзначити взаємозв'язок

схемотехнічних та структурних рішень, що виявляються при реалізації

даного способуобміну у вигляді створення спеціальних двонаправлених буферних

каскадів з трьома стійкими станами та використання тимчасового

мультиплексування каналів обміну.

Мікропрограмне управліннязабезпечує найбільшу гнучкість при організації

багатофункціональних модулів та дозволяє здійснити проблемну орієнтацію

МПС, а також використовувати в них макрооперації, що ефективніше за використання

стандартних підпрограм. Крім цього, передача керованих слів у вигляді

зашифрованих кодових послідовностей відповідає умовам мінімізації

числа висновків НВІС та скорочення числа міжз'єднань у модулях.

Крім перерахованих вище основних особливостей проектування МПС, слідує

відзначити принцип регулярності, який передбачає закономірну

повторюваність елементів структури МПС та зв'язків між ними. Застосування цього

принципу дозволяє збільшити інтегральну щільність, зменшити довжину зв'язків

на кристалі, скоротити час топологічного та схемотехнічного

проектування БІС та НВІС, зменшити кількість перетинів та типів функціональних

та конструктивних елементів.

При розробці архітектури МПС (системний етап) необхідно вирішити такі

Дати опис концептуальної структури функціональної поведінки системи з

позицій обліку інтересів користувача при її побудові та організації

обчислювального процесуу ній;

Визначити структуру, номенклатуру та особливості побудови програмних та

мікропрограмних засобів;

Описати характеристики внутрішньої організації потоків даних та керуючої

інформації;

Провести аналіз функціональної структури та особливості фізичної

реалізації пристроїв системи з позиції збалансованості програмних,

мікропрограмних та апаратурних засобів.

Основні етапи проектування МПС наведено на рис. 3.1.

На початковій стадії проектування МПС може бути описана на одному з

наступних концептуальних рівнів: “чорна скринька”, структурна, програмна,

логічний, схемний.

На рівні “чорної скриньки” МПС описується зовнішніми специфікаціями, де

перераховуються зовнішні властивості.

Мал. 3.1. Етапи проектування МПС

Структурний рівень створюється апаратними компонентами МПС, яка

описується функціями окремих пристроїв, їх взаємозв'язком та інформаційними

потоками.

Програмний рівень поділяється на два підрівні (команд процесора та

мовний) і МПС інтерпретується як послідовність операторів або

команд, які викликають ту чи іншу дію над деякою структурою даних.

Логічний рівень властивий виключно дискретним системам і поділяється на

два підрівні: перемикачових схем та регістрових пересилок.

Перший підрівень утворюється вентилями (комбінаційні схеми та елементи пам'яті) та побудованими на їх основі операторами обробки даних. Другий підрівень характеризується більш високим ступенем абстрагування і є описом регістрів і передачу даних між ними. Він включає в себе дві

частини: інформаційну та керуючу: перша утворюється регістрами,

операторами та шляхами передачі даних, друга забезпечує залежні від

часу сигнали, що ініціюють пересилання даних між регістрами.

Схемний рівень полягає в описі роботи елементів дискретних устройств.

У життєвому циклі МПС, як і будь-якої дискретної системи, виділяються три стадії:

проектування, виготовлення та експлуатація.

Кожна із стадій підрозділяється на кілька фаз, для яких існують ймовірності виникнення конструктивних чи фізичних несправностей. Несправності класифікують відповідно до їхніх причин: фізична, якщо причиною її є дефекти елементів, і суб'єктивна, якщо її причиною є помилки проектування.

Суб'єктивні несправності ділять на проектні та інтерактивні. Проектні

несправності викликані недоліками, що вносяться до системи на різних стадіях

реалізації вихідного завдання. Інтерактивні несправності виникають у

процесі роботи з вини обслуговуючого персоналу (оператора) Результатом

прояви несправності є помилка, причому одна несправність може

служити причиною цілого ряду помилок, а та сама помилка може бути викликана

безліччю несправностей.

Існує також поняття дефекту – фізична зміна параметрів

компонентів системи, що виходять за допустимі межі Дефекти називають

збоями, якщо вони мають тимчасовий характер, і відмовими, якщо вони постійні.

Дефект не може бути виявлений доти, доки не будуть створені умови для

виникнення через нього несправності, результат якої має бути, у свою

чергу, передано на вихід досліджуваного об'єкта для того, щоб зробити

несправність спостережуваної.

Діагностика несправності - процес визначення причини появи помилки по

результати тестування.

Налагодження – процес виявлення помилок та визначення

джерел їх появи за результатами тестування під час проектування МПС.

Засобами налагодження є прилади, комплекси та програми. Іноді під

налагодженням розуміють виявлення, локалізацію та усунення несправності. Успіх

налагодження залежить від того, як спроектована система, чи передбачені

властивості, що роблять її зручною для налагодження, а також від засобів, що використовуються

для налагодження.

Для проведення налагодження проектована МПС повинна мати

властивостями керованості, спостережуваності та передбачуваності.

Керованість –властивість системи, у якому її поведінка піддається

управлінню, тобто. є можливість зупинити функціонування системи в

певному стані та заново запустити систему.

Спостережуваність- Властивість системи, що дозволяє простежити за поведінкою

системи за зміною її внутрішніх станів.

Передбачуваність- властивість системи, що дозволяє встановити систему в

стан, з якого всі наступні стани можуть бути передбачуваними.

МПС за своєю складністю, вимогами та функціями можуть значно відрізнятися.

експлуатаційними параметрами, обсягом програмних засобів, типом

мікропроцесорного набору і т.д. У зв'язку з цим процес проектування може

видозмінюватися в залежності від вимог, які пред'являються до системи.

Процес проектування – ітераційний процес. Несправності, виявлені на етапі приймальних випробувань, можуть призвести до корекції специфікації, а

отже, до початку проектування всієї системи. Виявляти

несправності необхідно якомога раніше; для цього треба контролювати

коректність проекту кожному етапі розробки. Існують такі методи

контролю правильності проектування: верифікація (формальні методи

докази коректності проекту); моделювання; Тестування.

Останнім часом з'явилося багато робіт з верифікації програмного забезпечення.

забезпечення, мікропрограм, апаратури. Однак ці роботи поки що носять

теоретичний характер. Тому на практиці частіше використовують моделювання

поведінки об'єкта та тестування на різних рівнях абстрактного

уявлення системи.

На етапі формалізації вимог до системи контроль за коректністю проекту

особливо необхідний, оскільки багато цілей проектування не формалізуються або

неможливо знайти формалізовані у принципі. Функціональна специфікація може

аналізуватися колективом експертів або моделюватися та перевірятись у

дослідному порядку виявлення досягнення бажаних цілей. Після затвердження

функціональної специфікації починається розробка тестових програм,

призначених для встановлення правильності роботи системи відповідно до

її специфікацією. В ідеальному випадку розробляються тести, цілком

засновані на цій специфікації та дають можливість перевірки будь-якої

реалізації системи, яка оголошується здатною виконувати функції,

обумовлені у специфікації. Цей спосіб – повна протилежність іншим,

де тести будуються стосовно конкретних реалізацій. Однак на практиці

розробці тестів часто надають нижчий пріоритет у порівнянні з

проектом, тому тестові програми з'являються значно пізніше за нього