WWW.REFERATCENTRAL.ORG.UA - Я ТУТ НАВЧАЮСЬ

... відкритий, безкоштовний архів рефератів, курсових, дипломних робіт

ГоловнаІнформатика, Компютерні науки → Реалізація функцій DOS (CD, MD, RD, Date, Time, Dir) - Курсова робота

Реалізація функцій DOS (CD, MD, RD, Date, Time, Dir) - Курсова робота

На практиці здійснити арбітраж у цьому випадку досить просто. Під час передачі даних обидва передавачі точно синхронізують тактові імпульси. Якщо при передачі адреси біт, що повинний мати значення „1", насправді приймає значення „0", то це вказує на те що шина зайнята іншим пристроєм. У цьому випадку ведучий пристрій відключається від шини і чекає, коли наступить стан "кінець передачі", після якого повторює запит. Можливо, це важко зрозуміти по приведеному описі. У наступному розділі "Протокол CAN" буде показано, як теж саме відбувається з використанням асинхронної шини CAN, що має багато загального із шиною І2С.

Протокол І2С може бути легко реалізований програмним шляхом. Але при цьому швидкий режим не може бути реалізований через перевантаження процесора, навіть стандартний режим 100 Кбіт/с може виявитися занадто швидким для деяких мікроконтролерів. Програмна реалізація щонайкраще підходить тоді, коли в мережі мається тільки один ведучий пристрій. У цьому випадку немає необхідності синхронізуватися з іншими пристроями чи приймати повідомлення від інших ведучих пристроїв, що працюють із занадто великою швидкістю, що не забезпечується при програмній реалізації.

Протокол CAN

Протокол CAN (Controller Area Network) був розроблений компанією Bosch кілька років назад як мережне рішення для зв'язку комп'ютерних систем, застосовуваних в автомобілях. У той час не існувало єдиного стандарту для зв'язку цифрових пристроїв в автомобілях. До появи протоколу CAN (чи протоколу J1850, що є аналогічним американським стандартом) автомобілі містили до трьох миль проводів вагою понад 90 кг, що зв'язували різні автомобільні електронні пристрої. Протокол CAN був розроблений, щоб задовольняти наступним вимогам:

- Висока швидкість обміну (до 1 Мбіт/с).

- Нечутливість до електромагнітних перешкод.

- Простота, невелика кількість роз'ємних контактів (для

забезпечення механічної надійності).

- Легкість підключення і видалення пристроїв.

Протокол CAN подібний протоколу J1850 і ґрунтується на тих же перших двох рівнях семирівневої моделі OSІ, однак ці два стандарти електрично несумісні. Стандарт на протокол CAN з'явився раніш, тому даний стандарт реалізується практично у всіх моделях європейських і японських автомобілів, а в даний час активно використовується й американськими автомобільними компаніями.

Протокол CAN реалізується з використанням операції "монтажне И", що використовується також шиною І2С. Передача даних на фізичному електричному рівні реалізується за допомогою драйверів, що відповідають стандарту RS-485, що забезпечують видачу на лінію зв'язку диференціальної напруги. Така мережа буде працювати навіть якщо один із двох провідників закорочений чи обірваний, що особливо важливо для забезпечення надійності автомобільного устаткування. Використання з'єднання, що реалізує "монтажне И", дозволяє виконувати арбітраж між різними ведучими пристроями: коли вихідні драйвери пристроїв активні, то шина CAN переводиться в низький стан, аналогічно І2С.

Приклад реалізації цього методу арбітражу показаний на рис. 2.43. Коли сигнал, видаваний драйвером, не збігається з рівнем, встановленим на лінії передачі даних (наприклад, при видачі „1" на шині виявляється „0"), то драйвер зупиняє передачу даних доти поки не завершиться пересилання поточного повідомлення. Цей простий і ефективний спосіб арбітражу виключає необхідність повторної посилки повідомлення при виникненні колізій на шині.

Рисунок 16. Арбітраж при передачі по шині CAN

Кожне повідомлення являє собою окремий кадр у потоці даних, що пересилається. Кадр передається як фрагмент цього асинхронного послідовного потоку, у якому пересилання даних не супроводжується посилкою синхросигнала. При цьому приймач і передавач повинні працювати на одній частоті: звичайно швидкість обміну встановлюється в межах від 200 Кбіт/с до 1 Мбіт/с. Формат кадру передачі даних показаний на рис. 17.

Рисунок 17. Кадр передачі даних по шині CAN із використанням 11-бітного ідентифікатора

При використанні протоколу CAN нульове значення біта називається "домінантним", а одиничне значення - "рецессивним" (за аналогією з генами в біології).

Різні поля кадру мають наступне призначення:

SOF (Start Of Frame) - початок кадру, одиничний домінантний біт.

Ідентифікатор - 11-и чи 19-бітний ідентифікатор повідомлення.

RTR - Біт, що вказує, що ведучий пристрій є передавачем (при RTR=1) чи приймачем (при RTR=0) даних.

r1/r0 - Зарезервовані біти, що повинні бути домінантними.

DLC - 4 біти, що вказують кількість переданих байт.

Data - від 0 до 8 переданих байтів даних, де старший біт йде першим.

CRC - 15 бітний код контрольної суми, за яким випливає рецесивний біт.

Ack - 2-бітне поле підтвердження готовності (домінантний і рецесивний біти).

EOF (End Of Frame) - кінець кадру (поле, що містить не менш 7 рецесивних біт).

Останнє важливе зауваження, що стосується CAN, полягає в тому, що пристроям не даються специфічні імена чи адреси, повідомлення ідентифіковане (використовуючи 11-и чи 19-и бітний ідентифікатор повідомлення). Цей метод адресації може забезпечити дуже гнучкий обмін повідомленнями.

Кадр у протоколі CAN має складний формат, що ускладнює його обробку в процесі передачі і прийому повідомлення. Така обробка може виконуватися як апаратно, так і програмно, але рекомендується використовувати тільки апаратну реалізацію CAN. Ряд виробників вбудовують CAN-інтерфейс у мікроконтролери, що випускаються ними. Також існує декілька пристроїв, що серійно випускаються, (особливо популярна мікросхема Intel 82527), що ефективно і з мінімальними додатковими витратами виконують функції CAN інтерфейсу.

2. Переривання. Система переривань

Багато користувачів вважають, що переривання — це та частина апаратного забезпечення, якій краще дати спокій, тому що їхнє використання вимагає чудового знання процесора для розробки програми обробки переривання. У противному випадку при виникненні переривання система "засинає" чи "йде вразнос". Таке почуття звичайно з'являється в розробника після досвіду роботи з перериваннями для персонального комп'ютера, що має ряд особливостей, що ускладнюють створення оброблювача переривань. Багато з цих проблем не мають місця в устаткуванні, реалізованому на базі мікроконтролерів. Використання в даному устаткуванні переривань може істотно спростити його розробку і застосування.

У комп'ютерній системі переривання — це запуск спеціальної підпрограми (названої "оброблювачем переривання" чи "програмою обслуговування переривання"), що викликається сигналом апаратури. На час виконання цієї підпрограми реалізація поточної програми зупиняється. Термін "запит на переривання" (interrupt request) використовується тому, що іноді програма відмовляється підтвердити переривання і виконати оброблювач переривання негайно (рис. 2.19).

Переривання - подія, що виникає в комп'ютері і яку треба обробити. Обробити - не що інше, як викликати певну процедуру, обробник переривання.

У MS-DOS існує така класифікація переривань:

Апаратні - пов'язані з сигналом від зовнішнього пристрою;

Внутрішні - переривання, що генеруються самим процесором;

Програмні - генеруються програмою і викликають процедуру обробки переривань.

Команда звернення до переривання - int <номер_переривання>. Це далекий виклик переривань, він змінює регістри CS і IP.

Повернення з обробника переривань - iret. Ця команда відновлює змінені регістри, які зберігаються на стеку.

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

Рисунок 2.19 Виконання переривання

Перша можлива відповідь — "не реагувати на переривання, поки не завершиться виконання поточної задачі" — реалізується шляхом заборони (маскування) обслуговування запиту переривання. Після завершення задачі можливий один із двох варіантів: скидання маски і дозвіл обслуговування, що приведе до виклику оброблювача переривання, чи аналіз значення бітів ("пуллінг"), що вказують на надходження запитів переривання і безпосереднє виконання програми обслуговування без виклику оброблювача переривання. Такий метод обробки переривань використовується, коли потрібно забезпечити заданий час виконання основної програми, тому що будь-яке переривання може порушити реалізацію необхідного інтерфейсу.

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

Loading...

 
 

Цікаве