Разработка автономного аппаратно-программного комплекса средств для подсистемы управления "Роботом-дозиметристом"

/

/

Аннотация

«Робот-дозиметрист» представляет собой довольно сложную вычислительную систему, состоящую из нескольких узлов. При выходе из строя какого-нибудь из его узлов весь робот может выйти из строя, особенно если этим узлом станет бортовой ПК, который отвечает за все внутренние процессы робота. Основной проблемой данной реализации робота является малая дистанция передачи данных. Для обеспечения дополнительной безопасности системы и увеличения дальности передачи данных, было принято решение, разработать автономный аппаратно-программный комплекс средств для подсистемы управления “Роботом - дозиметристом”.

Первая глава работы посвящена сбору предварительной информации необходимой для разработки платы. В частности, проанализирована общая структурная схема разрабатываемого робота. Основываясь на этом анализе мы так же рассматриваем основные проблемы которые могут возникнуть при работе робота. Во второй главе производится анализ существующих способов передачи информации на большие расстояния и там же составляется основной список требований разрабатываемой системе.

Третья глава посвящена проектированию подсистемы управления, нашедшей своё отображение в виде двух контроллеров: котроллера оператора и бортового контроллера. Глава состоит из проектирования принципиальных электрических схем контроллеров и трассировке плат этих контроллеров.

Четвёртая глава содержит в себе разработку протокола гарантированной доставки сообщений по радио каналу и разработку управляющей программы для взаимодействия контроллеров.

Пятая глава посвящена тестированию печатных плат и тестированию протокола гарантированной доставки сообщений. В Приложении 1 так же приведено руководство пользователя для созданной платы управления датчиками.

Оглавление

ВВЕДЕНИЕ

1. ОБЗОРНАЯ ЧАСТЬ

1.1 Робот-дозиметрист (проект НИЯУ МИФИ): назначение, краткая характеристика, перспективы внедрения.

1.2 Робот-дозиметрист (проект НИЯУ МИФИ): архитектурная концепция, основные составные узлы.

1.2.1 Контроллер управления двигателями

1.2.2 Аккумуляторы для питания блока управления

1.2.3 Бортовой ПК

1.3 Обзор общей функциональной схемы “Робота - дозиметриста”.

2. НАХОЖДЕНИЕ ОПТИМАЛЬНОГО СПОСОБА ДОПОЛНИТЕЛЬНОГО КОНТРОЛЯ РОБОТА

2.1 Обзор способов беспроводной передачи данных на большие расстояния.

2.2 Основные требования к контроллерам.

3. РАЗРАБОТКА АППАРАРАТНОЙ ЧАСТИ КОНТРОЛЛЕРА ОПЕРАТОРА И БОРТОВОГО КОНТРОЛЛЕРА.

3.1 Проектирование принципиальной схемы контроллера оператора.

3.2 Проектирование принципиальной схемы бортового контроллера.

3.3 Трассировка печатных плат.

4. РАЗРАБОТКА ПРОГРАМНОЙ ЧАСТИ КОНТРОЛЛЕРОВ.

4.1 Алгоритм взаимодействия контроллеров.

4.1.1 Формат пакетов.

4.1.2 Протокол обмена данными.

4.1.3 Возможные ситуации при передаче данных по протоколу.

4.1.4 Блок-схемы основных функций протокола.

4.2 Общий алгоритм программы.

5. ТЕСТИРОВАНИЕ И ОТЛАДКА СПРОЕКТИРОВАННЫХ УСТРОЙСТВ.

5.1 Тестирование печатных плат

5.2 Отладка программной части контроллеров

СПИСОК ЛИТЕРАТУРЫ

ПРИЛОЖЕНИЕ 1. РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ.

ВВЕДЕНИЕ

В настоящее время робототехника является одной из самых динамично развивающихся прикладных наук. Задача робототехники - проектирование, производство и ввод в эксплуатацию автоматизированных технических систем. Опорой для этой науки служат такие дисциплины как электроника, механика, программирование. В последнее десятилетие, к ведущей роле робототехники в выполнении задач автоматизации производственных процессов прибавилось так же задачи автоматизации практически всех сфер человеческой деятельности - от работы в открытом космосе до решения самых простых бытовых проблем.

Для описания эволюции роботов можно воспользоваться теорией профессора Университета Карнеги-Меллона (Пенсильвания, США) Ханса Моравеца, согласно которой созданные человеком роботы должны пройти 4 этапа эволюции. Условное первое поколение он уподобил по своему интеллектуальному потенциалу ящерице, ко второму отнёс роботов с возможностью накопления знаний (обучения) и уподобил их мышам (по его же прогнозу, такие роботы появятся к 2020 году). Третье поколение роботов должно иметь интеллект сопоставимый с обезьяной. И, наконец, четвёртое поколение он уподобил человеку, однако, появление таких роботов профессор предсказал никак не ранее второй половины 21 века.

Подавляющее большинство существующих и готовящихся к производству роботов обладает сравнительно малым интеллектуальным потенциалом, поэтому, их возможно квалифицировать в зависимости от цели назначения, либо по используемым компонентам. В частности, разделив роботы по способу передвижения, можно выделить колёсные роботы (одноколёсные, двухколёсные, трёхколёсные, четырёхколёсные, многоколёсные), шагающие роботы (использующие две, четыре, шесть ног, либо многоногие), плавающие роботы (надводные и подводные), летающие и другие (прыгающие, подражающие движением змеи и т.д.). Так же роботы актуально квалифицировать в зависимости от используемой движущей силы и систем управления.

Настоящая работа посвящена проектированию одной из составных частей колёсной передвижной платформы «Робота-дозиметриста» - а именно, подсистеме управления.

Для успешного выполнения задачи необходимо:

- провести анализ проектных решений для устранений возможных неисправностей в разрабатываемом роботе;

- проанализировать способы дистанционной передачи данных;

- спроектировать функциональную схему бортового вычислительного блока Робота-дозиметриста;

- провести анализ микроконтроллеров для разработки системы;

- спроектировать функциональную и принципиальные схемы плат подсистемы управления Роботом-дозиметристом и произвести трассировку в системе автоматизированного проектирования P-cad;

- закупить комплектующие и изготовить спроектированные платы;

- провести монтаж и отладку изготовленных плат;

- написать управляющую программу для взаимодействия контроллеров;

- протестировать спроектированные платы;

- протестировать управляющую программу;

- составить руководство пользователя.

Первая глава работы посвящена сбору предварительной информации необходимой для разработки платы. В частности, проанализирована общая структурная схема разрабатываемого робота. Основываясь на этом анализе мы так же рассматриваем основные проблемы которые могут возникнуть при работе робота.

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

Третья глава посвящена проектированию подсистемы управления, нашедшей своё отображение в виде двух контроллеров: котроллера оператора и бортового контроллера. Глава состоит из проектирования принципиальных электрических схем контроллеров и трассировке плат этих контроллеров.

Четвёртая глава содержит в себе разработку протокола гарантированной доставки сообщений по радио каналу и разработку управляющей программы для взаимодействия контроллеров.

Пятая глава посвящена тестированию печатных плат и тестированию протокола гарантированной доставки сообщений. В Приложении 1 так же приведено руководство пользователя для созданной платы управления датчиками.

1. ОБЗОРНАЯ ЧАСТЬ

1.1 Робот-дозиметрист (проект НИЯУ МИФИ): назначение, краткая характеристика, перспективы внедрения

Универсальная робототехническая платформа «Робот - дозиметрист» - разрабатываемое в рамках научных программ НИЯУ МИФИ многофункциональное устройство, основное предназначение которого - удалённый сбор данных и получение максимально-подробных сведений об окружающей среде, в том числе, в условиях, непригодных для работы человека. В соответствии со своим назначением, проектируемое устройство должно обладать следующими характеристиками:

- повышенной прочностью конструкции и надёжности аппаратуры, в том числе, радиационной стойкостью всех устройств робота не менее 10000 рентген/час при гамма-излучении

- возможностью максимально-удалённой от оператора работы, либо полностью автономной работы

- мобильностью (возможность передвигаться со скоростью не менее 15 кмч, размеры не более чем 500х500х500 мм)

- временем работы без подзарядки в любых условиях не менее часа

- возможностью автономной ориентации на местности (самостоятельный объезд препятствий, сбор сведений о местоположении встречаемых предметов относительно друг друга для дальнейшей передачи оператору)

- наличием датчиков, достаточных для полного анализа радиоактивной обстановки

- универсальностью (возможностью, как подключения дополнительных датчиков, так и замены существующих в зависимости от выполняемой задачи без изменения конструкции и серьёзных программных модификаций)

- экономической привлекательностью относительно зарубежных робототехнических платформ

Робот, отвечающий всем приведённым выше требованиям, станет уникальным, не имеющим аналогов продуктом, в первую очередь предназначенным для предприятий, работающих в сфере атомной энергетики. Так же, подобный робот, благодаря своей универсальности, может успешно конкурировать с зарубежными и немногочисленными российскими робототехническими платформами, созданными для нужд полиции и специальным служб.

1.2 Робот-дозиметрист (проект НИЯУ МИФИ): архитектурная концепция, основные составные узлы

Разрабатываемый робот представляет собой четырёхколёсную тележку с 2 ведущими колёсами. Такая компоновка позволяет обеспечить оптимальные ходовые характеристики при необходимом уровне проходимости. В качестве мотор-колёс используются колёса HUB24E производства компании GoldenMotor(рис 1.1).

Рис. 1.1. Мотор-колесо HUB24E

Технические характеристики мотор-колёс приведены ниже:

- номинальное напряжение питания: 12/24/36 В;

- максимальная мощность:100-300 Вт;

- вес: 4.8 кг.

Структурная схема связи элементов робота, размещённых на тележке, представлена на рис 1.2. Так же на схеме показана модель связи с удалённым оператором.

Концепция проектируемого робота предлагает разбиение его составных частей на 3 узла: блок сбора данных, систему видеонаблюдения и блок управления. В центре этой системы находится бортовой ПК, связанный с каждым из 3 узлов по USB-интерфейсу. Кроме этого, по штатному Wi-Fi каналу бортовой ПК связан с клиентской системой (постом оператора).

В целом, блок управления отвечает за механическое передвижение робота. Он состоит из контроллера управления двигателями, самих двигателей. Он связан с бортовым ПК через проводник USB-COM.

Система видеонаблюдения состоит из 2 видеокамер и контроллера видеоизображения.

Блок сбора данных состоит из платы управления датчиками, отвечающей за сбор данных с самих датчиков и передачу её на бортовой ПК. Блок сбора данных имеет автономную систему питания.

Рис. 1.2. Cтруктурная схема «Робота-дозиметриста»

1.2.1 Контроллер управления двигателями

Для управления двигателями выбран двухканальный контроллер ax3500 американской фирмы RoboteQ (рис. 1.3), предназначенный для преобразования команд, полученных от беспроводного модема, аналогового джойстика или другого микроконтроллера в ток высокого напряжения для управления одним или двумя двигателями постоянного тока. Два канала контроллера могут работать независимо или в паре для задания направления движения либо вращения движимого объекта путём координации движения с 2 сторон объекта.

Рис. 1.3. Двухканальный контроллер управления двигателями RoboteQ ax3500

Технические характеристики контроллера:

- рабочее напряжение: от 12 до 40 В постоянного тока;

- количество каналов: 2;

- ток: 40А постоянный, 60A Max;

- ограничение по току: по автоматическому снижению выходной мощности в зависимости от нагрузки и прошедшего времени;

- защита по температуре: автоматически, начиная от 80 С;

- защита по напряжению: отключение при значении ниже 12 и выше 43В:

- коррекция на входах: программируемая;

- операционная температура: От -40 до +85 ° С (температура радиатора);

- способ охлаждения: радиатор;

- размеры: 106 х 172 х 30 мм;

- вес 212 грамм;

- возможность использования:

- двух R / C входов;

- последовательного интерфейса RS232;

- двух входов аналогового интерфейса;

- разъёмов для двух дополнительных оптических энкодеров (максимум 125 кГц);

- 8 выходов R / C сервоприводов;

- двух входов цифрового интерфейса, одного выхода (максимально

24 В, 2 А);

- контроля скорости при движении вперёд или назад;

- тахометра на аналоговых входах;

- потенциометра на аналоговых выходах.

1.2.2 Аккумуляторы для питания блока управления

В качестве аккумулятора для питания мотор-колёс используются герметизированные, свинцово-кислотные аккумуляторные батареи CSB HR 12120W, высокоэффективные и обладающие большой энергоемкостью.

Имея небольшие массогабаритные показатели, батареи обеспечивают работу более 260 циклов заряда-разряда до 100% степени разряда в циклическом режиме или 3-5 лет эксплуатации в буферном режиме. Основное достоинство данных батарей - это специальная конструкция решетки, позволяющая повысить выходную мощность на 20%. Они наиболее приспособлены к использованию в высокомощном оборудовании и источниках бесперебойного питания. Батареи герметизированы, не нуждаются в обслуживании и в доливке водой, могут работать как в буферном, так и в циклическом режимах. Они могут эксплуатироваться в любом положении, имеют очень низкий уровень саморазряда и низкое сопротивление.

Характеристики:

- страна производства: Тайвань;

- выполнены по AGM-технологии;

- напряжение: 12 В;

- ёмкость: 30 Ач;

- длина 166 мм;

- ширина 125 мм;

- высота 166.5 мм;

- высота с клеммой: 175 мм;

- вес 10.7 кг;

- срок службы 5 лет;

- количество элементов в блоке: 6;

- максимальный ток разряда 400 (5 сек);

- внутреннее сопротивление 9 мОм;

- диапазон рабочих температур:

- разряд: -20°С ~50°С

- заряд : 0°С ~40°С

- хранение : -20°С ~40°С

- оптимальная рабочая температура: 25°С;

- напряжение подзаряда: 13,5 до 13,8 В при 25°С;

- максимальный ток заряда: 12 А;

- напряжение заряда при циклическом режиме: 14,4 до 15,0 В при 25°С

- саморазряд: батареи CSB могут храниться 6 месяцев без подзарядки при 25°С. При более высокой температуре - время хранения уменьшается;

- материал корпуса: ABS (акрило-бутадиен-стирол).

1.2.3 Бортовой ПК

Основным бортовым вычислительным узлом проектируемого робота-дозиметриста является нетбук Acer Aspire One. С помощью 3USB-портов нетбук связан с контроллером управления двигателями, платой управления датчиками, а так же с бортовыми органами зрения (веб-камерами). Через штатную систему беспроводной связи нетбука (Wi-fi) осуществляется связь робота с оператором. Формируемая посылка от робота к оператору содержит информацию о состоянии окружающей среды с платы управления датчиками и с веб-камер. В обратную сторону, оператор может выдавать задания роботу по автономному исследованию определённой местности, либо управлять роботом вручную в режиме реального времени.

1.3 Обзор общей функциональной схемы “Робота - дозиметриста”

Универсальная робототехническая платформа «Робот - дозиметрист» - разрабатываемая в рамках научных программ НИЯУ МИФИ многофункциональное устройство, основное предназначение которого - сбор данных и получение максимально-подробных сведений об окружающей среде в условиях, непригодных для работы человека.

«Робот - дозиметрист» состоит из нескольких основных узлов: блока сбора данных, системы видеонаблюдения и блок управления. В центре этой системы находится бортовой ПК, связанный с каждым из 3 узлов по USB-интерфейсу. Кроме этого, по штатному Wi-Fi каналу бортовой ПК связан с клиентской системой (постом оператора). В связи с этим, при постоянном использовании робота может возникнуть ряд проблем, которые смогут помешать выполнению поставленной задачи. Ниже, более подробно, рассматриваются эти проблемы.

Основными программно-аппаратными проблемами являются:

· Потеря сигнала Wi-Fi;

· Выход из строя контроллера управления датчиками;

· Выход из строя контроллера управления двигателями;

· Выход из строя бортового ПК.

По штатному Wi-Fi каналу бортовой ПК связан с клиентской системой (постом оператора). По этому, потеря Wi-Fi сигнала приведёт к невозможности управлять роботом и следить за показанием датчиков. Это одна из самых серьёзных и часто встречающихся проблем. Она может возникать в различных ситуациях. Wi-Fi сети поддерживают роуминг, поэтому клиентская станция может перемещаться в пространстве, переходя от одной точки доступа к другой.

Имеет большое значение расположение 'точки доступа' или беспроводного свитча/роутера и всех кто будет подключен через эту 'беспроводную сеть' (клиентские машинки). Передача данных идет (в основном) по прямой, по кратчайшему расстоянию. Имеет значение количество и материал преград на пути сигнала (стены, окна-двери, мебель и т.п.). Наилучший вариант - когда все в одном 'ангаре' без преград, наихудший вариант - когда много преград из железобетона, железа. Может быть проблемой и одна стенка, если она расположена почти параллельно пути сигнала, но сигналу нужно через нее пройти.

Реалии таковы, что для передачи на большие расстояния, нужно или увеличивать мощность передатчика в роутере или применять наружную антенну и увеличивать чувствительности по приему. Для первого и второго варианта, необходимо зарегистрировать радиочастоту.

Плата управления датчиками представляет собой контроллер, имеющий свой собственный источник питания, отличный от основного (двух аккумуляторов CSBHR 12120W). К этому контроллеру подключены оптические датчики, ультразвуковые датчики, акселерометры и прочие. Контроллер опрашивает датчики, обрабатывает данные, пришедши с них, и отсылает их на бортовой ПК. После чего, компьютер, обрабатывает данные, пришедшие с датчиков и команды управления, пришедшие по Wi-Fi от оператора, и принимает решение, выполнять эти команды или нет. Эти “Инстинкты”, должны служить гарантом безопасности во время движения робота.

Тем самым, при выходе из строя платы управления датчиками, или самих датчика, может возникнуть ситуация, когда оператор будет отправлять команды, а робот в свою очередь будет стоять на месте. Либо наоборот, оператор будет думать, что робот способен среагировать на препятствия, которые ему встретятся впереди, но робот будет их не замечать.

AX3500 Roboteq это цифровой двухканальный контроллер управления высоко-мощными двигателями. Он предназначены для преобразования команд, полученных от бортового ПК, в высокое напряжение и высокий ток на выходе для управления одним или двумя двигателями постоянного тока.

Два канала могут либо работать самостоятельно, либо вместе, чтобы задать направление и вращение робота за счет координации движений с каждой его стороны. Двигатели могут работать в открытом или закрытом режиме контура скорости.

Этот узел является основным для управления роботом, так как он напрямую управляет двигателями, преобразуя команды, пришедшие с бортового ПК в постоянный ток. При выходе из строя данного контроллера, наступает ситуация когда невозможно контролировать движение робота. В лучшем случае робот остановится и не сможет сдвинуться с места. В худшем, контроллер начнёт подавать на двигатели максимальный ток, а они в свою очередь будут выдавать максимальную мощность. “Инстинкты” описанные высшее не смогут защитить робота от столкновения или ограничить его скорость, так их расчёт происходит в бортовом ПК. Контроллер можно перепрограммировать, в зависимости от поставленной задачи. Так что, неисправности данного рода могут возникнуть по большей части из-за программных ошибок. Несмотря на большой ток, аппаратные поломки мало вероятны, так как двигатели управляются высокоэффективными управляемыми транзисторами Power MOSFET с помощью широтно-импульсной модуляции (ШИМ) при 16кГц.AX3500 может работать от 12 до 40 В постоянного тока и может выдержать до 60A, обеспечивая мощность до 2400 Вт полезной мощности каждого двигателя.

Основным бортовым вычислительным узлом проектируемого робота-дозиметриста является нетбук Acer Aspire One. Как было написано выше, он обеспечивает связь оператора с роботом через Wi-Fi канал. Так же он отправляет оператору данные собранные с датчиков и видео изображение, полученное от двух видеокамер установленных на нём. Нетбук является центральным узлом системы и контролирует каждый узел в отдельности и любая проблема программного или аппаратного характера приведёт к сбою работы робота. С точки зрения безопасности, самым уязвимым местом является Wi-Fi канал, так как он ограничен по дистанции. Потеря связи оператора с роботом приведёт к неспособности управлять роботом и получать с него необходимые данные.

2. НАХОЖДЕНИЕ ОПТИМАЛЬНОГО СПОСОБА ДОПОЛНИТЕЛЬНОГО КОНТРОЛЯ РОБОТА

2.1 Обзор способов беспроводной передачи данных на большие расстояния

Основной проблемой данной реализации робота является малая дистанция передачи данных. Она связана с использованием стандартного Wi-Fi канала расположенного на ПК робота. Дальность передачи данных такого канала, на открытой местности, около 50 метров. В помещение она гораздо ниже.

Для передачи на большие расстояния, нужно или увеличивать мощность передатчика или применять наружную антенну и увеличивать чувствительности по приему.

Wi-Fi имеет многоголосную структуру, что позволяет ему работать в режиме параллельной приёма-передачи данных. Для этого Wi-Fi использует 13 каналов для передачи данных. Каналы в данном случае представляют собой частотный диапазон. Благодаря этому и работе на частоте 2.4ГГц достигается большая скорость обмена данными. Но именно из за этого Wi-Fi имеет малую дальность работы.

При проектировке любых радиопередатчиков основной характеристикой является максимальная дистанция передачи данных. Она достигается двумя вещами. Во-первых, необходимо компенсировать реактивную составляющую сопротивления (импеданс) выхода передатчика и реактивное сопротивление антенны. Второй основной характеристикой является коэффициент усиления антенны [3].

Для согласования импеданса, в радиотехнике обычно используется определённое расположение активных элементов в цепи (колебательный контур) между передатчиком и антенной. При правильном расположении этих элементов в цепи достигается резонанс частот. Этот резонанс внутренней частоты колебательного контура и частоты передаваемого сигнала значительно увеличивает амплитуду передаваемого сигнала (рис. 2.1). При достижении резонанса, импеданс последовательно соединённых индуктивности и ёмкости минимален, а при параллельном включении -- максимален. Частота, на которой происходит резонанс, определяется величинами (номиналами) используемых элементов, т.е. для каждой конкретной частоты передачи данных необходим свой колебательный контур с определёнными номиналами.

Рис. 2.1. АЧХ при резонансе частот на частоте 2.4ГГц.

Рис. 2.2. Пример конфигурации элементов колебательного контура для радио модуля CC1100 работающего на частоте 433МГц.

Резонансная частота у Wi-Fi 2.4ГГц, но Wi-Fi использует параллельную передачу данных, что подразумевает под собой использование определённого частотного диапазона. Эти частоты относительно близки к частоте 2.4ГГц, но всё же не являются резонансными. Амплитуда сигнала передаваемого на этих частотах гораздо меньше, чем на резонансной частоте, поэтому сигналы на этих частотах рассеиваются гораздо сильнее, что накладывает определённые ограничения на дальность использования Wi-Fi сигнала.

Коэффициент усиления антенны определяет, насколько децибел плотность потока энергии, излучаемого антенной в определенном направлении, больше плотности потока энергии, который был бы зафиксирован в случае использования идеального точечного источника электромагнитных волн, излучающего равномерно по всем направлениям (изотропный излучатель). Зная коэффициент усиления антенны и мощность передатчика, нетрудно рассчитать мощность сигнала в направлении главного лепестка диаграммы направленности. Так, при использовании беспроводной точкой доступа с мощностью передатчика 20 dBm (100 мВт) и направленной антенны с коэффициентом усиления 10 dBi мощность сигнала в направлении максимального усиления составит 20 dBm + 10 dBi = 30 dBm (1000 мВт), то есть в 10 раз больше, чем в случае применения изотропной антенны. Тем самым можно утверждать, что при проектировании радиопередатчика основная роль отводится антенне.

Одним из вариантов увеличения дистанции передачи данных является усиление Wi-Fi сигнала. Так как усилить электрические характеристики Wi-Fi модуля, с целью увеличения выходной мощности сигнала не представляется возможным, то единственным вариантом усиления Wi-Fi сигнала является увеличение коэффициента усиления антенны

В плане использования все антенны для Wi-Fi-устройств можно условно разделить на два больших класса: антенны для наружного (outdoor) и для внутреннего применения (indoor). Отличаются эти антенны, прежде всего своими габаритами и коэффициентом усиления. Естественно, антенны для наружного использования больше по размерам и предусматривают форму крепления либо к стене дома, либо к вертикальному столбу. Высокий коэффициент усиления в таких антеннах достигается за счет малой ширины диаграммы направленности (главного лепестка). Внешние антенны применяются, как правило, для связи двух беспроводных сетей, находящихся на большом расстоянии друг от друга. Две такие антенны устанавливаются в зоне прямой видимости, и в данном случае важно, чтобы каждая из них находилась в зоне главного лепестка диаграммы направленности другой антенны.

Антенны для внутреннего использования меньше по размерам и обладают более низким коэффициентом усиления. Такие антенны либо устанавливаются на столе, либо крепятся к стене или непосредственно к точке доступа.

К самой точке доступа, антенны, могут подсоединяться либо напрямую, либо с помощью кабеля. При этом, для подсоединения антенны или кабеля к точке доступа предусмотрен специальный миниатюрный SMA-разъем.

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

Стоит отметить, что стоимость всех антенн для внутреннего использования явно завышена -- средняя цена на рынке около 3500р.

Антенны для внешнего использования не применима в нашем случае из-за своих габаритов.

Ещё одним вариантом для передачи данных является использование радиоканала построенного на основе радио модуля реализованного в виде микросхемы.

Чуть ранее, была рассмотрена работа Wi-Fi канала. Из неё можно сделать вывод, что для передачи сигнала лучше использовать одну частоту чем диапазон частот. Из-за этого радио модуль медленнее передаёт информацию, но в то же время на большие дистанции. Современные радио модули могут передавать сигнал до 2 км на открытом пространстве при допустимых мощностных характеристиках, не требующих лицензирования данного устройства. Такие возможности достигаются только при правильном выборе антенны с колебательным контуром, которые подключаются к радио модулю.

Современные радио модули предоставляют пользователю большой выбор радиочастот, в которых они могут работать. Они могут работать, как в режиме передачи данных, так и в режиме приёма. Стандартный радио модуль подключается с одной стороны к антенне, а с другой, либо к модулю последовательной приёмопередатчи данных (UART), либо к последовательному периферийному интерфейсу (SPI). Эти интерфейсы широко распространены в современных микроконтроллерах, так что использование радио модулей не представляет особого труда.

На основе всего вышесказанного было принято решение реализовать два устройства для дополнительного контроля робота. Эти устройства представляют собой два контроллера: контроллер оператора и бортовой контроллер. Контроллер оператора, должен будет предоставлять пользователю информацию о текущем состоянии робота и возможность для управления роботом. Бортовой контроллер должен будет отслеживать текущее состояние робота. Он должен быть установлен на роботе между ПК и контроллером управления двигателями. Такое расположение позволит управлять роботом при отключении основных узлов, таких как контроллер управления датчиками или бортовой ПК. Каждый контроллер должен иметь свой источник питания. Такой подход позволит сделать нашу систему энергонезависимой от уже имеющихся источников питания. Поскольку он будет подключён к своему источнику, разрядка любого аккумулятора данной системы не приведёт к выключению данного устройства. Обмен данными между этими контроллерами будет происходить по радиоканалу, так как в отличие от остальных возможных вариантов только он способен передавать сигнал на большие расстояния при низком энергопотреблении. Общая структурная схема «Робота-дозиметриста» приведена на рис. 2.3.

Рис. 2.3. Общая структурная схема «Робота-дозиметриста»

2.2 Основные требования к контроллерам

Контроллер оператора, (или пульт управления) должен представлять собой портативное устройство с помощью которого, пользователь, может в любой момент времени получить необходимые данные о состоянии робота и ”перехватить” управление роботом. Он должен удовлетворять следующим требованиям:

* Наличие дисплея;

* Набор клавиш;

* Наличие радиоканала;

* Собственный источник питания.

Бортовой контроллер представляет собой устройство, которое располагается между ПК и контроллером управления двигателями. Он позволяет прервать управление двигателями со стороны ПК и управлять ими самостоятельно.

Основными требованиями к данному контроллеру являются:

* Наличие USB-порта;

* Наличие COM-порта;

* Наличие радиоканала;

* Собственный источник питания.

Данное расположение бортового контроллера позволит отключить контроллер управления двигателями от основных вычислительных узлов таких как, бортовой ПК и контроллер управления датчиками.

Функциональная схема подсистемы управления представлена на рис.2.4.

Рис. 2.4. Функциональная схема подсистемы управления

3. РАЗРАБОТКА АППАРАРАТНОЙ ЧАСТИ КОНТРОЛЛЕРА ОПЕРАТОРА И БОРТОВОГО КОНТРОЛЛЕРА

Проектировка печатных плат, в данной работе, производилась с нуля. Проектировка производилась в редакторе печатных плат P-CAD 2006 [1]. Это многофункциональная, профессиональная программа для пошагового проектирования и разработки печатных плат любой сложности и проектирования аналоговых, цифрово - аналоговых и аналогово-цифровых устройств. Разработка печатных плат состояла из двух этапов:

- разработка принципиальной схемы устройства;

- размещение компонентов и трассировка платы.

3.1 Проектирование принципиальной схемы контроллера оператора

При проектировании контроллера оператора мы отталкивались от основных задач, которые он должен будет выполнять, а именно:

- Передача сигнала по радио каналу;

- Наличие интерфейса для пользователя;

- Наличие автономного источника питания;

- Компактность.

Из этого списка требований можно сделать вывод, что основные устройства, которые нам понадобятся это:

- LCD дисплей, для вывода необходимой информации пользователю

- Набор кнопок (возможно кнопочная клавиатура) для предоставления пользователю возможности ввода необходимой информации;

- Радио модуль для обеспечения работы с радиоканалом;

- Микроконтроллер, имеющий в своём наличии необходимый нам минимум, а именно: АЦП для обеспечения контроля энергопитания, порты вводавывода, последовательный интерфейс для взаимодействия с радио модулем и LCD модуль;

- Источник питания.

На современном цифровом рынке есть большое количество различных компаний, таких как Atmel, Texas Instruments, Microchip, Fujitsu и т.д., которые производят, как и цифровые устройства, так и сами цифровые компоненты. Практически у всех этих компаний есть различные линейки микро контроллеров, которые всецело удовлетворяют нашим требованиям. Цены у этих микроконтроллеров тоже не слишком разнятся. Поэтому, вопрос выбора микроконтроллера всецело упирается в предпочтения разработчика, если конечно в задании чётко не указано на каком конкретном микроконтроллере производить разработку.

В связи с этим, мною был выбран микроконтроллер CC430F6137 компании Texas Instruments (рис 3.3). Его основные технические характеристики:

* 16-разрядный микроконтроллер пониженной мощности;

* 32КБ Flash-памяти;

* 4КБ RAM;

* CC1101 радио модуль;

* 12 разрядный АЦП;

* LCD модуль.

Как видно из данных характеристик микроконтроллера, он всецело удовлетворяет нашим требованиям, даже с избытком. Он потребляет очень мало электроэнергии за счёт возможности управления внутренней частотой его работы и так же в процессе работы его можно перевести в режим «сна». В этом режиме, ЦПУ микроконтроллера перестаёт выполнять исполнительный код программы, записанный в него, но не отключает контроллер прерываний. Можно сказать, что в данном случае ЦПУ микроконтроллера просто перестаёт работать, до момента, когда на него поступит какое-нибудь прерывание извне. Данная особенность микроконтроллера позволяет нам отказаться от использования миниатюрных аккумуляторов, которые должны были нам дать необходимые электрические мощности, и перейти на использование обычной пальчиковой батарейки. Для согласования электрических мощностей потребляемых системой и возможностей предоставляемой батарейкой был применён повышающий источник напряжения TPS61006, о котором будет написано чуть ниже.

Так же внутрь микроконтроллера был встроен уже готовый радио модуль СС1100.

CC1100E является суб-ГГц приемопередатчиком высокой производительности, потребляющим очень мало мощности для работы. Он предназначен для устройств ближнего радиуса действия с частотными полосами 470-510 МГц в и 950-960 МГц.

Рис.3.1.Принципиальная схема колебательного контура для контроллера оператора

В CC1100 трансивер встроен настраиваемый модем для работы с частотным диапазоном. Модем поддерживает различные формы модуляции и имеет настраиваемые скорости передачи данных до 500 кбод. Колебательный контур для данного радио модуля подробно описан в сопровождающей документации на микроконтроллер CC430F6137.

Для отображения необходимой информации предоставляемой пользователю был выбран LCD дисплей TC20297A-00. Его основные технические характеристики:

* Может отображать 8 цифр состоящих из 9и сегментов;

* 24 основных контакта и 3 управляющих;

* рабочее напряжение 3.5.

Микроконтроллер CC430F6137 имеет модуль для работы с LCD дисплеями. В его состав входят 34обычных выхода и 4 выхода управления. Этот набор выходов позволяет использовать все необходимые сегменты выбранного дисплея.

Для предоставления пользователю возможности ввода необходимой информации рассматривался вариант использования кнопочной клавиатуры. Но самая маленькая такая клавиатура использует как минимум 9 контактов вводавывода микроконтроллера. Поэтому было принято решение использовать обычные кнопки, собрав их в виде матрицы [5]. Такой подход позволил подключить 6 кнопок, используя всего 5 контактов вводавывода микроконтроллера. Данную реализацию модуля ввода можно считать миниатюрной кнопочной клавиатурой.

В качестве основного источника питания было принято решение использовать обычную пальчиковую батарейку. Для согласования электрических мощностей потребляемых системой и возможностей предоставляемой батарейкой был применён повышающий источник напряжения [8] TPS61006 (рис 3.2). Данный преобразователь напряжения позволяет регулировать выходное напряжение от 1,5В до 3,3В максимум и обеспечивает минимальный выходной ток 100 мА, с одной батареей и 250 мА от двух гальванических элементов. Преобразователь запускается в полной нагрузке с напряжением питания 0,9В и остается в работе с напряжением питания 0,8 В.

Рис.3.2.Принципиальная схема повышающего источника напряжения для контроллера оператора

Все остальные элементы, включённые в схему, были добавлены в соответствии с технической документацией и являются элементами типовой схемы включения для основных компонентов, таких как CC430F6137, TPS61006, TC20297A-00.

3.2 Проектирование принципиальной схемы бортового контроллера

При проектировании бортового контроллера мы отталкивались от основных задач, которые он должен будет выполнять, а именно:

- Передача сигнала по радио каналу;

- Наличие необходимых интерфейсов для взаимодействия с узлами робота;

- Наличие автономного источника питания;

Из этого списка требований можно сделать вывод, что основные устройства, которые нам понадобятся это:

- USB интерфейс;

- Интерфейс для COM - порта;

- Радио модуль для обеспечения работы с радиоканалом;

- Микроконтроллер, имеющий в своём наличии необходимый нам минимум, а именно: АЦП для обеспечения контроля энергопитания, порты вводавывода, два или более последовательных интерфейсов для взаимодействия с радио модулем и внешними последовательными интерфейсами (USB и COM);

- Источник питания.

В качестве используемого микроконтроллера был выбран MSP430F147 (рис.3.10). Его основные характеристики:

• 16-разрядный микроконтроллер пониженной мощности;

• 32 КБ Flash-памяти;

• 1КБ RAM;

• 12 разрядный АЦП;

• 2 USARTs (универсальный асинхронный приёмопередатчик).

Поскольку данный микроконтроллер имеет всего два универсальных асинхронных приёмопередатчика, один из которых постоянно должен будет использоваться для взаимодействия с радио модулем, то необходимо будет использовать специальную систему коммутации, для того что бы мы смогли пользоваться USB и COM интерфейсами используя всего один USARTs.

Данная система коммутации позволяет перехватывать все сообщения в обоих направлениях и аппаратно отключать/включать внешние интерфейсы. Так же, при выключенном микроконтроллере наша система сможет работать как обычный преобразователь типа USB - COM. Для реализации этой системы коммутации были использованы аналоговые ключи TS3A5017. Это двойной четырёх-канальный аналоговый мультиплексор, предназначенный для работы от 2,3 В до 3,6 В. Это устройство может работать как с цифровыми, так и аналоговыми сигналами, и сигналы до V + могут быть переданы в любом направление (рис.3.5).

В качестве радио модуля был выбран СС1100 (рис.3.6). Это было сделано, поскольку этот модуль уже используется у нас в контролере оператора. Такое решение позволит уменьшить затраты по согласованию настроек радиоканала. Колебательный контур для данного радио модуля подробно описан в сопровождающей документации на микроконтроллер CC1100.

В качестве контроллера USB [14] был выбран FT232RL (рис.3.5). Его основные характеристики:

• одночиповый переходник из USB в асинхронный последовательный интерфейс передачи данных (UART);

• протокол USB полностью реализован в микросхеме;

• интерфейс UART поддерживает режимы передачи 7 и 8 бит данных, 1 и 2 стоповых бита, различные режимы контроля четности;

• скорости передачи от 300 бод до 1 мегабод для RS-232;

В качестве преобразователя UART - COM [13] был выбран ADM232 (рис.3.5). Он представляет собой высокоскоростной преобразовательRS-232 и предоставляет скорость передачи данных до 200 Кб / с. Работая от одного +5В питания. Имеет в своём наличии два порта приёма/передачи RS-232.

USB интерфейс имеет линию питания +5В, поэтому он может служить основным источником питания. Но поскольку для работы радио модуля CC1100 и микроконтроллера MSP430F147 нужно напряжение +3В то нам необходимо использовать преобразователь напряжения с +5В до +3В. В качестве такого преобразователя был выбран L78L00 (рис.3.7). Его основные характеристики:

• Выходной ток до 100 мА;

• Выходное напряжение3,3;

• Тепловая защита от перегрузки.

Рис.3.7. Принципиальная схема понижающего источника напряжения для бортового контроллера

Поскольку не каждый USB разъём может предоставлять линию электропитания, то необходимо использовать ещё и свой внутренний источник питания. В качестве внутреннего источника питания было принято решение использовать обычную пальчиковую батарейку. Для согласования электрических мощностей потребляемых радио модуля CC1100 и микроконтроллером MSP430F147 и возможностей предоставляемой батарейкой был применён повышающий источник напряжения TPS61006 (рис.3.8). О этом преобразователе напряжения было рассказано в предыдущем параграфе.

Рис.3.8. Принципиальная схема повышающего источника напряжения для бортового контроллера

Для согласования электрических мощностей потребляемых микросхемами FT232RL и ADM232 и возможностей предоставляемой батарейкой был применён повышающий источник напряжения TPS61200 (рис.3.9).

Его основные характеристики:

• Более 90% КПД при,

- 300 мА выходной ток 3,3 V (VIN ? 2,4 В);

- 600 мА выходной ток при 5 В (VIN ? 3 В);

• Выходной ток не менее 55 мкА;

• Запуск при Входном напряжении 0.5В;

• Рабочий диапазон входного напряжения от 0,3 В до 5,5 В;

• Выходная защита от короткого замыкания при любых условиях эксплуатации;

• Фиксированные и регулируемые параметры выходного напряжения от 1,8В до 5,5 В;

• Режим энергосбережения для повышения эффективности при низкой выходной мощности;

• Защита от перегрева;

Рис.3.9. Принципиальная схема повышающего источника напряжения для бортового контроллера

Так же для обеспечения более удобной отладки плат в схему были введены некоторые дополнительные элементы , такие как: 2 кнопки, 2 свето-диода и 5 выводных портов подключённых к не подключенным ножкам микроконтроллера и ножкам коммутационных аналоговых мультиплексоров.

Все остальные элементы, включённые в схему, были добавлены в соответствии с технической документацией и являются элементами типовой схемы включения для основных компонентов, таких как CC430F6137, СС1100, FT232RL, ADM232, TPS61006, TPS61200, L78L00

3.3 Трассировка печатных плат

Трассировка печатных плат очень аккуратная и тонкая работа в связи, с которой установлен ряд правил. Но большинство из этих правил относятся к ВЧ, СВЧ схемам, и схемам, имеющим в своём наличии линии по которым идут высокие токи или напряжение. В случае обычных цифровых схем, правил не так много.

• Минимальное расстояние между проводниками 0,3мм;

• При разводке линий нельзя допускать прямых или острых углов;

• Длинна сигнальных линий, должна быть как можно короче;

• Количество переходных отверстий на сигнальных линиях должно быть как можно меньше;

• Длинна линий питания может быть любой;

• Количество переходных отверстий на линии питания может быть любым;

• Если элемент имеет металлический корпус, то он должен быть заземлён;

• Нельзя допускать открытие маски на медных элементах платы.

Для формы линий тоже есть свои правила.

• Стандартная ширина сигнальной линии 0.25мм;

• Стандартная ширина линии питания 0.50мм, но можно и больше.;

Что касаемо линий питания, чем они шире, тем лучше. Обычно их стараются делать шириной 1.0мм.

Также необходимо стараться оставить больше количество меди на плате, так как при производстве печатных плат медь стравливают с платы. А чем больше нужно вытравить меди, тем дороже плата. Лишние и не нужные медные площадки, обычно становятся «землёй». Такой подход не ухудшает качество платы, а наоборот увеличивает его, так как отрицательный заряд равномерно распределяется по медной площадке. Именно для того что бы заряд равномерно распределялся по площадкам необходимо «прошивать» эти площадки большим количеством переходных отверстий.

В данной работе было использовано два вида переходных отверстий:

• C10D05 диаметр контактной площадки 1.0мм, диаметр отверстия 0.45мм (стандартное переходное отверстие)

• C06D03 диаметр контактной площадки 0.60мм, диаметр отверстия 0.30мм

C06D03 использовались только при трассировке платы контроллера оператора.

В качестве излучателя электромагнитных волн для радио канала, было принято решение использовать печатную антенну [12] для 868МГц компании CCIPCON. Реактивное сопротивление антенны на входе 50ohm. График пропускной способность при настройке антенны на частоту 868МГц представлен на рис.

Рис.3.11.Пропускная способность при настройке антенны на частоту 868МГц.

Чертёж антенны с линиями для колебательного контура представлен на рис.3.12.

Рис.3.12.Чертёж антенны с линиями для колебательного контура

Разработка печатной платы контроллера оператора производилась с учётами размеров корпуса BOS 400 компании BOPLA (рис.3.13). Чертёж корпуса представлен на рис

В дальнейшем, с учётом всех вышесказанных правил, была произведена трассировка печатной платы контроллера оператора и бортового контроллера (Рис.3.14 - 3.17).

Итоговые размеры плат составляют:

- Для платы контроллера оператора длинна75.5мм ширина 56.5мм

- Для платы бортового контроллера длинна 92.0мм ширина 82.0мм

Рис.3.13.Чертёж пластикового корпуса BOS 400 компании BOPLA

Рис.3.14.Печатная плата контроллера оператора (вид сверху).

Рис.3.15.Печатная плата контроллера оператора (вид снизу).

Рис.3.16.Печатная плата бортового контроллера (вид сверху).

Рис.3.17.Печатная плата бортового контроллера (вид снизу)

4. РАЗРАБОТКА ПРОГРАМНОЙ ЧАСТИ КОНТРОЛЛЕРОВ

Микроконтроллеры MSP430F147 [7] и CC430F6137 [8] имеют ряд библиотек для работы с модулями, которые входят в их состав. Эти библиотеки позволяют программисту легко управлять сложными процессами внутри микроконтроллера благодаря набору функций. Среди этих функций есть таки, как приём/отправка сообщений на UART, SPi. Так же в CC430F6137 есть набор функций для работы с LCD и радио модулем. Так что основными задачами при разработке программной части контроллеров были:

- Разработка протокола для гарантированной доставки сообщений по радиоканалу;

- Разработка основного цикла программы;

- Разработка программы обработчика прерываний.

4.1 Алгоритм взаимодействия контроллеров

Сразу стоит сказать, что разрабатываемый нами протокол нужен нам по тому, что передача сообщений будет проходить в незащищённой, зашумлённой среде. Протокол будет гарантировать нам целостность данных при их отправке и то, что данные будут обязательно получены. Так же протокол обмена позволит нам получать данные только от того кто их нам послал, а это нам необходимо потому что частота 868МГц общедоступна и на ней работает очень много устройств. Но перед тем как разрабатывать протокол нам необходимо разработать формат данных, которые будут передаваться по радио каналу, и отработать все возможные варианты, из-за которых могут возникнуть ошибки.

4.1.1 Формат пакетов

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

Основное что должно быть в нашем пакете, это адреса, отправителя и получателя. Благодаря им мы сможем отсеивать ненужные пакеты и обрабатывать только те, которые предназначались нам.

Каждый микроконтроллер семейства MSP430 и СС430 компании Texas Instruments содержит уникальный номер, расположенный во флеш-памяти по адресу 0xff00. Он имеет длину в 10 байт. Этот номер и был взят за основу адреса устройства.

Так же при передаче нам понадобятся флаги, с помощью которых мы сможем контролировать этапы передачи данных. На первых этапах нам понадобятся:

• Флаг подтверждения передачи ACK

• Флаг ошибки при передаче ERR

• Флаг установки соединения .INIT для обмена адресами.

Под эти флаги отводится 1 байт. Тем самым у нас остаётся ещё 5 бит зарезервированных для особых нужд.

Что бы следить за последовательным ходом работы при передачи пакетов, и контролировать потерю пакетов так же была введена числовая последовательность. Под неё выделяется один 1. Если

Для проверки целостности передаваемых данных, нам нужно передавать контрольную сумму. Для вычисления контрольной суммы был использован алгоритм для вычисления циклических избыточных кодов CRC16. Помимо этого с помощью этого кода можно узнать в каком месте пакета была произведена ошибка и восстановить повреждённые данные. Использование этого кода поможет свести к минимуму использование «битых» пакетов. Но всё равно остаётся одна опасная ситуация когда, одновременно повреждается пакет и контрольная сумма. Таким образом, система может посчитать пакет достоверным.

Под запись контрольной суммы полученной с использованием CRC16 отводится 2 байта.

Так же нам необходимо передавать данные в пакете. Поскольку у нас есть LCD дисплей, который нужен для отображения пользователю информации о системе, то нам необходимо передавать данные такого размера что бы на дисплее могло отобразиться максимально возможное число. Поскольку дисплей имеет 8 цифровых позиций, то максимальное число = 99999999. В шестнадцатеричном коде оно равно 5F5E0FF. Данное значение занимает 4 байта. Так же, под данные было отведено ещё 2 байта, для передачи кодов позволяющих, определить ,для чего нужны и что обозначают 4 последующих байта.

Таким образом, длинна нашего пакета ровна 30 байтам и имеет структуру изображённую на рис. 4.1.

Рис. 4.1. Формат пакета данных при передаче по протоколу гарантированной доставке сообщений по радиоканалу

4.1.2 Протокол обмена данными

При разработке алгоритмов протокола гарантированной доставки сообщений по радиоканалу были рассмотрены алгоритмы протокола TCP

Transmission Control Protocol (TCP) (протокол управления передачей) -- один из основных сетевых протоколов Интернета, предназначенный для управления передачей данных в сетях и подсетях TCP/IP.

TCP -- это транспортный механизм, предоставляющий поток данных, с предварительной установкой соединения, за счёт этого дающий уверенность в достоверности получаемых данных, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета.

Рис4.2.Стандартная работа алгоритма гарантированной доставки сообщений

В нашем протоколе, так же как и в TCP будет использоваться подтверждение приёма сообщения и подсчёт количества отправленных сообщений. Такой подход позволит узнать, дошёл ли пакет до получателя или нет.

Рис.4.3. Этапы нормальной работы протокола ГДС

Рис. 4.4. Этапы установления соединения по протоколу ГДС.

Основные функции, которые будет выполнять протокол гарантирован-ной доставки сообщений (ГДС) при обычной работе, изображены на рис. 4.2.

Работа протокола ГДС при обычной передаче сообщения представлена в несколько этапов (рис.4.3):

Этап 1.Сначало, инициатор передачи (1) отправляет пакет в котором указан адрес отправителя А1, адрес получателя А2, числовую последовательность ЧП, контрольную сумму CRC и сами данные. Поле флагов равно 0. После отправки пользователь 1 переходит в сон, дожидаясь подтверждения о доставке.

Этап 2.Получатель (2) принимает пакет. После чего он его проверяет, и удостоверившись что с пакетом всё хорошо он увеличивает свою числовую последовательность на 1 и отправляет пользователю 1, пакет подтверждения, а сам начинает обрабатывать данные которые только что получил. Пакет подтверждения отличается от обычного только тем, что в нём есть флаг подтверждения АСК и числовая последовательность увеличена на 1.

Этап 3.Пользователь 1 получает пакет подтверждения и проверяет его. Удостоверившись, что с пакетом всё хорошо он увеличивает свою числовую последовательность на 1

При установлении соединения, работа протокола ГДС отличается от обычной, увеличенным количеством этапов (рис.4.4):

Этап 1.Инициатор передачи (1) отправляет пакет в котором заполняет только адрес отправителя А1, числовую последовательность ЧП, контрольную сумму CRC и флаг установки соединения INIT.

Этап 2. Получатель (2) принимает пакет и благодаря флагу INIT не проверяет адреса, а проверяет только целостность пакета. Удостоверившись, что с пакетом всё хорошо он запоминает адрес отправителя и отправляет ему обычный пакет, а сам остаётся дожидается подтверждения.

Этап 3. Пользователь (1) принимает пакет и проверяет только адрес получателя и целостность пакета. Удостоверившись, что с пакетом всё хорошо он запоминает адрес отправителя, увеличивает свою числовую последовательность на 1 и отправляет пользователю 1, пакет подтверждения.

Этап 4. Пользователь 1 получает пакет подтверждения и проверяет его. Удостоверившись, что с пакетом всё хорошо он увеличивает свою числовую последовательность на 1.

При ближайшем рассмотрении становится, очевидно, что начиная со второго этапа, установка соединения выглядит как обычная передача сообщения. Она отличается только этапом 3, где не проверяется адрес отправителя. Так что можно сказать, что установка соединения по протоколу ГДС является частным случаем обычного обмена сообщениями.

4.1.3 Возможные ситуации при передаче данных по протоколу

Рис. 4.5. Потеря пакета сразу после отправки

Рис. 4.6.Нарушение целостности пакета, сразу после отправки.

Для того что бы реализовать функции проверки и формирования пакета, представленные на рис. 4.2, необходимо рассмотреть все возможные ситуации которые могут возникнуть при обычной передаче пакета по протоколу гарантированной доставке сообщений (ГДС).

Для начала рассмотрим ситуацию, когда наш пакет теряется сразу после отправки (Рис. 4.5).

Если такая ситуация произошла, то пользователю нужно всего лишь повторить отправку пакета. Это можно реализовать по прохождению, какого то промежутка времени, по Timeout'у. Программа уходит в ожидание и, прождав некоторое время, не дождавшись подтверждения, повторяет попытку. Количество попыток необходимо ограничить, что бы не возникла ситуации, когда у получателя произошла какая-нибудь поломка и он не может продолжать дальнейшую работу, а отправитель пытается ему что то отправить. После окончания попыток пользователь должен сообщить о не удачи.

Теперь рассмотрим ситуацию, когда сразу после отправки у нас нарушается целостность пакета (Рис. 4.6).

Если такое произойдёт, то получатель должен будет сообщить об этом отправителю. Для этого необходимо выставить флаг нарушения целостности ERR. Числовая последовательность у получателя не увеличится, так как формально он не получил нормальный пакет.

Когда отправитель получит пакет и проверит его, то на основе флага ERR и числовой последовательности, он примет решение отправить предыдущее сообщение заново. Дальнейшая работа протокола ни чем не отличается от обычной отправки сообщений.

Так же нам необходимо рассмотреть случаи, в которых происходит сбой при отправке подтверждения. Одним из этих случаев является потеря пакета подтверждения доставки сообщения (рис. 4.7).

Если такая ситуация произошла, то перед тем как отправить пакет подтверждения получатель увеличил свою числовую последовательность, а отправитель, как и в первом случае, недожавшись подтверждения, по Timeout'у, повторит отправку предыдущего пакета.

Получатель примет пакет и при проверке увидит, что его числовая последовательность выше, чем у отправителя. На основе этого он сделает вывод, что пакет подтверждения был потерян и отправит его снова. После чего получатель примет этот пакет, проверит его, и остановится, увеличив свою числовую последовательность.

Рис. 4.7. Потеря пакета подтверждения

Рис. 4.8. .Нарушение целостности пакета подтверждения

Теперь рассмотрим ситуацию, у нас нарушается целостность пакета подтверждения доставки сообщения (Рис. 4.6).

В этом случае, перед тем как отправитель получит повреждённый пакет подтверждения, получатель увеличит свою числовую последовательность. Отправитель же обнаружит при проверке, что пакет повреждён и уведомит об этом получателя, выставив флаг ERR, не увеличив при этом свою числовую последовательность.

Получатель примет пакет, как и в предыдущем случае, увидит, что его числовая последовательность выше, чем у отправителя. На основе этого он сделает вывод, что пакет подтверждения был потерян и отправит его снова. После чего получатель примет этот пакет, проверит его, и остановится, увеличив свою числовую последовательность.

Единственное отличие этого случая от предыдущего, что получатель так же с предыдущим сообщением получает флаг ERR.

Как было рассмотрено выше, процесс установки соединения по протоколу ГДС является частным случаем обычного обмена сообщениями. Поэтому для него так же будут выполняться все случаи рассмотренные выше. Если же возникнет случай, когда сразу после инициализации у нас потеряется пакет с флагом INIT, то пользователь 1 просто не получит не какого сообщения и соединение не будет установлено. Тоже самое произойдет, если целостность этого пакета будет нарушена. Пользователь 2 просто откинет этот пакет и сделает вид, что ничего не произошло.

4.1.4 Блок-схемы основных функций протокола

После рассмотрения всех возможных ситуаций при работе протокола, были разработаны блок-схемы всех необходимых алгоритмов для дальнейшей реализации протокола гарантированной доставки (ГДС) сообщений по радиоканалу. В список необходимых алгоритмов вошли:

- алгоритм проверки пакетов;

- алгоритм передачи пакетов;

- алгоритм приёма пакетов;

- алгоритм установления соединения со стороны клиента;

- алгоритм установления соединения со стороны сервера;

Алгоритм проверки пакетов был реализован при использовании результатов полученных в пункте 4.1.3. «Возможные ситуации при передаче данных по протоколу».

Такая структура проверки пакета не случайна. Сначала проверяются адреса, поскольку среда передачи общедоступна, и кто угодно может отправить пакет на той же частоте что и мы, то если адреса не совпадают, программа сразу же перестаёт проверять пакет, не устанавливая флаг результата, деля вит, что ничего не произошло.

Далее идёт проверка целостности. По тому что, даже если пакет и адресован нам, но он повреждён, то нет никакого смысла проверять его дальше.

Рис.4.9. Алгоритм проверки пакетов

После проверки целостности, идёт распознавание того какой именно пакет к нам пришёл. На основе всех этих проверок возможны три различных результата. Если по завершению алгоритма флаг result равен:

0 пакет был адресован не нам, и мы возвращаемся в режим ожидания нужного нам пакета;

1 успешный результат;

2 нам необходимо отправить предыдущий пакет.

Этот алгоритм полностью отрабатывает все возможные ситуации, рассмотренные в предыдущем пункте. Так же он частично формирует следующее сообщение, устанавливая необходимые флаги и числовую последовательность.

Флаг NoCh устанавливается на первом этапе (рис 4.4) со стороны клиента при попытке установления связи с сервером.

PFlags. - набор флагов пришедших в пакете.

Flags. - флаги, которые необходимо отправить в будущем пакете.

ЧПН - наша числовая последовательность.

ЧПп - числовая последовательность, записанная в пришедшем пакете.

Рис.4.10. Алгоритм приёма пакетов

Рис.4.11. Алгоритм передачи пакетов

Рис.4.12. Алгоритм установления соединения со стороны сервера

Рис.4.13. Алгоритм установления соединения со стороны клиента

Про алгоритмы, представленные на рис. 4.12. 4.13. отдельно стоит добавить то, что установление соединения с обеих сторон должно происходить как можно быстрее. Это связанно с тем, что в режиме установлении соединения со стороны сервера система переходит в режим ожидания, в котором не проверяются адреса полученных пакетов. По этому, какой-нибудь шум может быть расценен как пакет с флагом инициализации.

4.2 Общий алгоритм управляющей программы

Рис.4.14. Общий алгоритм программы.

Общий алгоритм программы, представленный на рис. 4.14. был разработан для контроллера оператора и бортового контроллера. Единственное чем отличаются эти контроллеры при использовании этого алгоритма так это блоком выполнения функций.

Для контроллера оператора блок выполнения функций представляет собой набор функций вывода на LCD дисплей определённых сообщений и отправки данных запроса по протоколу гарантированной доставки сообщений по радиоканалу. Выбор выполняемых функций осуществляется с помощью обработчика прерываний кнопок.

Для бортового контроллера блок выполнения функций отсутствует. В его задачи входит обработка и выполнение запросов поступающих со стороны контроллера оператора и посылка ответов.

Блок инициализации включает в себя, настройку радио модуля, частоты работы ЦПУ, АЦП , LCD модуля, последовательных портов и основных портов ввода вывода микроконтроллера.

Блок обработки прерываний включает в себя обработку прерывания от четырёх видов источников.

Обработка прерываний от таймера. Реализована в виде ожидания в алгоритмах протокола гарантированной доставке сообщений. А так же в алгоритмах работы LCD дисплея и сканера клавиатуры.

Обработка прерываний от порта общего назначения. Используется при обработки нажатия кнопок.

Обработка прерываний от радио модуля. Используется только в контроллере оператора для обработки пакетов поступающих по протоколу.

Обработка прерываний от последовательного интерфейса. Используется только в бортовом контроллере для обработки пакетов поступающих по протоколу и обработки данных поступающих с USB или СOM-порта

Блок «Сон» представляет собой особое состояние микроконтроллера в котором ЦПУ микроконтроллера перестаёт выполнять исполнительный код программы, записанный в него, контроллер прерываний остаётся включен. Можно сказать, что в данном случае ЦПУ микроконтроллера просто перестаёт работать, до момента, когда на него поступит какое-нибудь прерывание из вне.

Блок обработки пакетов и блок установления соединения реализованы на алгоритмах, которые были разработаны в пункте 4.1.4. «Блок-схемы основных функций протокола».

Рис.4.15. Алгоритм обработки нажатия кнопок

Данный алгоритм позволяет распознавать нажатие кнопки или зажатие кнопки, на определённый период времени, устанавливая при этом соответствующие флаги. Он так же подходит для распознавания нажатия или зажима группы кнопок.

5. ТЕСТИРОВАНИЕ И ОТЛАДКА СПРОЕКТИРОВАННЫХ УСТРОЙСТВ

Тестирование данных устройств проводилось по двум направлениям:

- Тестирование аппаратной части контроллеров;

- Тестирование программной части контролеров.

Среди средств отладки применялись:

- Мультиметр Mastech MAS838;

- Цифровой осциллограф АСК-22060;

- Программатор MSP-GANG430.

5.1 Тестирование печатных плат

Тестирование состояло из следующих этапов:

- тестирование правильности работы преобразователей напряжения;

- тестирование приёма и передачи сообщений по интерфейсу RS-232;

- тестирование приёма и передачи сообщений по интерфейсу USB;

- тестирование работы радио модуля.

Тестирование преобразователей напряжения проводилось следующим образом. К платам подключали необходимый источник питания , и с помощью мультиметра измеряли выходное напряжение преобразователей.

Выходное напряжение преобразователей попадало в 5% диапазон от того которое указал производитель.

Преобразователь TPS61006 установленный на плате те контроллера оператора, превышал этот диапазон. Его выходное напряжение было +3.52В при заявленных +3.3В.

В документации на микроконтроллер CC430F6137 сказано, что критическое напряжение работы микроконтроллера +3.6В.

По сколько источником питания для контролера оператора служит батарейка, то со временем она будет разряжаться в связи с чем выходное напряжение так же будет понижаться. Так что было принято решение не заменять этот источник питания.

Для проверки работы последовательного интерфейса RS-232 в режиме приёма и передачи был проведён специальный тест.

Ход выполнения тестирования:

- подключаем плату к USB порту, тем самым подавая напряжение на плату +5В;

- предварительно, МК запрограммирован тестовой программой, которая должна принимать код приходящий по асинхронному последовательному порту, и отправлять обратно;

- плата подключается по интерфейсу RS-232 к компьютеру;

- на компьютере запускается программа “Terminal”;

- после включения питания, плата устанавливает свою схему коммутации в положение COM - UART и передаёт по интерфейсу RS-232 сообщение о готовности ;

- из программы “Terminal” отсылаются пакеты по интерфейсу RS-232;

- плата ретранслирует принятые пакеты на компьютер по интерфейсу RS-232.

После проведения этого теста на экране Terminal`а появились отправленные нами пакеты, и их количество совпадало с количеством отправленных, было принято считать тест успешно пройденным.

Для проверки работы интерфейса USB в режиме приёма и передачи был проведён специальный тест. Тест аналогичен соответствующему тесту для интерфейса RS-232 за счёт того, что программа “Terminal” распознают USB - соединение как COM.

Ход выполнения тестирования:

- подключаем плату к USB порту, тем самым подавая напряжение на плату +5В;

- предварительно, МК запрограммирован тестовой программой, которая должна принимать код приходящий по асинхронному последовательному порту, и отправлять обратно;

- на компьютере запускается программа “Terminal”;

- после включения питания, плата устанавливает свою схему коммутации в положение COM - UART и передаёт по интерфейсу USB сообщение о готовности;

- из программы “Terminal” отсылаются пакеты для робота по интерфейсу USB;

- плата ретранслирует принятые пакеты на компьютер по интерфейсу USB.

После проведения этого теста на экране Terminal`а появились отправленные нами пакеты, и их количество совпадало с количеством отправленных, было принято считать тест успешно пройденным.

Для проверки работы радио модуля в режиме приёма и передачи на частоте 868МГц был проведён специальный тест.

Ход выполнения тестирования:

- Берём 2 одинаковых контроллера оператора;

- Подключаем к ним источник напряжения;

- предварительно, МК запрограммирован тестовой программой, которая должна принимать код приходящий по радиоканалу и выводить его на LCD дисплей, а при нажатии на кнопку отправлять этот код;

- нажимаем на кнопку контроллера №1;

- контроллер №1 передаёт на контроллер №2, а тот выводит его на дисплей.

В результате этого теса сообщение было передано на максимальном расстоянии 7см. что позволяет утверждать, что радио модуль, работает. Но при повторном проведении этого теста с последующим увеличением расстояния, Сообщение не передаётся.

Этот тест так же проводился при использовании частот 916МГц и 413МГц. Но даже на расстоянии менее 7см данные не передавались. Из этого можно сделать вывод, что антенна спроектирована правильно и с частотой работы 868МГц.

При дальнейшем рассмотрении всех особенностей проектировки печатных антенн, в плате контроллера оператора была найдена ошибка, допущенная при проектировании рис.5.1.

Рис.5.1. Фотография контролера оператора (вид сверху)

Как можно увидеть на фотографии, линии, соединяющие микроконтроллер MSP430F6137 и колебательный контур, имеют разную длину. Это разница в длине и повлекла за собой понижение мощности радио модуля.

В связи с этой ошибкой пришлось заново произвести разработку принципиальной схемой котроллера оператора с заменой микроконтроллера CC430F6137 на MSP430FE423 (рис. 5.3) и добавлением в схему отдельного радио модуля CC1100, того же что используется в бортовом контроллере.

Основные характеристики микроконтроллера MSP430FE423:

* 16-разрядный микроконтроллер пониженной мощности;

*8КБ Flash-памяти;

* 256Б RAM;

* USARTs (универсальный асинхронный приёмопередатчик);

* LCD модуль.

Замена микроконтроллеров произошла по той причине, что невозможно развести плату так, чтобы линии, соединяющие микроконтроллер MSP430F6137 и колебательный контур были одинаковой длинны.

Новые принципиальные схемы представлены на рис.5.2, 5.3, 5.4.

Так же повторно была произведена трассировка печатной платы контроллера оператора (рис 5.5 и 5.6)

Рис.5.2. Принципиальная схема повышающего источника напряжения для повторно спроектированного контроллера оператора

Рис.5.3. Принципиальная схема микроконтроллера для повторно спроектированного контроллера оператора

Рис.5.4. Принципиальная схема радио модуля для повторно спроектированного контроллера оператора

Рис.5.5. Повторно спроектированная печатная плата контроллера оператора (вид сверху).

Рис.5.6. Повторно спроектированная печатная плата контроллера оператора (вид снизу).

5.2 Отладка программной части контроллеров

Поскольку на этапе тестирования печатных платы была выявлена ошибка, из-за которой радио модуль не может передавать данные на большие расстояния, провести полную отладку программной части контроллеров, не получилось.

Но всё же радио модуль оказался способен передавать данные на короткое расстояние. Благодаря этому удалось произвести тестирование протокола гарантированной доставки сообщений по радиоканалу.

Для тестирования протокола были искусственно созданы ситуации, описанные в пункте 4.1.2. «Возможные ситуации при передаче данных по протоколу», с целью проверки того что данные всё ровно будут доставлены.

При прохождении тестов были выявлены 2 тупиковые ситуации.

Рис.5.7. Первая тупиковая ситуация

Рис.5.8. Вторя тупиковая ситуация

Предположим, что пакет подтверждения не был доставлен, в то время как пользователь 2 увеличил свою числовую последовательность. Тогда пользователь 1 будет повторять запрос, пока у него не кончится количество попыток. Предположим что у пользователя 1 кончались попытки отправки сообщения и он так и не получил ответа и не увеличил свою числовую последовательность. После чего пользователь 2 отправляет уже новый пакет с числовой последовательностью большей чем у него.

Исходя из алгоритма проверки пакетов представленного на рис.4.9. мы должны будем увеличить нашу числовую последовательность и отослать пустое сообщение без флагов. Но это не так. Мы оказываемся в совершенно новой ситуации. Таким образом, что бы выбраться из первой тупиковой ситуации, необходимо после проверки числовой последовательности, проверять пакет на наличие флага подтверждения ACK и в соответствии с ним принимать дальнейшее решение.

Так же данная ситуация абсолютно точно показывает пользователю 1 сколько пакетов он потерял. Если для нас приходит пакет, числовая последовательность которого больше, и этот пакет не содержит флага подтверждения, то количество потерянных пакетов есть разница между нашей и пришедшей числовой последовательностью.

Теперь рассмотрим вторую тупиковую ситуацию. Предположим, что пакет подтверждения был доставлен поврежденным, в то время как пользователь 2 увеличил свою числовую последовательность. Тогда пользователь 1 повторит запрос установив флаг повреждения целостности ERR. Предположим, что это сообщение дойдёт до пользователя 2 тоже повреждённым. Тогда он сам отправит сообщение с флагом ERR пользователю 1. Исходя из доработанного алгоритма проверки пакетов, мы должны будем расценить это сообщение, как потерю пакета. Нам вроде как необходимо повторить отправку пакета со стороны пользователя 1 и получив пакет подтверждения увеличить свою ЧП. Но это не так. На самом деле нам просто необходимо на этапе 5 сразу увеличить свою числовую последовательно и успешно выйти из алгоритма передачи пакетов представленном на рис.4.11. Доработанный алгоритм проверки пакетов представлен на рис.5.9.

Рис.5.9. Доработанный алгоритм проверки пакетов.

робот дозиметрист передача контроллер

Основные параметры протокола, такие как, время ожидания подтверждения и количество попыток отправки пакета, необходимо устанавливать экспериментально, но поскольку, сообщения не могут быть переданы на большое расстояние, то этого сделать не удастся.

Вовремя проведения тестирования протокола, время ожидания равнялось 300мс а, количество попыток отправки пакета равно 3.

ЗАКЛЮЧЕНИЕ

Цели, поставленные в техническом задании на дипломный проект, были последовательно выполнены, их результаты представлены в данной пояснительной записке.

Обзорная часть дипломного проекта состоит из следующих частей:

- обзор аппаратных решений, применяющихся в «Роботе-дозиметристе» и анализ общей структурной схемы робота;

- обзор способов дистанционной передачи данных.

На основании обзорной части, было последовательно выполнено следующее:

- разработана структурная схема взаимодействия контроллера оператора и бортового контроллера;

- произведён выбор аппаратной базы для реализации контроллера оператора и бортового контроллера.

Далее, основываясь на результатах предыдущих пунктов:

- спроектированы принципиальные электрические схемы контроллера оператора и бортового контроллера;

- спроектированы печатные платы контроллера оператора и бортового контроллера;

- разработан протокол гарантированной доставки сообщений для радиоканала;

- разработана общая программа для взаимодействия бортового контроллера и контроллера оператора;

- составлено руководство пользователя для плат бортового контроллера и контроллера оператора.

Отладка протокола не была выполнена до конца из-за возникших проблем с платой контроллера оператора.

Спроектированные контроллеры имеют большое значение в разработке «Робота-дозиметриста». Они позволяют сократить ряд основных проблем при дальнейшей разработке и эксплуатации робота, обеспечивая дополнительный контроль над ним и предоставляя ряд новых возможностей, таких как увеличенная дистанция беспроводного управления роботом.

Кроме того в Бортовом контроллере предусмотрены интерфейсы для подключения множества самых разных устройств, которые смогут расширить его функциональные возможности.

Разработанный протокол позволяет двум устройствам обмениваться данными с гарантией доставки этих данных. Так же он имеет широкие возможности для доработки, с целью создания более серьёзных систем. На его основе можно создать многопользовательский протокол для организации сети, использующей в качестве среды передачи данных радиоканал определённой частоты. Так же в дальнейшем можно использовать шифрование данных для этого протокола.

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

СПИСОК ЛИТЕРАТУРЫ

1. Лопаткин А. В.. P-CAD. - СПб.: БВХ - Петербург, 2006. - 560 с.

2. А. В. Белов. Самоучитель разработчика устройств на микроконтроллерах AVR. - М.: Наука и техника, 2010. - 544 с.

3. Шахнович И. Современные технологии беспроводной связи.- М.: Мир, 1987. - 608 с.

4. Семейство микроконтроллеров MSP430. Рекомендации по применению. - ЗАО «Компэл», 2005. - 544 с.

5. Семейство микроконтроллеров MSP430x1xx. - ЗАО «Компэл», 2005. - 368 с.

6. Лобкова Л. М. Проектирование антенн и устройств СВЧ. - СевНТУ, 2002. - 147 с.

7. CC430 Family User's Guide (Rev. B). SLAU259B - Texas Instruments, 2010 - 640с.

8. CC430x1xx Family User's Guide (Rev. F). SLAU049B - Texas Instruments, 2006 - 625с.

8. Раймонд Мэк. Импульсные источники питания. Теоретические основы проектирования и руководство по практическому применению. - М: Додэка XXI, 2008. - 274 с.

9. Горвард Джонсон, Мартин Грэхем. Высокоскоростная передача цифровых данных: высший курс черной магии. - Вильямс, 2005. - 997 с.

10. Джон Мортон. Микроконтроллеры AVR. Вводный курс. - М: Додэка-ХХI, 2006. - 272 с.

11. Феер К. Беспроводная цифровая связь: методы модуляции. -- Пер. с англ. // Под. ред. В. И. Журавлёва. -- М.: Радио и связь, 2000. -- 520 с.

12. Kent Smith. Antennas for low power application. - 2001 http://www.mplab.ru/rfmod/ant.pdf

13. Wikipedia (http://ru.wikipedia.org/wiki/ Последовательный_порт) - интернет ресурс

14. Агуров П.В. - Интерфейс USB. Практика использования и программирования. - СПб.: БВХ - Петербург, 2004. - 576 с.

ПРИЛОЖЕНИЕ 1. РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ.

Инструкция по программированию МК

Программирование осуществляется при помощи программатора MSP-GANG430. MSP-GANG430 может запрограммировать до восьми идентичных MSP430 устройств одновременно. MSP-GANG430 подключается к ПК с использованием стандартного RS232 последовательного порта. MSP-GANG430 предоставляет гибкие возможности программирования устройств.

MSP-GANG430 оснащен платой расширения, реализующего взаимосвязь между MSP-GANG430 и несколькими восьми устройствами.

Программирование микроконтроллера выполняется при помощи следующей последовательности действий:

1. Подключите MSP-GANG430 к последовательному порту ПК (COM1 или COM15).

2. Подключите внешний источник питания для MSP-GANG430. Напряжение питания должно находиться в диапазоне от 9В до 15В постоянного тока и должны быть способно, обеспечить минимальный ток 300 мА.

3. Установите плату расширения. D-Sub разъем на MSP-GANG430. Плата расширения обеспечивает подключение до восьми устройств.

4. Установите последнюю версию программного обеспечения, которое можно загрузить с веб-сайта MSP430 в www.msp430.com.

5. Нажмите на иконку GANG430 находящуюся в папке, указанной при установке программного обеспечения (по умолчанию папка ADT430). Графический интерфейс программы изображён на рис.6.2.

6. Выберите нужные устройства в закладках «группы» и «тип».

7. Подключите к плате расширения устройства, которые необходимо запрограммировать.

8. После подключения нажмите на кнопку Start находящуюся на программаторе.

9. Выберите файл, объектный код которого должен быть запрограммирован в устройство. Поддерживаемые форматы для файла кода .TXT и .HEX

10. Используйте кнопку Load Image, чтобы загрузить файл объектного кода и его контрольную сумму для MSP-GANG430.

11. Выберите напряжение, используя закладку напряжения питания.

12. Выберите необходимые параметры, находящиеся в основном окне программы.

13. Нажмите на кнопку Execute в главном разделе. В разделе Статус отображаются операций прогресса и завершения.

Перечень элементов

Листинг 1

#include 'main.h'

#include 'LCD.h'

#include 'ADC.h'

#include 'CoupleProto.h'

#include 'RF_coreMod.h'

unsigned int buttonCnt = 0;

unsigned int buttonPressed = 0;

unsigned int ButtonSet = 0;

unsigned int lastDisp = 0;

unsigned char flagfinInt = 0;

unsigned char slip = 0;

unsigned char idself[10] = {0};

unsigned char msg[8] = {' ',' ',' ',' ',' ',' ',' ',' '};

unsigned char* data = 0;

int main( void )

{

WDTCTL = WDTPW + WDTHOLD;

SetVCore(3);

InitButtonLeds();

InitTimer();

ResetRadioCore();

InitAdc();

InitRadio();

ReceiveOff();

int h =6;

while (h--)

data[h] = 0;

get(idself);

while(1)

{

slip = 1;

__bis_SR_register( LPM3_bits + GIE );

__no_operation();

if (!initSys)

{

switch (ButtonSet)

{

case 1:

ClientInit();

break;

case 7:

ServerInit();

break;

default:

ButtonSet =0;

break;

}

}

if(initSys)

{

if(chReceiving())

{

RecDataProto(data, 6);

ReceiveOn();

}

else

{

switch (ButtonSet)

{

case 1:

ClientInit();

break;

case 2:

ClientInit();

ClientInit();

break;

case 7:

ServerInit();

break;

default:

ButtonSet =0;

break;

}

}

}

}

void InitButtonLeds(void)

{

P5SEL |= 0xc0;

// Set up the button as interruptible

P2DIR &= ~(0x07);

P2REN |= 0x07;

P2IES |= 0x07;

P2IFG = 0;

P2OUT |= 0x07;

P2IE |= 0x07;

// Initialize Port J

PJOUT = 0x00;

PJDIR = 0xFF;

// Set up LEDs

P2DIR |= BIT6 + BIT7;

P2OUT |= BIT6 + BIT7;

}

void InitTimer(void)

{

P5SEL |= 0x03; // Set xtal pins

LFXT_Start(XT1DRIVE_0);

TA0CTL = TASSEL__ACLK + TACLR; // ACLK source

}

void InitRadio(void)

{

PMMCTL0_H = 0xA5;

PMMCTL0_L |= PMMHPMRE_L;

PMMCTL0_H = 0x00;

WriteRfSettings(&rfSettings);

WriteSinglePATable(PATABLE_VAL);

}

void Wait(void)

{

TA0CTL &= ~(MC_3);

TA0CCR2 = 3277;

TA0CCTL2 |= CCIE;

TA0CTL |= MC_2 + TACLR;

}

void WaitDisp(unsigned int Time, unsigned char* action)

{

Init_LCD();

lastDisp = Time * 10;

Load_LCD_Memory(action);

Wait();

}

void ChButton (void)

{

TA0CCTL2 &= ~(CCIE);

unsigned char n = (P2IFG & 0x07);

if (!(flagfinInt & n))

{

if (!(P2IN & n))

buttonCnt++;

else

{

buttonPressed = 0;

ButtonSet = n;

}

if ((buttonCnt == 30)&&(buttonPressed))

{

buttonPressed = 0;

ButtonSet = 8 + n;

flagfinInt |= n;

}

}

else

{

P2IES &= 1;

flagfinInt &= ~n;

buttonPressed = 0;

}

}

#pragma vector=TIMER0_A1_VECTOR

__interrupt void TIMER0_A1_ISR(void)

{

switch(__even_in_range(TA0IV,14))

{

case 0: break;

case 2:

if(chReceiving())

{

TA0CCR1 += RX_TIMER_PERIOD; // 16 cycles * 1/32768 = ~500 us

for(int i=0; i<8; i++)

msg[i]=' ';

msg[0]='P';

msg[1]='t';

msg[2]='r';

WaitDisp(5, msg);

pktRxHandler();

if(chPacketReceived())

__bic_SR_register_on_exit(LPM3_bits);

}

else if(chTransmitting())

{

TA0CCR1 += TX_TIMER_PERIOD; // 16 cycles * 1/32768 = ~500 us

for(int i=0; i<8; i++)

msg[i]=' ';

msg[0]='P';

msg[1]='t';

msg[2]='t';

WaitDisp(5, msg);

pktTxHandler();

if(chPacketTransmit())

__bic_SR_register_on_exit(LPM3_bits);

}

else if (chCProtoFlagWait() == 1)

{

setCProtoTimeOut(1);

__bic_SR_register_on_exit(LPM3_bits);

}

break;

case 4:

TA0CTL &= ~(MC_3);

if(buttonPressed)

{

ChButton();

if (!buttonPressed)

{

P2IFG = 0;

P2IE |= 0x07;

if(slip)

{

__bic_SR_register_on_exit(LPM3_bits);

slip = 0;

}

}

else

Wait();

}

if (lastDisp)

{

lastDisp--;

Wait();

if (!lastDisp)

{

ClearDisplayDriverMemory();

LCDBCTL0 &= ~LCDON;

P2OUT |= BIT6 + BIT7;

}

}

break;

case 6: break; // Reserved not used

case 8: break; // Reserved not used

case 10: break; // Reserved not used

case 12: break; // Reserved not used

case 14: break; // Overflow not used

}

}

#pragma vector=PORT2_VECTOR

__interrupt void PORT2_ISR(void)

{

switch(__even_in_range(P2IV, 16))

{

case 0: break;

case 2: // P2.0 IFG

__delay_cycles(100);

buttonPressed = 1;

P2IE &= ~BIT0;

P2IFG |= 0x01;

buttonCnt = 0;

Wait();

break;

case 4: // P2.1 IFG

__delay_cycles(100);

buttonPressed =1;

P2IE &= ~BIT1;

P2IFG |= 0x02;

buttonCnt = 0;

Wait();

break;

case 6: // P2.2 IFG

__delay_cycles(100);

buttonPressed =1;

P2IE &= ~BIT2;

P2IFG |= 0x04;

buttonCnt = 0;

ADC12CTL0 |= ADC12SC;

Wait();

break;

case 8: break; // P2.3 IFG

case 10: break; // P2.4 IFG

case 12: break; // P2.5 IFG

case 14: break; // P2.6 IFG

case 16: break; // P2.7 IFG

}

}

//------------------------------------------------------------------------------

#pragma vector=ADC12_VECTOR

__interrupt void ADC12ISR (void)

{

switch(__even_in_range(ADC12IV,34))

{

case 0: break; // Vector 0: No interrupt

case 2: break; // Vector 2: ADC overflow

case 4: break; // Vector 4: ADC timing overflow

case 6: // Vector 6: ADC12IFG0

TakeVolt(msg);

WaitDisp(5, msg);

break;

case 8: break; // Vector 8: ADC12IFG1

case 10: break; // Vector 10: ADC12IFG2

case 12: break; // Vector 12: ADC12IFG3

case 14: break; // Vector 14: ADC12IFG4

case 16: break; // Vector 16: ADC12IFG5

case 18: break; // Vector 18: ADC12IFG6

case 20: break; // Vector 20: ADC12IFG7

case 22: break; // Vector 22: ADC12IFG8

case 24: break; // Vector 24: ADC12IFG9

case 26: break; // Vector 26: ADC12IFG10

case 28: break; // Vector 28: ADC12IFG11

case 30: break; // Vector 30: ADC12IFG12

case 32: break; // Vector 32: ADC12IFG13

case 34: break; // Vector 34: ADC12IFG14

default: break;

}}

#pragma vector=CC1101_VECTOR

__interrupt void CC1101_ISR(void)

{

switch(__even_in_range(RF1AIV,32)) // Prioritizing Radio Core Interrupt

{

case 0: break; // No RF core interrupt pending

case 2: break; // RFIFG0

case 4: break; // RFIFG1

case 6: break; // RFIFG2

case 8: break; // RFIFG3

case 10: break; // RFIFG4

case 12: break; // RFIFG5

case 14: break; // RFIFG6

case 16: break; // RFIFG7

case 18: break; // RFIFG8

case 20: // RFIFG9

if(!(RF1AIES & BIT9)) // RX sync word received

{

for(int i=0; i<8; i++)

msg[i]=' ';

msg[0]='I';

msg[1]='n';

msg[2]='t';

WaitDisp(5, msg);

setReceiving(1);

__bic_SR_register_on_exit(LPM3_bits); // Exit active

}

break;

case 22: break; // RFIFG10

case 24: break; // RFIFG11

case 26: break; // RFIFG12

case 28: break; // RFIFG13

case 30: break; // RFIFG14

case 32: break; // RFIFG15

}

#ifndef MAIN_H_

#define MAIN_H_

#include 'cc430F6137.h'

#include 'RF_1_fun.h'

void InitButtonLeds(void);

void InitRadio(void);

void InitTimer(void);

void WaitDisp(unsigned int Time, unsigned char* action);

void ChButton(void);

void Wait(void);

void get(unsigned char* id);

#define PATABLE_VAL (0x51)

RF_SETTINGS rfSettings = {

0x08, // FSCTRL1 Frequency synthesizer control.

0x00, // FSCTRL0 Frequency synthesizer control.

0x23, // FREQ2 Frequency control word, high byte.

0x31, // FREQ1 Frequency control word, middle byte.

0x3B, // FREQ0 Frequency control word, low byte.

0xCA, // MDMCFG4 Modem configuration.

0x83, // MDMCFG3 Modem configuration.

0x93, // MDMCFG2 Modem configuration.

0x22, // MDMCFG1 Modem configuration.

0xF8, // MDMCFG0 Modem configuration.

0x00, // CHANNR Channel number.

0x34, // DEVIATN Modem deviation setting (when FSK modulation is enabled).

0x56, // FREND1 Front end RX configuration.

0x10, // FREND0 Front end TX configuration.

0x18, // MCSM0 Main Radio Control State Machine configuration.

0x16, // FOCCFG Frequency Offset Compensation Configuration.

0x6C, // BSCFG Bit synchronization Configuration.

0x43, // AGCCTRL2 AGC control.

0x40, // AGCCTRL1 AGC control.

0x91, // AGCCTRL0 AGC control.

0xE9, // FSCAL3 Frequency synthesizer calibration.

0x2A, // FSCAL2 Frequency synthesizer calibration.

0x00, // FSCAL1 Frequency synthesizer calibration.

0x1F, // FSCAL0 Frequency synthesizer calibration.

0x59, // FSTEST Frequency synthesizer calibration.

0x81, // TEST2 Various test settings.

0x35, // TEST1 Various test settings.

0x09, // TEST0 Various test settings.

0x47, // FIFOTHR RXFIFO and TXFIFO thresholds.

0x29, // IOCFG2 GDO2 output pin configuration.

0x06, // IOCFG0 GDO0 output pin configuration. Refer to SmartRF® Studio User Manual for detailed pseudo register explanation.

0x04, // PKTCTRL1 Packet automation control.

0x04, // PKTCTRL0 Packet automation control.

0x00, // ADDR Device address.

0x64 // PKTLEN Packet length.

};

#endif

#include 'CoupleProto.h'

#include 'RF_1_fun.h'

#include 'cc430F6137.h'

#include 'crc16.h'

unsigned char CProtoFlagOK = 0;

unsigned char CProtoIdSelf[10] = {0};

unsigned char CProtoIdPar[10] = {0};

unsigned char CProtoPos = 0;

unsigned char CProtoFlags = 0;

unsigned char CProtoFlagFail = 0;

unsigned char* CProtoGlobData;

unsigned int CProtoGlobDataLength = 0;

unsigned char RxBuffer[PACKET_LEN+2] = {0};

unsigned char TxBuffer[PACKET_LEN]= {0};

unsigned char CProtoTransmitting = 0;

unsigned char CProtoReceiving = 0;

unsigned char txBytesLeft = PACKET_LEN; // +1 for length byte

unsigned char txPosition = 0;

unsigned char rxBytesLeft = PACKET_LEN+2; // +2 for status bytes

unsigned char rxPosition = 0;

unsigned char lengthByteRead = 0;

unsigned short CProtoLastTime = 0;

unsigned int CProtoTimeLoop = 0;

unsigned char CProtoTimeOut = 0;

unsigned char CProtoFlagWait = 0;

unsigned char packetReceived = 0;

unsigned char packetTransmit = 0;

unsigned char transmitting = 0;

unsigned char receiving = 0;

char ClientInit(void)

{

char initSys = 0;

CProtoFlagOK = 0;

GetSelfId();

CProtoFlags = INIT_FLAG;

ReceiveOff();

FormMsg();

TransmitPacket();

ReceiveOn();

while((!initSys))&&(!ButtonSet))

{

__bis_SR_register( LPM3_bits + GIE );

__no_operation();

if(receiving)

{

ReceivePacket();

ChRecDataInit();

if(CProtoFlagOK)

{

GetParId();

initSys = 1;

FormMsg();

TransmitPacket();

}

else

ReceiveOn();

}

}

ReceiveOff();

return (initSys);

}

char ServerInit(void)

{

char initSys = 0;

int msgCnt = 0;

CProtoFlagOK = 0;

ReceiveOn();

while((!initSys))&&(!ButtonSet))

{

WaitSec(3);

if(receiving)

{

ReceivePacket();

ChRecDataInit();

if (CProtoFlagOK)

{

CProtoFlagOK = 0;

StopWaitTimer();

GetParId();

GetSelfId();

FormMsg();

while((!initSys)&&(msgCnt<3))

{

ReceiveOff();

TransmitPacket();

ReceiveOn();

CProtoTimeOut = 0;

while((!initSys)&&(!CProtoTimeOut))

{

WaitSec(1);

if(receiving)

{

ReceivePacket();

ChRecData( );

if(CProtoFlagOK)

initSys = 1;

else

ReceiveOn();

}

if(CProtoTimeOut)

msgCnt++;

}

}

StopWaitTimer();

}

receiving = 0;

}

}

StopWaitTimer();

ReceiveOff();

return (initSys);

}

char TransDataProto(unsigned char* Data_Buffer, int Data_Length)

{

CProtoGlobData = Data_Buffer;

CProtoGlobDataLength = Data_Length;

char msgCnt = 0;

CProtoFlagOK = 0;

CProtoFlags = 0;

CProtoPos++;

FormMsg();

while((!CProtoFlagOK)&&(msgCnt<3))

{

ReceiveOff();

TransmitPacket();

ReceiveOn();

CProtoTimeOut = 0;

while((!CProtoFlagOK)&&(!CProtoTimeOut))

{

WaitSec(3);

if(receiving)

{

ReceivePacket();

ChRecData();

ReceiveOn();

}

if(CProtoTimeOut)

msgCnt++;

}

}

StopWaitTimer();

return (CProtoFlagOK);

}

char RecDataProto(unsigned char* Data_Buffer, int Data_Length)

{

CProtoGlobDataLength = Data_Length;

CProtoFlagOK = 0;

ReceivePacket();

ChRecData();

if(!CProtoFlagOK)

{

CProtoGlobData = Data_Buffer;

GetData();

FormMsg();

TransmitPacket();

}

return (CProtoFlagOK);

}

void ReceiveOn(void)

{

RF1AIES &= ~BIT9;

RF1AIFG = 0;

RF1AIE |= BIT9;

Strobe( RF_SRX );

__no_operation();

}

void ReceiveOff(void)

{

RF1AIE &= ~BIT9;

RF1AIFG &= ~BIT9;

RF1AIES &= ~BIT9;

Strobe(RF_SIDLE);

Strobe(RF_SFRX);

}

void GetSelfId(void) //Вытаскивает_id_микроконтроллера-------------------

{

unsigned char *idadr;

idadr = 0x0000;

idadr = idadr + 0x0ff0;

for (int h=0; h<10; h++)

CProtoIdSelf[h] = *(idadr + h);

}

void GetParId(void)

{

for (int h=0; h<10; h++)

CProtoIdPar[h] = RxBuffer[h+10];

}

void GetData(void)

{

int h = 0;

while (h < CProtoGlobDataLength)

{

CProtoGlobData[CProtoGlobDataLength] = RxBuffer[22+h];

h++;

}

}

void FormMsg(void)

{

short crc;

for (int h=0; h<10; h++)

{

TxBuffer[h] = CProtoIdPar[h];

TxBuffer[h + 10] = CProtoIdSelf[h];

}

TxBuffer[20] = CProtoFlags;

TxBuffer[21] = CProtoPos;

int h=0;

while (h < CProtoGlobDataLength)

{

TxBuffer[22+h] = CProtoGlobData[CProtoGlobDataLength];

h++;

}

crc = CRC16(TxBuffer, 22 + CProtoGlobDataLength);

TxBuffer[23 + CProtoGlobDataLength] = crc;

TxBuffer[22 + CProtoGlobDataLength] = crc>>8;

}

void ChRecData(void)

{

short crc, crcIn = 0;

CProtoFlagFail = 0;

CProtoFlags = 0;

for (int h=0; h<10; h++)

{

if((CProtoIdSelf[h] != RxBuffer[h])||(CProtoIdPar[h] != RxBuffer[h + 10]))

{

CProtoFlagFail = 1;

break;

}

}

if(!CProtoFlagFail)

{

crc = CRC16(RxBuffer, PACKET_LEN + CProtoGlobDataLength - 2);

crcIn = RxBuffer[22 + CProtoGlobDataLength];

crcIn = crcIn<<8;

crcIn |= RxBuffer[23 + CProtoGlobDataLength];

if(crc != crcIn)

{

TxBuffer[21] = ERR_FLAG;

ReceiveOff();

TransmitPacket();

ReceiveOn();

CProtoFlagFail = 1;

}

else

{

switch (RxBuffer[20] & 0x30)

{

case 0x00:

if ((RxBuffer[20] == (CProtoPos + 1)) || (RxBuffer[20] == CProtoPos))

{

CProtoFlags |= ACK_FLAG;

if(RxBuffer[20] == (CProtoPos + 1))

CProtoPos++;

CProtoFlagOK = 1;

}

else

{

CProtoFlagFail = 1;

}

break;

case 0x20:

if (RxBuffer[20] == (CProtoPos - 1))

{

ReceiveOff();

TransmitPacket();

ReceiveOn();

CProtoFlagFail = 1;

}

else if (RxBuffer[20] == CProtoPos)

{

CProtoFlags = ACK_FLAG;

CProtoFlagOK = 1;

}

else

{CProtoFlagFail = 1;}

break;

case 0x10:

CProtoFlagOK = 1;

break;

default:

CProtoFlagFail = 1;

break;

}

}

}

}

void ChRecDataInit(void)

{

short crc, crcIn = 0;

CProtoFlagFail = 0;

CProtoFlags = 0;

if (RxBuffer[20] & 0x80)

{

crc = CRC16(RxBuffer, PACKET_LEN + CProtoGlobDataLength - 2);

crcIn = RxBuffer[22 + CProtoGlobDataLength];

crcIn = crcIn<<8;

crcIn |= RxBuffer[23 + CProtoGlobDataLength];

if(crc != crcIn)

{CProtoFlagFail = 1;}

else

{

CProtoPos++;

CProtoFlagOK = 1;

}

}

else if ((RxBuffer[21] == (CProtoPos + 1)) || (RxBuffer[21] == CProtoPos))

{

for (int h=0; h<10; h++)

{

if(CProtoIdSelf[h] != RxBuffer[h])

{

CProtoFlagFail = 1;

break;

}

}

if(!CProtoFlagFail)

{

crc = CRC16(RxBuffer, PACKET_LEN + CProtoGlobDataLength - 2);

crcIn = RxBuffer[22 + CProtoGlobDataLength];

crcIn = crcIn<<8;

crcIn |= RxBuffer[23 + CProtoGlobDataLength];

if(crc != crcIn)

{

TxBuffer[21] = ERR_FLAG;

ReceiveOff();

TransmitPacket();

ReceiveOn();

CProtoFlagFail = 1;

}

else

{

if (RxBuffer[21] == (CProtoPos + 1))

CProtoPos++;

CProtoFlags = ACK_FLAG;

}

}

}

}

void WaitSec(unsigned int Time)

{

if(CProtoFlagWait == 2)

{

TA0CTL &= ~(MC_3);

CProtoFlagWait = 1;

TA0CCR1 = CProtoLastTime;

if (TA0CCR1 < 50)

TA0CCR1 = 50;

TA0CCTL1 |= CCIE;

TA0CTL |= MC_2 + TACLR;

__bis_SR_register(LPM3_bits + GIE);

__no_operation();

TA0CCTL2 &= ~(CCIE);

}

if(!CProtoFlagWait)

{

CProtoTimeLoop = Time;

CProtoTimeOut = 1;

CProtoFlagWait = 1;

}

while((CProtoTimeLoop) && (CProtoTimeOut))

{

CProtoTimeOut = 0;

CProtoTimeLoop--;

TA0CTL &= ~(MC_3);

TA0CCR1 = 32768;

TA0CCTL1 |= CCIE;

TA0CTL |= MC_2 + TACLR;

__bis_SR_register(LPM3_bits + GIE);

__no_operation();

TA0CCTL2 &= ~(CCIE);

}

if(CProtoTimeOut)

{

CProtoFlagWait = 0;

}

else

{

CProtoFlagWait = 2;

CProtoLastTime = TA0CCR2;

}

}

void StopWaitTimer(void)

{

TA0CCR2 = 32768;

TA0CCTL2 &= ~(CCIE);

CProtoTimeLoop = 0;

CProtoTimeOut = 0;

CProtoFlagWait = 0;

}

void ReceivePacket(void)

{

rxBytesLeft = PACKET_LEN + CProtoGlobDataLength + 2;// Set maximum packet leng + 2 for appended bytes

rxPosition = 0;

packetReceived = 0;

__delay_cycles(2800); // Wait for bytes to fill in RX FIFO

TA0CTL &= ~(MC_3);

TA0CCR1 = RX_TIMER_PERIOD; // x cycles * 1/32768 = y us

TA0CCTL1 |= CCIE;

TA0CTL |= MC_2 + TACLR; // Start the timer- continuous mode

__bis_SR_register(LPM3_bits + GIE);

__no_operation();

TA0CCR1 = RX_TIMER_PERIOD;

TA0CCTL1 &= ~(CCIE);

//TA0CTL &= ~(MC_3); // Turn off timer

__no_operation();

}

void TransmitPacket(void)

{

P2OUT |= BIT6; // Pulse LED during Transmit

txBytesLeft = PACKET_LEN + CProtoGlobDataLength;

txPosition = 0;

packetTransmit = 0;

transmitting = 1;

Strobe( RF_STX ); // Strobe STX

TA0CTL &= ~(MC_3);

TA0CCR1 = TX_TIMER_PERIOD; // x cycles * 1/32768 = y us

TA0CCTL1 |= CCIE;

TA0CTL |= MC_2 + TACLR; // Start the timer- continuous mode

__bis_SR_register(LPM3_bits + GIE);

__no_operation();

TA0CCR1 = TX_TIMER_PERIOD; // x cycles * 1/32768 = y us

TA0CCTL1 &= ~(CCIE);

// TA0CTL &= ~(MC_3); // Turn off timer

P2OUT &= ~BIT6; // Turn off LED after Transmit

}

void pktRxHandler(void) {

unsigned char RxStatus;

unsigned char bytesInFifo;

RxStatus = Strobe(RF_SNOP);

switch(RxStatus & CC430_STATE_MASK)

{

case CC430_STATE_RX:

if (bytesInFifo = MIN(rxBytesLeft, RxStatus & CC430_FIFO_BYTES_AVAILABLE_MASK))

{

rxBytesLeft -= bytesInFifo;

while (bytesInFifo--) {

RxBuffer[rxPosition] = ReadSingleReg(RXFIFO);

rxPosition++;

}

if (!rxBytesLeft){

packetReceived = 1;

receiving = 0;

lengthByteRead = 0;

ReceiveOff();

P2OUT ^= BIT7;

}

}

break;

default:

if(!packetReceived)

{

packetReceived = 1;

}

rxBytesLeft = 0;

receiving = 0;

ReceiveOff();

break;

}

}

void pktTxHandler(void) {

unsigned char freeSpaceInFifo;

unsigned char TxStatus;

TxStatus = Strobe(RF_SNOP);

switch (TxStatus & CC430_STATE_MASK) {

case CC430_STATE_TX:

if (freeSpaceInFifo = MIN(txBytesLeft, TxStatus & CC430_FIFO_BYTES_AVAILABLE_MASK))

{

txBytesLeft -= freeSpaceInFifo;

while(freeSpaceInFifo--)

{

WriteSingleReg(TXFIFO, TxBuffer[txPosition]);

txPosition++;

}

if(!txBytesLeft)

{

RF1AIES |= BIT9; // End-of-packet TX interrupt

RF1AIFG &= ~BIT9; // clear RFIFG9

while(!(RF1AIFG & BIT9)); // poll RFIFG9 for TX end-of-packet

RF1AIES &= ~BIT9; // End-of-packet TX interrupt

RF1AIFG &= ~BIT9; // clear RFIFG9

transmitting = 0;

packetTransmit = 1;

}

}

break;

case CC430_STATE_TX_UNDERFLOW:

Strobe(RF_SFTX); // Flush the TX FIFO

__no_operation();

default:

if(!packetTransmit)

packetTransmit = 1;

if (transmitting) {

if ((TxStatus & CC430_STATE_MASK) == CC430_STATE_IDLE) {

transmitting = 0;

}

}

break;

}

}

unsigned char chCProtoFlagWait(void)

{

return (CProtoFlagWait);

}

void setCProtoTimeOut(unsigned char flag)

{

CProtoTimeOut = flag;

}

unsigned char chPacketReceived(void)

{

return (packetReceived);

}

unsigned char chPacketTransmit(void)

{

return (packetTransmit);

}

unsigned char chReceiving(void)

{

return (receiving);

}

unsigned char chTransmitting(void)

{

return (transmitting);

}

void setReceiving(unsigned char flag)

{

receiving = flag;

}

void setTransmitting(unsigned char flag)

{

transmitting = flag;

}

#include 'cc430f6137.h'

#include 'ADC.h'

void InitAdc(void)

{

P2SEL |= BIT3;

ADC12CTL0 = ADC12ON+ADC12SHT02; // Turn on ADC12, set sampling time

ADC12CTL1 = ADC12SHP; // Use sampling timer

ADC12MCTL0 = ADC12SREF_1; // Vr+=Vref+ and Vr-=AVss

}

int TakeVot(int maxVolt)

{

ADC12CTL0 |= ADC12SC;

while (!(ADC12IFG & BIT0));

int Voltage = (int)(((long)ADC12MEM0*maxVolt*100)/4095);

return (Voltage);

}

#include 'crc16.h'

const unsigned short CRC16_Table[256] = {

0x0000, 0x1021, 0x2042, 0x3063, 0x4084, 0x50A5, 0x60C6, 0x70E7,

0x8108, 0x9129, 0xA14A, 0xB16B, 0xC18C, 0xD1AD, 0xE1CE, 0xF1EF,

0x1231, 0x0210, 0x3273, 0x2252, 0x52B5, 0x4294, 0x72F7, 0x62D6,

0x9339, 0x8318, 0xB37B, 0xA35A, 0xD3BD, 0xC39C, 0xF3FF, 0xE3DE,

0x2462, 0x3443, 0x0420, 0x1401, 0x64E6, 0x74C7, 0x44A4, 0x5485,

0xA56A, 0xB54B, 0x8528, 0x9509, 0xE5EE, 0xF5CF, 0xC5AC, 0xD58D,

0x3653, 0x2672, 0x1611, 0x0630, 0x76D7, 0x66F6, 0x5695, 0x46B4,

0xB75B, 0xA77A, 0x9719, 0x8738, 0xF7DF, 0xE7FE, 0xD79D, 0xC7BC,

0x48C4, 0x58E5, 0x6886, 0x78A7, 0x0840, 0x1861, 0x2802, 0x3823,

0xC9CC, 0xD9ED, 0xE98E, 0xF9AF, 0x8948, 0x9969, 0xA90A, 0xB92B,

0x5AF5, 0x4AD4, 0x7AB7, 0x6A96, 0x1A71, 0x0A50, 0x3A33, 0x2A12,

0xDBFD, 0xCBDC, 0xFBBF, 0xEB9E, 0x9B79, 0x8B58, 0xBB3B, 0xAB1A,

0x6CA6, 0x7C87, 0x4CE4, 0x5CC5, 0x2C22, 0x3C03, 0x0C60, 0x1C41,

0xEDAE, 0xFD8F, 0xCDEC, 0xDDCD, 0xAD2A, 0xBD0B, 0x8D68, 0x9D49,

0x7E97, 0x6EB6, 0x5ED5, 0x4EF4, 0x3E13, 0x2E32, 0x1E51, 0x0E70,

0xFF9F, 0xEFBE, 0xDFDD, 0xCFFC, 0xBF1B, 0xAF3A, 0x9F59, 0x8F78,

0x9188, 0x81A9, 0xB1CA, 0xA1EB, 0xD10C, 0xC12D, 0xF14E, 0xE16F,

0x1080, 0x00A1, 0x30C2, 0x20E3, 0x5004, 0x4025, 0x7046, 0x6067,

0x83B9, 0x9398, 0xA3FB, 0xB3DA, 0xC33D, 0xD31C, 0xE37F, 0xF35E,

0x02B1, 0x1290, 0x22F3, 0x32D2, 0x4235, 0x5214, 0x6277, 0x7256,

0xB5EA, 0xA5CB, 0x95A8, 0x8589, 0xF56E, 0xE54F, 0xD52C, 0xC50D,

0x34E2, 0x24C3, 0x14A0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405,

0xA7DB, 0xB7FA, 0x8799, 0x97B8, 0xE75F, 0xF77E, 0xC71D, 0xD73C,

0x26D3, 0x36F2, 0x0691, 0x16B0, 0x6657, 0x7676, 0x4615, 0x5634,

0xD94C, 0xC96D, 0xF90E, 0xE92F, 0x99C8, 0x89E9, 0xB98A, 0xA9AB,

0x5844, 0x4865, 0x7806, 0x6827, 0x18C0, 0x08E1, 0x3882, 0x28A3,

0xCB7D, 0xDB5C, 0xEB3F, 0xFB1E, 0x8BF9, 0x9BD8, 0xABBB, 0xBB9A,

0x4A75, 0x5A54, 0x6A37, 0x7A16, 0x0AF1, 0x1AD0, 0x2AB3, 0x3A92,

0xFD2E, 0xED0F, 0xDD6C, 0xCD4D, 0xBDAA, 0xAD8B, 0x9DE8, 0x8DC9,

0x7C26, 0x6C07, 0x5C64, 0x4C45, 0x3CA2, 0x2C83, 0x1CE0, 0x0CC1,

0xEF1F, 0xFF3E, 0xCF5D, 0xDF7C, 0xAF9B, 0xBFBA, 0x8FD9, 0x9FF8,

0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0

};

unsigned short CRC16(unsigned char *BufI, unsigned short LenB)

{

unsigned short crc, i0;

crc = 0xFFFF; i0 = LenB;

while(i0--)

crc = (crc << 8) ^ CRC16_Table[(crc >> 8) ^ *BufI++];

return(crc);

}

#include 'LCD.h'

const unsigned int ascii_to_lcd_digit_e [] =

{

0,/*DW 0 ; displays 'SP' */

0,/*DW 0 ; displays '!' */

0,/*DW 0 ; displays ' ' '*/

0,/*DW 0 ; displays '#' */

0,/*DW 0 ; displays '$' */

0,/*DW 0 ; displays '%' */

0,/*DW 0 ; displays '&' */

0,/*DW 0 ; displays ' ' '*/

0,/*DW 0 ; displays '(' */

0,/*DW 0 ; displays ')' */

0,/*DW 0 ; displays '*' */

0,/*DW 0 ; displays '+' */

0,/*DW 0 ; displays ',' */

g__,/*DW g ; displays '-' */

0,/*DW 0 ; displays '.' */

0,/*DW 0 ; displays '/' */

/*30*/ a__+b__+c__+d__+e__+f__,/*DW a+b+c+d+e+f ; displays '0' */

b__+c__,/*DW b+c ; displays '1' */

a__+b__+g__+e__+d__,/*DW a+b+g+e+d ; displays '2' */

a__+b__+c__+d__+g__,/*DW a+b+c+d+g ; displays '3' */

b__+c__+f__+g__,/*DW b+c+f+g ; displays '4' */

a__+c__+d__+f__+g__,/*DW a+c+d+f+g ; displays '5' */

a__+c__+d__+e__+f__+g__,/*DW a+c+d+e+f+g ; displays '6' */

a__+b__+c__,/*DW a+b+c ; displays '7' */

a__+b__+c__+d__+e__+f__+g__,/*DW a+b+c+d+e+f+g ; displays '8' */

a__+b__+c__+d__+f__+g__,/*DW a+b+c+d+f+g ; displays '9' */

0,/*DW colon ; displays ':' */

0,/*DW 0 ; displays ';' */

0,/*DW 0 ; displays '<' */

0,/*DW 0 ; displays '=' */

0,/*DW 0 ; displays '>' */

0,/*DW 0 ; displays '?' */

0,/*DW 0 ; displays '@' */

/*41*/ a__+b__+c__+e__+f__+g__,/*DW a+b+c+e+f+g ; displays 'A' */

0,/*DW 0 ; displays 'B' */

a__+d__+e__+f__,/*DW a+d+e+f ; displays 'C' */

0,/*DW 0 ; displays 'D' */

a__+d__+e__+f__+g__,/*DW a+d+e+f+g ; displays 'E' */

a__+e__+f__+g__,/*DW a+e+f+g ; displays 'F' */

0,/*DW 0 ; displays 'G' */

b__+c__+e__+f__+g__,/*DW b+c+e+f+g ; displays 'H' */

b__+c__,/*DW b+c ; displays 'I' */

b__+c__+d__+e__,/*DW 0 ; displays 'J' */

0,/*DW 0 ; displays 'K' */

d__+e__+f__,/*DW d+e+f ; displays 'L' */

0,/*DW 0 ; displays 'M' */

0,/*DW 0 ; displays 'N' */

a__+b__+c__+d__+e__+f__,/*DW a+b+c+d+e+f ; displays 'O' big*/

/*50*/ a__+b__+e__+f__+g__,/*DW a+b+e+f+g ; displays 'P' */

0,/*DW 0 ; displays 'Q' */

0,/*DW 0 ; displays 'R' */

a__+c__+d__+f__+g__,/*DW a+c+d+f+g ; displays 'S' */

0,/*DW 0 ; displays 'T' */

c__+d__+e__+f__+b__,/*DW c+d+e+f+b ; displays 'U' */

0,/*DW 0 ; displays 'V' */

0,/*DW 0 ; displays 'W' */

0,/*DW 0 ; displays 'X' */

c__+d__+f__+g__+b__,/*DW e+f+g+b ; displays 'Y' */

a__+b__+e__+g__+d__,/*DW a+b+e+g+d ; displays 'Z' */

e__+f__+a__+d__,/*DW e+f+a+d ; displays '[' */

0,/*DW 0 ; displays '' */

a__+d__+b__+c__,/*DW a+d+b+c ; displays ']' */

0,/*DW 0 ; displays '^' */

d__,/*DW d ; displays '_' */

/*60*/ 0,/*DW 0 ; displays ' ' ' */

0,/*DW 0 ; displays 'a' */

c__+d__+e__+f__+g__,/*DW c+d+e+f+g ; displays 'b' */

g__+d__+e__,/*DW g+d+e ; displays 'c' */

b__+c__+d__+e__+g__,/*DW b+c+d+e+g ; displays 'd' */

0,/*DW 0 ; displays 'e' */

0,/*DW 0 ; displays 'f' */

0,/*DW 0 ; displays 'g' */

c__+e__+f__+g__,/*DW c+e+f+g ; displays 'h' */

c__,/*DW c ; displays 'i' */

b__+c__+d__+e__,/*DW b+c+d+e ; displays 'j' */

0,/*DW 0 ; displays 'k' */

b__+c__,/*DW b+c ; displays 'l' */

0,/*DW 0 ; displays 'm' */

e__+c__+g__,/*DW e+c+g ; displays 'n' */

c__+d__+e__+g__,/*DW c+d+e+g ; displays 'o' */

0,/*DW 0 ; displays 'p' */

a__+b__+c__+f__+g__,/*DW a+b+c+f+g ; displays 'q' */

e__+g__,/*DW e+g ; displays 'r' */

0,/*DW 0 ; displays 's' */

d__+e__+f__+g__,/*DW 0 ; displays 't' */

c__+d__+e__ //,/*DW c+d+e ; displays 'u' */

// 0,/*DW 0 ; displays 'v' */

// 0,/*DW 0 ; displays 'w' */

// 0,/*DW 0 ; displays 'x' */

// 0,/*DW 0 ; displays 'y' */

// 0,/*DW 0 ; displays 'z' */

// 0,/*DW 0 ; displays '{' */

// e__+f__,/*DW e+f ; displays '|' */

// 0,/*DW 0 ; displays '}' */

// 0/*DW 0 */

};

void Config_LCD_Driver (void)

{

LCDBCTL0 = ~LCDON;

LCDBCTL0 = (LCDDIV2 + LCDDIV3) | (LCDPRE0 + LCDPRE1) | LCD4MUX;

LCDBPCTL0 = 0xFFFF;

LCDBPCTL1 = 0x00FF;

LCDBCTL0 |= LCDON;

}

void ClearDisplayDriverMemory(void)

{

int i;

char *LCD = LCDMEM;

for (i=0; i<12; i++)

{

LCD[i] = 0;

}

}

void Init_LCD (void)

{

Config_LCD_Driver();

ClearDisplayDriverMemory();

}

void Load_LCD_Memory(uchar* Video_Buffer)

{

ClearDisplayDriverMemory();

unsigned int temp;

char *mem;

mem = LCDMEM;

for (unsigned char i=0; i<8; i++)

{

temp = ascii_to_lcd_digit_e [Video_Buffer[i]-0x20];

*mem = (unsigned char)temp;

mem++;

temp = temp>>8;

*mem = (unsigned char)temp;

i++;

temp = ascii_to_lcd_digit_e [Video_Buffer[i]-0x20];

temp = temp<<4;

*mem |= (unsigned char)temp;

mem++;

temp = temp>>8;

*mem |= (unsigned char)temp;

mem++;

}

}

#include 'msp430.h'

#include 'RF_coreMod.h'

#define _HAL_PMM_DISABLE_SVML_

#define _HAL_PMM_DISABLE_SVSL_

#define _HAL_PMM_DISABLE_FULL_PERFORMANCE_

#ifdef _HAL_PMM_DISABLE_SVML_

#define _HAL_PMM_SVMLE SVMLE

#else

#define _HAL_PMM_SVMLE 0

#endif

#ifdef _HAL_PMM_DISABLE_SVSL_

#define _HAL_PMM_SVSLE SVSLE

#else

#define _HAL_PMM_SVSLE 0

#endif

#ifdef _HAL_PMM_DISABLE_FULL_PERFORMANCE_

#define _HAL_PMM_SVSFP SVSLFP

#else

#define _HAL_PMM_SVSFP 0

#endif

unsigned int SetVCore (unsigned char level)

{

unsigned int actlevel;

unsigned int status = 0;

level &= PMMCOREV_3; // Set Mask for Max. level

actlevel = (PMMCTL0 & PMMCOREV_3); // Get actual VCore

while (((level != actlevel) && (status == 0)) || (level < actlevel))

{

if (level > actlevel)

status = SetVCoreUp(++actlevel);

else

status = SetVCoreDown(--actlevel);

}

return status;

}

unsigned int SetVCoreUp (unsigned char level)

{

unsigned int PMMRIE_backup,SVSMHCTL_backup;

PMMCTL0_H = 0xA5;

cleared

PMMRIE_backup = PMMRIE;

PMMRIE &= ~(SVSMHDLYIE | SVSMLDLYIE | SVMLVLRIE | SVMHVLRIE | SVMHVLRPE);

possible

SVSMHCTL_backup = SVSMHCTL;

PMMIFG &= ~(SVMHIFG | SVSMHDLYIFG);

SVSMHCTL = SVMHE | SVMHFP | (SVSMHRRL0 * level);

while ((PMMIFG & SVSMHDLYIFG) == 0);

SVSMHCTL &= ~_HAL_PMM_SVSFP ;

if ((PMMIFG & SVMHIFG) == SVMHIFG){ //-> Vcc is to low for a Vcore increase

PMMIFG &= ~SVSMHDLYIFG;

SVSMHCTL = SVSMHCTL_backup;

while ((PMMIFG & SVSMHDLYIFG) == 0);

PMMIFG &= ~(SVMHVLRIFG | SVMHIFG | SVSMHDLYIFG | SVMLVLRIFG | SVMLIFG | SVSMLDLYIFG);

PMMRIE = PMMRIE_backup;

PMMCTL0_H = 0x00;

return PMM_STATUS_ERROR; // return: voltage not set

}

for a Vcore increase

SVSMHCTL |= SVSHE | (SVSHRVL0 * level);

SVSMLCTL = SVMLE | SVMLFP | (SVSMLRRL0 * level);

while ((PMMIFG & SVSMLDLYIFG) == 0);

PMMIFG &= ~(SVMLVLRIFG | SVMLIFG);

PMMCTL0_L = PMMCOREV0 * level;

if (PMMIFG & SVMLIFG)

while ((PMMIFG & SVMLVLRIFG) == 0);

PMMIFG &= ~SVSMLDLYIFG;

SVSMLCTL |= SVSLE | (SVSLRVL0 * level);

while ((PMMIFG & SVSMLDLYIFG) == 0);

SVSMLCTL &= ~(_HAL_PMM_DISABLE_SVSL_+_HAL_PMM_DISABLE_SVML_+_HAL_PMM_SVSFP );

PMMIFG &= ~(SVMHVLRIFG | SVMHIFG | SVSMHDLYIFG | SVMLVLRIFG | SVMLIFG | SVSMLDLYIFG);

PMMRIE = PMMRIE_backup;

PMMCTL0_H = 0x00;

return PMM_STATUS_OK; // return: OK

}

unsigned int SetVCoreDown (unsigned char level)

{

unsigned int PMMRIE_backup;

PMMCTL0_H = 0xA5;

cleared

PMMRIE_backup = PMMRIE;

PMMRIE &= ~(SVSMHDLYIE | SVSMLDLYIE | SVMLVLRIE | SVMHVLRIE | SVMHVLRPE);

PMMIFG &= ~(SVMHIFG | SVSMHDLYIFG | SVMLIFG | SVSMLDLYIFG);

SVSMHCTL = SVMHE | SVMHFP | (SVSMHRRL0 * level);

SVSMLCTL = SVMLE | SVMLFP | (SVSMLRRL0 * level);

while ((PMMIFG & SVSMHDLYIFG) == 0 || (PMMIFG & SVSMLDLYIFG) == 0);

PMMCTL0_L = PMMCOREV0 * level;

PMMIFG &= ~(SVSHIFG | SVSMHDLYIFG | SVSLIFG | SVSMLDLYIFG);

SVSMHCTL |= SVSHE | SVSHFP | (SVSHRVL0 * level);

SVSMLCTL |= SVSLE | SVSLFP | (SVSLRVL0 * level);

while ((PMMIFG & SVSMHDLYIFG) == 0 || (PMMIFG & SVSMLDLYIFG) == 0);

SVSMHCTL &= ~_HAL_PMM_SVSFP;

SVSMLCTL &= ~ (_HAL_PMM_DISABLE_SVSL_+_HAL_PMM_DISABLE_SVML_+_HAL_PMM_SVSFP );

PMMIFG &= ~(SVMHVLRIFG | SVMHIFG | SVSMHDLYIFG | SVMLVLRIFG | SVMLIFG | SVSMLDLYIFG);

PMMRIE = PMMRIE_backup;

PMMCTL0_H = 0x00;

if ((PMMIFG & SVMHIFG) == SVMHIFG)

return PMM_STATUS_ERROR; // Highside is still to low for the adjusted VCore Level

else return PMM_STATUS_OK; // Return: OK}

#include 'RF_1_fun.h'

#include 'cc430F6137.h'

unsigned char Strobe(unsigned char strobe)

{

unsigned char statusByte = 0;

unsigned int gdo_state;

if((strobe == 0xBD) || ((strobe >= RF_SRES) && (strobe <= RF_SNOP)))

{

RF1AIFCTL1 &= ~(RFSTATIFG);

while( !(RF1AIFCTL1 & RFINSTRIFG));

if ((strobe > RF_SRES) && (strobe < RF_SNOP))

{

gdo_state = ReadSingleReg(IOCFG2); // buffer IOCFG2 state

WriteSingleReg(IOCFG2, 0x29); // chip-ready to GDO2

RF1AINSTRB = strobe;

if ( (RF1AIN&0x04)== 0x04 ) // chip at sleep mode

{

if ( (strobe == RF_SXOFF) || (strobe == RF_SPWD) || (strobe == RF_SWOR) ) { }

else

{

while ((RF1AIN&0x04)== 0x04); // chip-ready ?

// Delay for ~810usec at 1.05MHz CPU clock, see erratum RF1A7

__delay_cycles(850);

}

}

WriteSingleReg(IOCFG2, gdo_state); // restore IOCFG2 setting

while( !(RF1AIFCTL1 & RFSTATIFG) );

}

else // chip active mode (SRES)

{

RF1AINSTRB = strobe;

}

statusByte = RF1ASTATB;

}

return statusByte;

}

unsigned char ReadSingleReg(unsigned char addr)

{

unsigned char data_out;

PATABLE

if ((addr <= 0x2E) || (addr == 0x3E))

RF1AINSTR1B = (addr | RF_SNGLREGRD);

else

RF1AINSTR1B = (addr | RF_STATREGRD);

while (!(RF1AIFCTL1 & RFDOUTIFG) );

data_out = RF1ADOUTB; // Read data and clears the RFDOUTIFG

return data_out;

}

void WriteSingleReg(unsigned char addr, unsigned char value)

{

while (!(RF1AIFCTL1 & RFINSTRIFG)); // Wait for the Radio to be ready for next instruction

RF1AINSTRB = (addr | RF_SNGLREGWR); // Send address + Instruction

RF1ADINB = value; // Write data in

__no_operation();

}

void ReadBurstReg(unsigned char addr, unsigned char *buffer, unsigned char count)

{

unsigned int i;

if(count > 0)

{

while (!(RF1AIFCTL1 & RFINSTRIFG));

RF1AINSTR1B = (addr | RF_REGRD); for (i = 0; i < (count-1); i++)

{

while (!(RFDOUTIFG&RF1AIFCTL1));

buffer[i] = RF1ADOUT1B;

}

buffer[count-1] = RF1ADOUT0B;

}

}

void WriteBurstReg(unsigned char addr, unsigned char *buffer, unsigned char count)

{

unsigned char i;

if(count > 0)

{

while (!(RF1AIFCTL1 & RFINSTRIFG));

RF1AINSTRW = ((addr | RF_REGWR)<<8 ) + buffer[0];

for (i = 1; i < count; i++)

{

RF1ADINB = buffer[i];

while (!(RFDINIFG & RF1AIFCTL1));

}

i = RF1ADOUTB;

}

}

void ResetRadioCore (void)

{

Strobe(RF_SRES);

Strobe(RF_SNOP);

}

void WriteRfSettings(RF_SETTINGS *pRfSettings) {

WriteSingleReg(FSCTRL1, pRfSettings->fsctrl1);

WriteSingleReg(FSCTRL0, pRfSettings->fsctrl0);

WriteSingleReg(FREQ2, pRfSettings->freq2);

WriteSingleReg(FREQ1, pRfSettings->freq1);

WriteSingleReg(FREQ0, pRfSettings->freq0);

WriteSingleReg(MDMCFG4, pRfSettings->mdmcfg4);

WriteSingleReg(MDMCFG3, pRfSettings->mdmcfg3);

WriteSingleReg(MDMCFG2, pRfSettings->mdmcfg2);

WriteSingleReg(MDMCFG1, pRfSettings->mdmcfg1);

WriteSingleReg(MDMCFG0, pRfSettings->mdmcfg0);

WriteSingleReg(CHANNR, pRfSettings->channr);

WriteSingleReg(DEVIATN, pRfSettings->deviatn);

WriteSingleReg(FREND1, pRfSettings->frend1);

WriteSingleReg(FREND0, pRfSettings->frend0);

WriteSingleReg(MCSM0 , pRfSettings->mcsm0);

WriteSingleReg(FOCCFG, pRfSettings->foccfg);

WriteSingleReg(BSCFG, pRfSettings->bscfg);

WriteSingleReg(AGCCTRL2, pRfSettings->agcctrl2);

WriteSingleReg(AGCCTRL1, pRfSettings->agcctrl1);

WriteSingleReg(AGCCTRL0, pRfSettings->agcctrl0);

WriteSingleReg(FSCAL3, pRfSettings->fscal3);

WriteSingleReg(FSCAL2, pRfSettings->fscal2);

WriteSingleReg(FSCAL1, pRfSettings->fscal1);

WriteSingleReg(FSCAL0, pRfSettings->fscal0);

WriteSingleReg(FSTEST, pRfSettings->fstest);

WriteSingleReg(TEST2, pRfSettings->test2);

WriteSingleReg(TEST1, pRfSettings->test1);

WriteSingleReg(TEST0, pRfSettings->test0);

WriteSingleReg(FIFOTHR, pRfSettings->fifothr);

WriteSingleReg(IOCFG2, pRfSettings->iocfg2);

WriteSingleReg(IOCFG0, pRfSettings->iocfg0);

WriteSingleReg(PKTCTRL1, pRfSettings->pktctrl1);

WriteSingleReg(PKTCTRL0, pRfSettings->pktctrl0);

WriteSingleReg(ADDR, pRfSettings->addr);

WriteSingleReg(PKTLEN, pRfSettings->pktlen);

}

void WriteSinglePATable(unsigned char value)

{

while( !(RF1AIFCTL1 & RFINSTRIFG));

RF1AINSTRW = 0x3E00 + value;

while( !(RF1AIFCTL1 & RFINSTRIFG));

RF1AINSTRB = RF_SNOP;

void WriteBurstPATable(unsigned char *buffer, unsigned char count)

{

volatile char i = 0;

while( !(RF1AIFCTL1 & RFINSTRIFG));

RF1AINSTRW = 0x7E00 + buffer[i];

for (i = 1; i < count; i++)

{

RF1ADINB = buffer[i];

while (!(RFDINIFG & RF1AIFCTL1));

}

i = RF1ADOUTB;

while( !(RF1AIFCTL1 & RFINSTRIFG));

RF1AINSTRB = RF_SNOP; }

void LFXT_Start(uint16_t xtdrive)

{

UCSCTL6_L |= XT1DRIVE1_L+XT1DRIVE0_L; startup

while (SFRIFG1 & OFIFG) {

UCSCTL7 &= ~(DCOFFG+XT1LFOFFG+XT1HFOFFG+XT2OFFG);

SFRIFG1 &= ~OFIFG; }

UCSCTL6 = (UCSCTL6 & ~(XT1DRIVE_3)) |(xtdrive); }