Темп выдачи команд в SIM900, обмен затыкается Опции

[Hoodwin]

Наблюдается странное поведение, когда обмен между SIM900 и микроконтроллером встает. В процессе разбирательств сделали такой трюк, с помощью диодов и одного pull-uр резистора объединили RX и TX по И и вывели на RX-овый вход USB-UART мостика (CP2103). И тоге имеем в гипертерминале протокол обмена модуля и контроллера. Поскольку в основном обмен полудуплексный то все достаточно наглядно. Этим методом изучали, где затыкается.

Так вот, обнаружили что:
1) Затыкается не в определенном конкретно месте, а блуждает по разным командам.
2) С очень высокой вероятностью на сбойной команде видно мусор в терминале, что говорит об одновременной активности RX и TX. Но иногда мусора нет.
3) Остановка обмена выглядит так, мы туда что-то послали (например, AT+CPIN=0000), а в ответ тишина, ну то есть вообще ничего, ни OK, ни ERROR.

Из фактов пока все.

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

Но ведь раньше их тоже не то чтобы слали без разбору. Ждали OK или таймаут. А оно все равно умирает. Ну была гипотеза, что нельзя до прихода OK начинать слать следующую команду, и при неправильном таймауте оно может не дожидаться ОК, и слать следующую команду. Но тогда странно другое:
1) Ну и что такого, что команда идет до OK, она же в буфер идет? И будет обработана второй.
2) Мы видели зависание команд, которые в логе вполне чистые, то есть нет наложений на предыдущий ОК.
3) Допустим, что при приеме команды и до выдачи ОК модуль вообще RX выключает. Допустим, что он пропустит начало следующей команды и примет только конец, тогда он должен выдать ERROR. Но вот ERROR мы никогда не видели от него. Получается, что мы как-бы вообще всю команду послали в закрытый RX ему. Странно.

Да, эхо у нас выключено, и падать начинает сильно после его выключения.

[Hoodwin]

Master of Nature
По поводу кварца. Кварц у нас на 26MГц, начальная точность -- 10 ppm, температурная стабильность в диапазоне -20..+85 -- 10 ppm (эти точности нужны конечно не для UART, а для радиотрансивера МК).
Используется прямой делитель (без прескейлера) 225, что дает погрешность по передаче от -0.4% до +0.3% (общим размахом 0.7%), и примерно удвоенный разброс по приему (точные значения не помню). Но этого хватает с огромным запасом. Когда я писал про погрешность 0.7%, то имел ввиду именно неточность бодового генератора, связанную с дискретностью делителя. Но я несколько ошибся в оценке, вначале полагал, что там обычный генератор с прескейлером на 16 (как было в предыдущих семействах), из чего выходило, что делитель равен 14, и в итоге делитель равен 224, а это, грубо говоря, и дает ошибку в 0.7%. А оказывается, даже точнее. Я бы даже сказал, что при такой ошибке должно железно работать даже при однократной выборке бита, а многие нынешние реализации UART делают ввод бита по трем и более соседним выборкам, что еще повышает надежность. Из чего я делаю вывод, что сам по себе UART как сдвиговый регистр не является причиной затыков. Тем более, повторюсь, что прослушка довольно часто показывает совершенно чистый диалог МК и модуля, в конце которого модуль вдруг раз и не ответил.

По поводу полевиков тоже все просто. Один транзистор стоит на POWER_KEY, второй - на N_RESET. МК обоими умеет рулить, чтобы уж точно привести в чувства модуль.

Velund
Ну, то есть, Вы подтверждаете, что темп подачи команд влияет на адекватность ответов модуля? Осталось теперь разобраться, что значит лучше выдерживать какие то разумные паузы между командами? Существует описание, поясняющее величину пауз? желательно в измеряемых единицах: мкс, мс, с, а не абстрактно "разумных". Я собственно, про это и спрашиваю с самого начала.

CADiLO
Про сброс. Ну вот это тогда уже очередные грабли, только уже без надписи "не наступать". В Hardware Design Guide 2.00, в разделе 4.14, ничего подобного про EXT_RESET не написано. Имеется, правда, примечание, смысл которого сводится к тому, что сброс не гарантирует того, для чего он задуман: привести модуль в чувства и начать снова отвечать на AT-команды.

Power Key, я так понимаю, еще более программно реализованная кнопка?

К сожалению, рубать VBAT невозможно, так как из него потом делаются питания микроконтроллеров.

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

Ладно. Практика - критерий истины. Поглядим, как оно будет себя вести.

Сообщение отредактировал Hoodwin - Sep 6 2012, 09:13