[gegel 0]

10 mA - это с работающей задачей ОЦПУ? Или просто все отключено, а ток идет?

 

sleep ни в коей степени не укладывает сам модуль (GSM-часть) в спячку, для этого есть другие методы. А вот укладывает ли он в спячку задачу оцпу или просто делает задержку - надо пробовать по току потребления, я не могу сказать, т.к. пока не ставил задачей энергосбережение на своих разработках.

[pau62 0]

Вот сейчас впервые подал питание через тестер (не включая кнопкой POWERKEY)- кажет 10миллиампер (как бы не мало), но в талмуде на модуль вроде бы указан 1 миллиампер. Или его нужно как то усыплять, чтоб получить 1мА.

Не включая? Странно очень. 1.5 ма жрет м75 в режиме спячки с сохранением регистрации в сети. Ну в моменты передачи конечно есть кратковременное повышение тока. (это не в опенцпу)

может это потребление демо-платы с ее стабилизаторами и драйверами портов?

Изменено 3 ноября, 2011 пользователем pau62

[V125 0]

Пардон накололся, еще MAX 3232 запитана, но у неё по ДШ 300 микроампер. Резать дорогу питания пока не буду.

Изменено 3 ноября, 2011 пользователем V125

[pau62 0]

Вот м10 и м12 не мерил, а м75 при работе вместе с внешним контроллером жрал у меня между сеансами передачи что-то около 13ма. Причем половину контроллер жрал.

Проверю еще раз конечно.

[V125 0]

Каким обзазом порт DEBUG перестроить на 9600 (под ОЦПУ)?

[pau62 0]

Ql_SetUartBaudRate(ql_uart_port2,9600); - не помогает?

[V125 0]

Я хочу прицепить GPS модуль на дебаг порт (на основном все нормально работает), и пытался изменить скорость именно так этой ф-цией. Но чего то не врублюсь. Данные с GPS модуля начинают поступать только после пересброса питания GPS модуля. Вот и уточнил. Может надо подтяжку RX к питанию соорудить??? Вот не принимает их Дебаг порт пока не передерну питание GPS.

[pau62 0]

Осцилом посмотреть бы.

А 3-й порт? Я в дебаг порт пока ничего не втыкал

[V125 0]

Я пока не понял, что это за третий уарт, да и насчет ql_uart_port2 это Дебаг или не дебаг не уверен. Надо спросить у GeGeL. он разобрался с ними. Просто очень удобно GPS прицепить на дебаг, а с основного апгрейдиться.

[pau62 0]

если модуль боле-мене свежий, то 62pin -TXD3 63 - RXD3. Я им пользуюсь.

Работать с ним так же как и с 2-ым, только 3 вместо 2 писать.

В описании на М12, что у меня есть, порт 3 не упоминается, можно ДШ про М10 посмотреть. Если модуль старый, перепрошить можно попробовать.

 

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

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

Может, и не стоит его под другие задачм использовать, мало-ли подебажить .

 

Можно и у первого объединить функции, просто глушить как-то передaчу с GPS по power key

Изменено 5 ноября, 2011 пользователем pau62

[V125 0]

Вот спасибо, подсказали про третий Уарт, я не доумился М10 доку посмотреть. А второй модемный порт это что такое? Я понимаю модемные порты просто мультиплексируются.

[pau62 0]

Не понимаю зачем он. Возможно при передачи данных в нем есть смысл.

 

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

[V125 0]

Тогда про баги, незнаю модуля или моих мозгов. Если я подключаю GPS модуль к основному порту -данные поперли , парсятся. Не выключая модуль перебрасываю GPSмодуль на Дебаг порт, тоже идут. Если же изначально подключить GPS на Дебаг-борода. Приходится "заводить" на основном и перебрасываться на Дебажный. Возможно существует какой то мне неизвестный приоритет обработки портов случаем EVENT_UARTDATA: Может надо как то принудительно включать Дебаг порт?

Изменено 6 ноября, 2011 пользователем V125

[gegel 0]

Это не баг.

 

Китайцы в своем трекере используют порт 3. Я использую порт 2 (out использую для дебаг в BASIC_MODE, in - для ввода GPS-данных). BASIC_MODE дебаг - это собствеенно обычный режим порта, никакого самопроизвольного дебага там нету, данные отправляются только при использовании функции Ql_DebugTrace. Ну, и Ql_SendToUart для него тоже работает, и евент по приему данных.

Выбор uart2 сделал из-за того, что в отличие от 1 и 3, в нем используется другой драйвер, и есть возможность задать Threshold по времени (в примере ниже - если аж 100 мс данных нет, то возникает евент). Это предупреждает деление входящих пакетов на части при "тормозах" в источнике. В GPS такого не наблюдал, а в сатресиверах - полно. И если нету хардверного трешхолда, то приходится писать процедуру объединения кусков с последовательных евентов, а это гимор.

Т.о., задав трешхолд, я в итоге при евенте от uart2 получаю ВСЮ ПАЧКУ NMEA (благо буфера 2048 хватает), и затем ищу, что надо (обычно GPRMC).

А то, что Вы описали, происходит из-за ошибок приема при старте по питанию источника (GPS-модуля). Их ОБЯЗАТЕЛЬНО надо очищать в евенте UARTFE!

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

 

//на старте:

 

Ql_SetDebugMode(BASIC_MODE);

Ql_SetPortRts(ql_uart_port2, FALSE);

ret=Ql_SetUartBaudRate(ql_uart_port2,9600);

Ql_UartSetGenericThreshold(ql_uart_port2, TRUE, 512, 100);

Ql_UartGenericClearFEFlag(ql_uart_port2);

Ql_UartClrRxBuffer(ql_uart_port2);

Ql_SetPortRts(ql_uart_port2, TRUE);

 

 

//в обработчике евентов

 

case EVENT_UARTFE:

{

Ql_UartGenericClearFEFlag(ql_uart_port2);

}

break;

Изменено 6 ноября, 2011 пользователем GeGeL

[V125 0]

Спасибо, вроде понял. Хотя у меня GPS источник подключен постоянно, тоесть данные уже установились и прут. Вот поди попробуй сам все нюансы раскопать. ДШ всеже скудноват на пояснения.

Jawohl ! Alles in ordnung! Das ist phantastisch.

Изменено 6 ноября, 2011 пользователем V125