Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Микропроцессорные системы. Средства разработки программного обеспечения для микроконтроллеров семейства AVR. Учебное пособие
.pdf
81
Кроме показанных методов обработки прерываний, существует
масса их модификаций, которые зависят от многих факторов – задачи,
алгоритма работы программы, характеристик аппаратуры и т. п.
Если не удается организовать систему обработки прерываний так,
чтобы все временные характеристики обработчиков прерываний были
удовлетворительны, то, возможно, это означает, что для решения задачи
был выбран недостаточно производительный микроконтроллер и стоит
изменить аппаратную часть устройства.
9.5. Драйвера устройств
Драйвер устройства – логически завершенный программный мо-
дуль управления устройством, имеющий интерфейс для общения с дру-
гими программными модулями.
Можно считать, что драйвер – это программный модуль, реализующий абстрактное представление устройств микропроцессорной системы.
В операционных системах, как правило, существует регламент, ко-
торый определяет, как описывается программный интерфейс драйвера
устройства и каким образом производится взаимодействие с устрой-
ством ядра ОС и программ пользователя.
При проектировании программы для микроконтроллеров без опера-
ционной системы, разработчик волен описывать взаимодействие с устройствами произвольным образом. С практической стороны удобнее всего
строить программу таким образом, при котором программные модули работы с внешними устройствами являются полностью самостоятельными еди-
ницами, которые для устройств одного типа являются взаимозаменяемыми.
Такой подход обеспечивает переносимость программ, причем не
только между микроконтроллерами одного семейства, но и между абсо-
лютно различными микропроцессорными архитекторами.
В большинстве случаев для каждого устройства можно выделить
несколько общих, не зависящих от типа устройства, программных блоков драйвера устройства: программный блок инициализации устройства; программный блок непосредственной работы с устройством; про-
граммный блок завершения работы с устройством.
Этот подход к описанию устройств хорошо отразился в концепции
построения UNIX-подобных ОС – там все устройства абстрактно пред-
ставлены в виде файлов, имеющих стандартные функции инициализа-
ции, чтения данных, записи данных и так далее.
Несмотря на то, что в настоящем пособии рассматривается по-
строение ПО для микроконтроллера без использования ОС, ничего не
мешает использовать для написания драйверов устройств описанный
подход. Для простоты, будем использовать названия функций, анало-
82
гичные тем, что используются в UNIX-подобных ОС. Тогда любое
устройство можно описать всего несколькими функциями:
int dev_open(const char* name); – инициализирует (открывает)
устройство и выделяет для работы с устройством ресурсы. Возвращает
id – идентификатор устройства (положительное число) или код ошибки
(отрицательное число);
int dev_close(int id); – завершает работу с устройством (закры-
вает устройство) и освобождает выделенные ранее для работы с устройством ресурсы. Параметр id – идентификатор устройства. Возвращает 0
(код успешного завершения) или код ошибки (отрицательное число);
int dev_write(int id, const void *buf, size_t count); – осуществ-
ляет запись данных в устройство. Параметры: id – идентификатор
устройства; buf – указатель на буфер с данными для записи в устройство; count – количество записываемых данных, в байтах. Возвращает
реально записанное число байт (положительное число) или код ошибки
(отрицательное число);
int dev_read(int id, const void *buf, size_t count); – осуществ-
ляет чтение данных из устройства. Параметры: id – идентификатор
устройства; buf – указатель на буфер, куда будут помещаться считанные
данные; count – количество считываемых данных, в байтах. Возвращает
реально считанное из устройства число байт (положительное число) или
код ошибки (отрицательное число);
int dev_ioctl(int id, int request, …); – вызов специфической
функции для устройства. Параметры: id – идентификатор устройства;
request – номер функции устройства; остальные параметры произволь-
ные и зависят от конкретного устройства.
Разумеется, что для экономии памяти устройства можно обозна-
чать не строковыми именами, как в примере, а числовыми идентификаторами; использовать для принимаемых и возвращаемых значений более
короткие типы (например, signed char). Это не меняет общего принципа
описания устройств.
Недостатки такого подхода очевидны – увеличенный расход памяти и накладные расходы на выполнение вызовов.
Однако это дает огромные преимущества в плане переносимости
программного обеспечения; возможности отладки алгоритмов работы
программы на персональном компьютере с эмуляцией внешних
устройств и так далее.
Какой из подходов выбрать – реализовывать уровень абстракции
внешних устройств или реализовывать свой интерфейс для каждого
внешнего устройства – решает разработчик.
83
10. ОБМЕН ДАННЫМИ МЕЖДУ МПУ
Важнейшей частью проектирования ПО МПУ являются модули
обмена данными между несколькими МПУ. Разумеется, такой обмен
данными происходит, только если МПУ предназначено для работы в составе РМПС. Рассмотрим некоторые особенности алгоритмов обмена
данными между МПУ.
10.1. Протокол обмена данными между МПУ
При разработке любой РМПС следует определить протоколы об-
мена данными между МПУ. Предположим, что необходимо разработать
протокол обмена, отвечающий нескольким требованиям:
протокол должен быть пакетно-ориентированный, адресный;
возможность обмена пакетами с подтверждением или без под-
тверждения;
каждый пакет должен содержать уникальный идентификатор;
протокол должен иметь средства контроля целостности пакета.
Рассмотрим подробнее каждое требование к протоколу.
Протокол должен быть пакетно-ориентированный, адресный.
Поскольку РМПС имеет в своем составе несколько МПУ, то необ-
ходима их адресация для указания приемника (получателя) и источника
(отправителя) каждого пакета данных.
Следует учесть, что различные каналы связи имеют различные си-
стемы адресации. Например, в сети Интернет имеется адрес IP, в теле-
фонной сети адресом является уникальный телефонный номер и т. п.
Ввиду того, что РМПС в общем случае использует для передачи
данных различные каналы связи, то нельзя привязать МПУ к системе
адресации какого-либо одного канала связи.
Чтобы не привязываться к системе адресации какого-либо одного
канала связи, присвоим каждому МПУ уникальный в данной РМПС номер. Данный номер позволяет однозначно идентифицировать отправителя и получателя пакета данных, что является удобным с точки зрения
функций обработки пакетов данных. Будем называть этот уникальный
номер МПУ адресом МПУ. Адрес МПУ, привязанный к системе адресации конкретного канала связи, будем называть канальным адресом
МПУ.
В связи с тем, что у каждого канала связи в общем случае своя си-
стема адресации, возникает задача преобразования адреса МПУ в канальный адрес МПУ. Рассмотрим два способа решения этой задачи, за-
висящих от структуры РМПС.
84
Способ 1. РМПС с равноправной структурой.
В такой РМПС каждое МПУ может передать пакет данных любому
другому МПУ. Поэтому, в общем случае, каждое МПУ должно хранить
таблицу преобразования адресов, в которой для каждого канала связи
указаны адрес МПУ и соответствующий ему канальный адрес МПУ.
Достоинство такого подхода – универсальность. Недостатки –
большой объем таблицы преобразования адресов и сложность замены
таблиц на всех МПУ, входящих в РМПС, при добавлении, удалении или
изменении номера хотя бы одного из МПУ.
Способ 2. РМПС с иерархической структурой (рис. 14) представ-
ляет собой древовидную структуру, включающую в себя несколько
уровней. В приведенном примере на различных уровнях располагаются
пронумерованные МПУ с условными названиями «центр» и «абонент».
В такой РМПС каждое МПУ может передать пакет данных непо-
средственно только на уровень ниже (одному из подчиненных МПУ)
или на уровень выше (вышестоящему центру). Таким образом, МПУ
должно хранить таблицу преобразования адресов только для непосредственно связанных с ним других МПУ – подчиненных и вышестоящего
центра. Это позволяет сократить размер таблицы преобразования адре-
сов по сравнению со способом 1.
Передача пакета данных между двумя произвольными МПУ в
РМПС с иерархической структурой осуществляется в общем виде путем
пересылки через несколько уровней иерархии, что влечет за собой появ-
ление задачи поиска маршрута передачи пакета данных.
Выберем размер адреса МПУ для нашего протокола равным 32 бита,
что позволяет обеспечить адресацию до 2
32
=4294967296 МПУ.
Рис. 14. Пример РМПС с иерархической структурой
Абонент 2.1
Уровень иерархии
Абонент 2.2 Абонент 2.3 Абонент 2.4 Абонент 2.5 Абонент 2.6
Центр 1.1 Центр 1.2
Центр 0.1
0
1
2
85
Возможность обмена пакетами с подтверждением или без под-
тверждения.
В зависимости от типа передаваемой информации и конкретной
задачи получатель может подтверждать или не подтверждать получение
пакета данных.
Как правило, не требуют подтверждения, например, широковещательные пакеты и пакеты, содержащие аудио- и видеоинформацию, передаваемую в реальном времени.
Таким образом, в пакете данных необходимо иметь следующую
информацию:
требует пакет данных подтверждения о получении или нет;
является ли пакет пакетом с данными для получателя или под-
тверждением для отправителя.
Введем два флага, передаваемых с каждым пакетом данных:
QACK – размер 1 бит, если сброшен в 0, то пакет не требует под-
тверждения, если установлен в 1, то пакет требует подтверждения о до-
ставке;
ACK – размер 1 бит, если сброшен в 0, то пакет является пакетом
с данными, если установлен в 1, то пакет является подтверждением о
доставке. Если флаг ACK=1, то флаг QACK всегда считается равным 0,
так как подтверждение не требует подтверждения.
Каждый пакет должен содержать уникальный идентификатор
с целью отличия его от других пакетов, передаваемых между двумя
МПУ. Уникальный идентификатор служит для диагностики пропадания
конкретного пакета данных в канале связи, диагностики повторной доставки пакета данных, а также для идентификации подтверждений доставки данных. Обычно в качестве уникального идентификатора пакета
выступает псевдослучайное число, которое пересылается вместе с паке-
том данных. Уникальные идентификаторы пакета данных и пакетаподтверждения о доставке этого пакета данных совпадают.
Протокол должен иметь средства контроля целостности паке-
та. Каналы связи не являются надежными, и информация при передаче
по ним может искажаться вследствие многих причин. Для отбраковки
искаженных пакетов необходим один из способов контроля целостности
данных в пакете. Используем широко распространенный алгоритм кон-
троля целостности путем вычисления 16-разрядной циклической контрольной суммы пакета CRC16 [7]. При передаче пакета МПУ-
отправитель вместе с данными передает и контрольную сумму пакета.
При приеме пакета МПУ-получатель вычисляет CRC16 принятого пакета и сравнивает ее с принятой от МПУ-отправителя контрольной сум-
мой. Если вычисленная и принятая контрольные суммы CRC16 не сов-
86
падают, то считается, что пакет принят с искажениями, и такой пакет
игнорируется.
Построим структуру пакета данных на основании принятых соображений (табл. 4).
Таблица 4
Структура пакета данных протокола передачи данных
DA
SA F ID
LEN
DATA
CRC16
4 байта
4 байта
1 байт
1 байт
2 байта
LEN байт
2 байта
Заголовок
Данные
Контроль
Описание полей пакета:
DA – адрес приемника, т. е. МПУ-получателя пакета.
SA – адрес источника, т. е. МПУ-отправителя пакета.
F – флаги:
ACK – 0-й бит, размер 1 бит, если сброшен в 0, то пакет не
требует подтверждения, если установлен в 1, то пакет требует
подтверждения о доставке;
QACK – 1-й бит, размер 1 бит, если сброшен в 0, то пакет яв-
ляется пакетом с данными, если установлен в 1, то пакет является подтверждением о доставке. Если флаг ACK=1, то флаг
QACK всегда считается равным 0, так как подтверждение не
требует подтверждения.
Биты 2–7 – резерв, всегда равны 0.
ID – уникальный идентификатор пакета.
LEN – длина данных (поля DATA) в байтах. LEN =[0...65535].
Если LEN=0, то поле DATA отсутствует.
CRC16 – циклическая контрольная сумма полей DA, SA, F, ID,
LEN, DATA.
Разработанный протокол обмена данными фактически описывает
только транспортный уровень (согласно рис. 16). Нижележащие уровни
обеспечиваются драйвером конкретного оборудования и протоколами
нижнего уровня (если таковые есть).
На вышележащий, прикладной, уровень передаются данные (поле
DATA), а также дополнительная информация в виде полей SA, DA, ID.
10.2. Алгоритмы обработки пакетов данных
Составим общие алгоритмы обработки пакетов данных разработанного протокола обмена данными между МПУ.
87
Прием пакета данных
Алгоритм приема пакета данных представлен на рис. 15.
Поясним некоторые обозначения на представленном алгоритме:
CRC – вычисленная циклическая контрольная сумма пакета дан-
ных;
CRC16 – принятая вместе с пакетом данных циклическая кон-
трольная сумма;
DA – адрес приемника, принятый в пакете данных;
Adr – адрес МПУ, принимающего пакет.
Двойной рамкой отмечены блоки алгоритма, осуществляющие об-
работку принятого пакета данных.
Рис. 15. Алгоритм приема пакета данных
Приём пакета
Таймаут?
Начало
Да
Нет
DA=Adr ?
Да
Нет
CRC16 = CRC?
Да
Нет
ACK=1
Да
Нет
Обработка
подтверждения
QACK=1
Да
Нет
Обработка
пакета данных
Отправка
подтверждения
88
Передача пакета данных
Алгоритм передачи пакета данных (рис. 16) зависит от режима передачи – с подтверждением или без подтверждения.
Рис. 16. Алгоритм передачи пакета данных
Тип передачи пакета данных (с подтверждением или без подтверждения) определяется по флагу QACK в заголовке пакета.
Если передача пакета производится без подтверждения (QACK=0),
то после передачи пакета в канал связи алгоритм завершается.
Если пакет требует подтверждения о доставке (QACK=1), то после
передачи пакета в канал связи некоторое время (тайм-аут) ожидается
прием подтверждения на данный пакет. При получении подтверждения
алгоритм завершается. Если подтверждение не получено в течение заданного времени, то фиксируется ошибка передачи, которая обрабаты-
вается обработчиком ошибок.
Передача пакета
Таймаут?
Начало
Да
Нет
QACK=1
Да
Нет
Обработка
ошибки
Получено
подтверждение?
Да
Нет
Конец
89
СПИСОК ЛИТЕРАТУРЫ
1. Голубцов М.С. Микроконтроллеры AVR : от простого к сложному /
М.С. Голубцов. – Москва : СОЛОН-Пресс, 2003. – 288 с.
2. Хартов В.Я. Микроконтроллеры AVR. Практикум для начинаю-
щих / В.Я. Хартов. ‒ 2-е изд. – Москва : МГТУ им. Н.Э. Баумана,
2012. – 354 с.
3. Рэймонд Э. Искусство программирования для Unix / Э. Рэймонд. –
Москва : Вильямс, 2005. ‒ 544 с.
4. Стивенс У.Р. UNIX. Профессиональное программирование /
У. Р. Стивенс, С. Раго. ‒ 2-е изд. – Санкт-Петербург : Символ-Плюс,
2007. – 1040 с.
5. Managing Projects with GNU Make [Электронный ресурс] // O'Reilly
Media, Inc., 2004. – Режим доступа : http://shop.oreilly.com/product/
9780596006105.do, свободный. – Загл. с экрана.
6. Франка П. C++: учебный курс / П. Франка. – Санкт-Петербург : Пи-
тер, 2003. – 521 с.
7. Тревор М. Микроконтроллеры ARM7. Семейство LPC2000 компа-
нии Philips. Вводный курс / М. Тревор. – Москва : Додека XXI век,
2006 – 240 c.
8. Documentation for binutils. Linker Scripts [Электронный ресурс]. –
Режим доступа : https://sourceware.org/binutils/docs/ld/Scripts.html,
свободный. – Загл. с экрана.
9. Barryr R. Using the freertos real time kernel / R. Barryr. – 2009. – 163 c.
Учебное издание
СОНЬКИН Михаил Аркадьевич
ШАМИН Алексей Алексеевич
МИКРОПРОЦЕССОРНЫЕ СИСТЕМЫ
СРЕДСТВА РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ДЛЯ МИКРОКОНТРОЛЛЕРОВ СЕМЕЙСТВА AVR
Учебное пособие
Редактор В.Ю. Пустовалова
Компьютерная верстка О.Ю. Аршинова
Дизайн обложки Т.В. Буланова
Подписано к печати 10.05.2016. Формат 60х84/16. Бумага «Снегурочка».
Печать CANON. Усл. печ. л. 5,23. Уч.-изд. л. 4,73.
Заказ 417-16. Тираж 100 экз.
3
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]