david_off

Спасибо всем откликнувшимся. Действительно проблема в AT+IPR=0. После сохранения фиксированной скорости проблемы исчезли. PS: осталось разжится на новую прошивку, но мне кажется это большой дефицит...

прочитал. Но как я понял, проблема была по следующим причинам: 1) в отсутствии задержки около 3 сек после включения питания 2) в некоректном распозновании нужной частоты со стороны модуля. 3) в завышенном питании. У меня проблема не в этом. Конкретно по пунктам. 1) задержка есть 2) модуль распознаёт всё со второго, максимум с третьего раза. 3) питание 4,15-4,2 на LM2576 + 1000мФ. Так что вопрос остаётся открытым. В работающем устройстве, а точнее даже в двух - после непонятных условий слетает установленная автободингом частота. Ответы начинают приходить непонятными байтами разной длины. При посылке модему команды AT, тот практически с первого раза оживает. Суть вопроса - чего может слетать автободинг?

У меня появились очень неприятные симптомы при работе с SIM300C (прошивка 12, память SPANSION) Написана программа, которая настраивает модем, поднимает сессию GPRS. В ходе недели разберательств установлено, что периодически у модема слетают настройки автободинга. Т.е. после появления сплошных ошибок при общении с модемом, видно, что его ответы состоят из непонятного набора байт. После посылки команды AT несколько раз - модем в 90% случаев востанавливается. Вы не знаете что это такое и из-за чего может быть?!

Написана программа, которая настраивает модем, поднимает сессию GPRS. В ходе недели разберательств установлено, что периодически у модема слетают настройки автободинга. Т.е. после появления сплошных ошибок при общении с модемом, видно, что его ответы состоят из непонятного набора байт. После посылки команды AT несколько раз - модем в 90% случаев востанавливается.

Не знал что под мой зверёк тоже есть оси. Я думал оси пишут только для DSP и выше. Поищу. Может быть жить станет красивей. Кстати будет ещё интересно пару слов о ваших предпочтениях в этом вопросе. Наверняка будет много разных вариантов, львиную долю которых вы уже забраковали и лишите меня приятного права наткнулся на уже пройденные грабли. :) PS: cпасибо за просвящение.

Не знаю что у вас за железо, но я это реализую на mega128+SIM300C. Чего то для этой парочки не слышал про какую-то ось. Что касается алгоритма обработки, то мой алгоритм отлично работал, до появления сообщения REMOTE IP и данных GPRS. Ведь именно по этому я и создал эту тему. Тут мне подсказали сделать таймауты. После их добавления наши с вами алгоритмы стали практически близнецами. Сами судите. У меня тот же кольцевой буфер. Размер его выбран по такому же принципу. Байты ловятся в прерывании по приёму USART. Там же стоит логика, которая отслеживает появления LF по принципу StateMachine. Появилось LF дважды (пока таймер ещё не сработал) - значит в буфере уже лежит что-то осмысленное и можно это обработать. Для всех используемых мною команд можно это использовать. При появлении команд, которые в конце не имеют LF - обработку инициирует срабатывание таймера. После начала обработки, StateMachine возращается в начальное состояние, что бы начинать отлов новых ответов с "нового листа". Сам же принцип обработки тоже очень похож. Идём по буферу, сравниваем его содержимое с готовыми шаблонами ответа. Определённые ответы выставляют особые флаги. Например нашли OK - ставим OKfound = true. Если в буфере встречается ERROR или ему подобные, то ставиться ERRORfound=true. Если не нашли нужного шаблона - значит это просто ответ - для него есть флаг ANSWERfound. Когда есть три таких флага, то после посылки любой комады нужно дождаться либо экстернного вываливания (ERRORfound) либо нужного сочетания ANSWERfound и OKfound. После того как в буфере обработана инфа, он так же чистится, как и у вас. Перед посылкой новой команды, все флаги сбрасываются. Может это и покажется диким, но у меня как ни странно всё класно работает. Проверял, тестил сутки - сбоев не было. Отработаны команды поднятия GPRS сервиса, инициализации и приёма звонков, посылки и приёма TCP сообщений. Алгоритм обработки не падает при вклинивании UNSOLICITED сообщений типа RING или +CMTI. При появлении их появлении, они обрабатываеются, затем в буфере происходит откат указателей и программа продолжает корректное ожидание или обработку прерванной комады - все ок. Пробовал, но программа получается дико несмотрибельной. При достаточном количестве команд, появлеются дикие деревья вложенных IF, Количество внеших IF стремится к размеру алфавита, а внутренних при одинаковых первых символах, также прибаляет новые внутренние ветки. В итоге скорость не на много повышается, а писать не удобно. Единственное, что я сделал для ускорения, это считаю длину полученной посылки во время приёма. Процесс сравнивания сначала пытается найти похожий шаблона ответа в ответах фиксированной длины (OK, ERROR, CONNECT ...), если же после попадания в раздел нужной длины соответвий не найдено, то идем в раздел ответов неопределённой длины (+IPD, REMOTE IP: ...). Если и там ответ не найден, то получен не шаблонный ответ, который будет обработан по индивидуальному алгоритму для каждой нестандартной комады. Мне кажется более гуманно. Даём модему нормально высказаться, потом поднимаем RTS и спокойно обработать полученный ответ. А в вашем алгоритме получается не намного быстрее, но вы тем самым не даёте модему свободно выражаться. Ведь наверняка, если обработка ответа идёт во время получения, то возможно, что контроллер будет не готов к продолжению приёма к моменту получения нового байта.

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

Вы предлагаете после получения КАЖДОГО байта (когда уже был LF) пытаться распознать что у нас лежит в буфере приёма?! Мне кажется это будет нерационально расходовать процессорное время. Получается для распознования элементарного ответа IP INITIAL на команду CIPSTATUS прийдётся запустить процедуру распознования содержимого более 10 раз. И это не просто процедура инкремента, а попытка найти в буфере какую-то строку, соответсвующую определённому шаблону. Шаблоны как я понимаю должны быть приготовлены для всех вариантов ответа. Если же всё таки начинать распознавание ответа по признаку количества принятых байт, или ещё какому-то признаку, то это не меняет концептуально подход. Просто меняется признак, по которому начинается обработка. А смысл тот же. Ждём признак, а получив - идём на распознование.

Думал, думал и надумал... По суте у меня выбор между двумя вариантами: моим и вариант с таймаутами. У моего есть минус, что он не ловит сообщения, которые не заканчиваются на CRLF У второго - не ловятся и не обрабатываются сообщения, которые были получены сразу же за сообщением, которое запустило таймер. Т.е. когда начало второго ответа успело начать приходить раньше таймаута. Так вот что я думаю. Надо совместить плюсы двух вариантов, убраив их взаимные минусы. Буду ловить как раньше начало и конец сообщений, но если произвойдёт тайм-аут, то буду принудительно ставить флаг получения сообщения. Для тех кто делал тайм-ауты наверно будет понятней сказать так. Буду ждать тайм-аута, но по мере поступления данных, буду проверять а нет ли внутри потока уже готового для обработки сообщения.

неплохой вариант, только я хочу уточнить. Если получен LF, а заним ещё что-то лезит, то это уже снимает проверку таймаута? Если да, то тогда REMOTE IP, который не имеет вконце LF также не будет обработан как и в моём алгоритме. Если нет, то тогда вообще зачем ждать LF - алгоритм становиться такой же как описан выше.

В моей программе все сообщения обрабатываются по установке флага получения нового сообщения. Анализатор флага работает так: получив CRLF (начало) - начинает ожидать CRLF(конец). Как только получен конец - флаг устанавливается. Обработчик сообщений, получив флаг, смотрит в буфер и обрабатывает пришедшее сообщение. После обработки флаг сбрасывается. Алгоритм работает шикарно. Единственный его нюанс - нельзя работать с командами типа CLCC, которые возращают несколько строк и строки начиная со втрой не имеют CRLF (начало). Данные ответы имеют вид: CRLF<line1>CRLF<line2>CRLF...<lineN>CRLF OK CRLF. Проблема решается путём отказа от таких комманд - они мне не нужны. Так вот с сообщением <CRLF REMOTE IP:> тоже наблюдается лажа. Есть вариант выхода из сложившейся ситуации следующий: после соединения модулей посылать текст, который всегда будет заканчиватся на CRLF. Тогда сообщение будет иметь вид <CRLF REMOTE IP: текст CRLF> - такое корректно обработается. Но вот найти решение корректной обработки, когда приходит RING или ещё какое-то неожиданное сообщение - не могу. По сему спрашиваю здесь. Как обрабатывать REMOTE IP на тот случай, если влазит кто-то?

Думаю затея хорошая, но нереализуемая. 1) Мало кто будет писать такие библиотеки, в которых будет всё прокоменчено и понятно друг другу. 2) Мало кто будет закладывать всеобщую универсальность = пригодность использования одной библиотеки многими пользователями. 3) В данной ветке будет просто невозможно найти что либо полезное. Надо 100% хостинг + что бы кто-то один следил за порядком там. Что бы не было повторов, глюкнутых библиотек. 4) Ни кто не захочет писать хелпы, как в приведённом примере. В доказательство своих изречений могу поставить себя в пример. Пункт №1 я бы ещё к себе не применил, но вот 2, 3, 4 - это моё. Библиотека для AT-комманд у меня есть, но к её 1000 сточек кода нужно 5000 строчек объяснения как ей пользоваться.

А позвольте поинтересоваться, как вы пользуясь GPRS узнаёте IP адреса удалённых точек? Может я как-то нерациоанально сделал? Сначала сам думал о приобретении статических IP - оказалось что оператор не может это сделать. Потом думал пользоваться DynDNS и в главном модуле пользовать сервис DNS. Но так и не понял, как со вторичных мудулей посылать запросы на сервер DynDNS для обновления их IP. Если вы подскажите как разрулить с DynDNS, то буду признателен. Мне кажется это будет более красивое решение обновления IP, чем через CSD.

Прошивка 12 - самая новая из доставаемых. Теоритически есть 14, но это пока только теория. Спасибо, попробую. Может действительно дело упростится Отвечу вопросом на вопрос. А почему бы не побробывать сделать побыстрее? Опишу слегка конфигурацию системы и может тогда станет понятно зачем ускорять. Задача на один модуль собрать инфу о разных объектах. У меня в системе один из модулей (на котором замечено зависание) является "типа основным". Он пытается обзвонить все вторичные модули и узнать их IP адреса. Если вторичный заметил слет GPRS, то сам может позвонить на главный и инициировать обновление своего IP. Все вторичные настраивают себя как сервера. Когда на основной модуль приходят IP от от "вторичных модулей, то тот начинает у них сдаивать инфу о состояние их систем (через GPRS). Опрос одним всех, вместо сливания всеми на один сделано для того, что бы на главный модуль не валилась куча пакетов от кучи вторичных. TCP/IP глючный в модуле SIM300C c 12 прошивкой. 100% замечено, что данные TCP пакета могут вывалится из порта раньше, чем поступит сообщение REMOTE IP:xxx. Т.е не получается в сплошном потоке корректно обрабатывать пакеты. Про этот баг даже сами китайцы писали Когда же один опрашивает всех, то он может и подождать пару сек, пока там гарантированно вылезет REMOTE IP... Так вот, в системе есть тонкое место, когда в районе пропало питание, разрядились все УПС а потом дали элекричество, то потом практически все начнут одновременно ломится на главное устройство. И чем раньше закончится ломление = обновится список IP на главном, тем раньше продолжится нормальная работа.

а чем не подходит прошивки по приведённой ссылке? Лень искать? Лучше пусть кто-то лично для вас заливает в указанное вами место?! Для CADiLO: 1) Есть классное описание под прогу MiniG. Но вы говорили, что порт Debug не работает. Если ли же он всё таки работает, то где сама прога? В папке "AppNotes - Soft" лежит только сервер... 2) Не отрываются файл1 и файл2- скачать его можно, но при открытии выдаёт ошибку. 3) Находил пару абсолютно не нужных/непонятных документов с китайскими иероглифами, кроме того потом, судя по картинкам, нашёл их англоязычные аналоги. Наверно китайские можно удалить.