Журнал "Новости Электроники", номер 4, 2010 год.

Журнал "Новости Электроники", номер 4, 2010 год.Дорога к ╚Оазису╩, или практические вопросы перехода на операционную систему Oasis R7Дмитрий Поваляев (ОАО ╚НИИСА╩) В статье подробно описываются проблемы беспроводного процессора Q268 производства Sierra Wireless (линейка Wavecom), возникающие при работе с приложением Open AT, а также методы и алгоритмы их устранения. Также рассказывается об обновлении Oasis R7.4, в котором устранена проблема ╚зависания╩ (freeze) при циклическом чтении из шины I2C.

 

 

В 2008 г. в инициативном порядке в ОАО «Научно-исследовательский институт систем автоматизации» (ОАО «НИИСА») начата разработка навигационно-связных комплексов, функционирующих в составе диспетчерской системы. Носимое устройство должно обеспечивать пользователя голосовой телефонией стандарта GSM, определять собственное местоположение по сигналам GPS и передавать навигационную информацию по доступным каналам связи (GSM/GPRS, УКВ) на диспетчерский пункт. Дополнительно предусмотрен канал Bluetooth для отображения данных на КПК или ноутбуке.

Мобильный комплект предназначается для установки на транспортное средство (автомобиль, корабль или катер) в исполнении для внешнего монтажа. Мобильный комплект поддерживает все функции, присущие носимому варианту (кроме голоса), но имеет двойное питание (как от бортовой сети транспортного средства, так и от встроенной АКБ). Устройство также содержит дополнительные интерфейсы для логических датчиков, каналов управления, АЦП и шины CAN.

Сердцем носимого и мобильного устройства является беспроводной процессор Sierra Wireless (ранее Wavecom) Q2687 (рис. 1). В конструкции оказались задействованы практически все интерфейсы процессора, кроме параллельной шины и DAC. В частности, UART_1 используется как внешний порт для программирования и подключения внешних устройств, UART_2 - для взаимодействия с Bluetooth модулем, SPI_1 - передатчик УКВ, SPI_2 - интерфейс CAN и, наконец, I2C обеспечивает обмен информацией с GPS-приемником.

 

 

Рис. 1. Беспроводной процессор Q2687

Изначально приложение Open AT было создано под Open AT Firmware 6.63e, OS v4.24, SDK4.27. В процессе работы выяснилось, что при циклическом опросе шины I2C с периодом 0,5 с процессор как бы останавливался, замораживался (freeze) - т.е. прекращал выполнение приложения Open AT. При этом не выполнялся ни один таймер или функция, а процессор не реагировал на AT-команды, за исключением AT+WOPEN=0 (остановка встроенного приложения). В таком состоянии процессор находился до тех пор, пока его не перезагружали либо с помощью аппаратного сброса (hard reset), либо по срабатыванию внутреннего программного таймера перезапуска (software watchdog), что происходило через несколько минут после начала состояния «freeze». После перезагрузки процессор выдавал сообщение об ошибке вида «Except RTK ....144 a 2» (рис. 2). Описание этой ошибки в документации на OAT OSv4.24 я не нашел, однако встретил в документации на OAT OSv6.20: «144: Raised if too many items are pushed in the queue». Это можно найти в разделе «ADL Queue Service», но этот сервис в данной программе не используется.

 

 

Рис. 2. Отладка программы

Мои попытки выяснить причину закончились на следующей мысли: возможно, всему виной искажения сигнала по шине, возникающие из-за несогласованности подключенных подтягивающих (pull-up) резисторов и результирующей емкости проводников шины I2C. Вследствие этого факта можно было наблюдать разную картину частоты «зависаний» на разных изделиях с различной топологией проводников шины I2C и, следовательно, с различной емкостью проводников шины. Картина также менялась с изменением номиналов подтягивающих резисторов, подключаемых к шине одного и того же изделия. Когда мне удалось подобрать такую комбинацию подтягивающих резисторов для каждого изделия, что чтение по шине производилось без ошибок в течение длительного времени, мы столкнулись с еще одной проблемой. Похожие симптомы «зависания» процессора наблюдались в моменты передачи голоса и данных по GSM/GPRS. Виной всему, по-видимому, были высокочастотные наводки на проводники шины. Так как локализовать причину мне не удалось, то, почитав сообщения на форуме Sierra Wireless/Wavecom на данную тему, а так же следуя рекомендациям специалистам Sierra Wireless, я все-таки решил перевести наше приложение Open AT на более новую операционную систему Open AT Firmware R7.3, OS v6.20, SDK2.20. Процесс включал в себя следующие шаги:

1. Установил новую оболочку Open AT IDE «Oasis 2.20», скачав ее с ftp-сервера КОМПЭЛ (доступ открывается по запросу; кстати - очень удобно, что много необходимой информации для разработчиков доступно в любое время);

2. Перепрошил процессор Wavecom под новую операционную систему, следуя описаниям на сайте производителя;

3. Собрал на основе старых исходников проект с помощью Project Wizard (Open AT может отказаться собирать проект, если пользователь Windows в своем имени использует кириллические символы);

4. Скомпилировал проект с опцией «Wismo Target» в новой среде «Oasis 2.20», и, естественно, получил в ответ много сообщений об ошибках и несобранный бинарный файл;

5. Далее открыл документацию и последовательно начал выяснять различия в описании функций.

Первое с чем я столкнулся - в новой операционной системе некоторые статические данные хранятся в реестре. Ранее для определения версии hardware использовалась функция «adl_ioGetProductType()», теперь же данные приходилось получать из реестра.

Второе - в новом OAT ADL кардинально поменялся интерфейс работы c портами GPIO, поэтому эту часть программы пришлось переделать:

Определение самих GPIO:

вместо «ADL_IO_Q2687_GPIO_21» определил порты как «ADL_IO_GPIO | 21»;

Структуры, описывающие GPIO:

структуры типа:

const adl_ioConfig_t Config_EN_WT [GPIO_COUNT_EN_WT] =

{

{EN_WT_Power_GPIO, 0, ADL_IO_OUTPUT, ADL_IO_LOW},//EN_3V3_WT - On/Off Bluetooth modulle WT-12

{EN_WT_Translator_GPIO, 0, ADL_IO_OUTPUT, ADL_IO_LOW},//EN_IO_WT - Enable for Signal Translator FXL4TD245

{RESET_WT_GPIO, 0, ADL_IO_OUTPUT, ADL_IO_LOW} //RST_WT - Reset WT-12

};

стали выглядеть так:

const adl_ioDefs_t* Config_EN_WT [GPIO_COUNT_EN_WT] =

{

EN_WT_Power_GPIO | ADL_IO_DIR_OUT | ADL_IO_LEV_LOW, //EN_3V3_WT - On/Off Bluetooth modulle WT-12

EN_WT_Translator_GPIO | ADL_IO_DIR_OUT | ADL_IO_LEV_LOW, //EN_IO_WT - Enable for Signal Translator FXL4TD245

RESET_WT_GPIO, 0 | ADL_IO_DIR_OUT | ADL_IO_LEV_LOW //RST_WT - Reset WT-12

};

На форуме я узнал, что GPIO44 в новой операционной системе называется GPIO 0, хотя в документации в явном виде я этого факта не нашел;Подписка на сервисы GPIO:

соответственно, изменился интерфейс функции «adl_ioSubscribe», было:

// Subscribe to the RUN_REQ event service

RUN_REQ_GpioEventHandle = adl_ioEventSubscribe (RUN_REQ_GpioEventHandler);

GpioHandle_RUN_REQ_Signal = adl_ioSubscribe ( GPIO_COUNT_RUN_REQ,

(adl_ioConfig_t *)Config_RUN_REQ,

ADL_TMR_TYPE_100MS,

CheckRUN_REQ_state_Time,

RUN_REQ_GpioEventHandle );

стало:

// Subscribe to the RUN_REQ event service

RUN_REQ_GpioEventHandle = adl_ioEventSubscribe ( RUN_REQ_GpioEventHandler );

GpioHandle_RUN_REQ_Signal = adl_ioSubscribe ( GPIO_COUNT_RUN_REQ,

Config_RUN_REQ,

ADL_TMR_TYPE_100MS,

CheckRUN_REQ_state_Time,

RUN_REQ_GpioEventHandle );

Так как информация о GPIO хранится в виде битовых полей, то в новой версии OAT ADL получение информации о GPIO производится с помощью масок, например: ((((adl_ioDefs_t *)Param)[RING_Button]) ADL_IO_LEV_MSK) ADL_IO_LEV_HIGH;Соответствующим образом изменился и интерфейс функций «adl_ioWriteSingle» и «adl_ioReadSingle».

Третье - изменения коснулись модуля работы с шиной I2C. Основное время ушло на то, чтобы понять, что теперь в адресе slave-устройства (adl_busI2CSettings_t) используется реальный адрес периферийного модуля (в нашем случае - GPS-приемника LEA-5H), в то время как в OAT OS v4.24 необходимо было указывать адрес со сдвигом влево на 1 бит. Запутанности также способствовало то, что при неверно указанном адресе slave-устройства функция «adl_busRead» («adl_busWrite») возвращает ошибку типа «ADL_RET_ERR_PARAM». Получив такую ошибку, невольно начинаешь искать проблему в структурах, описывающих шину, и в других параметрах, а об адресе устройства приходит мысль в последнюю очередь.

Изменились структуры, описывающие работу шины:

в OAT OSv4.24 использовалась структура вида:

/******************************/

/* I2C bus settings */

/******************************/

const adl_busI2CSettings_t I2C_bus_Config =

{

0x84, // ChipAddress, 0x42






Рекомендуемый контент




Copyright © 2010-2019 housea.ru. Контакты: info@housea.ru При использовании материалов веб-сайта Домашнее Радио, гиперссылка на источник обязательна.