Перейти к содержанию
    

Необходимость RTS/CTS для надежной работы SIM800C

Доброго дня, уважаемые. Подскажите, обязательно ли задействовать выводы RTS/CTS для надежной работы связи SM800C/STM32.

TCP использую только в командном режиме (AT+CIPMODE=0).

 

Поток может прерываться (RTS=1) только в прозрачном режиме передачи данных?

Поток может прерываться только на отправке большого объема данных по TCP или и на обычных AT командах тоже?

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Доброго дня, уважаемые. Подскажите, обязательно ли задействовать выводы RTS/CTS для надежной работы связи SM800C/STM32.

TCP использую только в командном режиме (AT+CIPMODE=0).

Поток может прерываться (RTS=1) только в прозрачном режиме передачи данных?

Поток может прерываться только на отправке большого объема данных по TCP или и на обычных AT командах тоже?

Я только что написал драйвер BT-канала на SIM808 (в режиме APP - не прозрачный режим). Меня тоже очень интересует этот вопрос, так что сейчас будут писать тесты передачи потоков данных. Посмотрим что они покажут.

Если исходить из логики, то в APP-режиме (непрозрачном) для исходящего канала (МК->UART->SIM808->эфир) дополнительные сигналы управления потоком не нужны, так как SIM808 уже управляет потоком данных к нему (команд AT+BTSPPSEND) выдавая приглашение для ввода данных ("> ") и квитируя приём данных с UART ("SEND OK" и "SEND FAIL").

Мне думается, что управление потоком нужно только для прозрачного режима. Ну или оно может быть нужно, если необходимо управлять потоком входящего канала (эфир->SIM808->UART->МК). Например - если пользовательский МК может спать и долго пробуждаться.

Но сюрпризы возможны.

PS: Я не смотрел что там с TCP-командами (мне он не нужен), но думаю всё должно быть аналогично.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Доброго дня, уважаемые. Подскажите, обязательно ли задействовать выводы RTS/CTS для надежной работы связи SM800C/STM32.

TCP использую только в командном режиме (AT+CIPMODE=0).

 

Поток может прерываться (RTS=1) только в прозрачном режиме передачи данных?

Поток может прерываться только на отправке большого объема данных по TCP или и на обычных AT командах тоже?

Осталось уточнить с какой скоростью и в каком объеме Вы будете в модуль АТ команды отправлять и будете ли ждать подтверждения от модуля обработки команд ( чего часто многие не делают ) .

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

и будете ли ждать подтверждения от модуля обработки команд ( чего часто многие не делают ) .

А разве можно не ждать??? :wacko:

 

PS: Из моих, пока предварительных, данных испытаний, похоже следует, что без FC не обойтись :((((

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Осталось уточнить с какой скоростью и в каком объеме Вы будете в модуль АТ команды отправлять и будете ли ждать подтверждения от модуля обработки команд ( чего часто многие не делают ) .

38400, конечно жду подтверждения. В самом тяжелом случае - бесконечный опрос AT-командами, отправил одну команду, дождался ответа, отправил следующую и т.д.

 

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

А подробнее?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В самом тяжелом случае - бесконечный опрос AT-командами, отправил одну команду, дождался ответа, отправил следующую и т.д.

А почему - "тяжёлом"? Собственно там только такой интерфейс и есть, другого нет. Если не считать неудобного прозрачного режима.

 

А подробнее?

Пока сделал без FC. Работает почти стабильно в режиме потока при наличии небольших пауз (на неск. мс) после каждой команды AT+BTSPPSEND. Без пауз - не работает.

Такое поведение возможно намекает, что SIM808 почему-то не успевает разгребать входной поток данных, пытается ставить запрет (RTS), но не может, так как я ему запретил (AT+IFC=0,0) и теряет символы. Хотя очень странно это...

Скоро сделаю FC, тогда буду точно знать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Пока сделал без FC. Работает почти стабильно в режиме потока при наличии небольших пауз (на неск. мс) после каждой команды AT+BTSPPSEND. Без пауз - не работает.

Такое поведение возможно намекает, что SIM808 почему-то не успевает разгребать входной поток данных, пытается ставить запрет (RTS), но не может, так как я ему запретил (AT+IFC=0,0) и теряет символы. Хотя очень странно это...

Так можно включить FC и глянуть, дергается ли RTS.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Так можно включить FC и глянуть, дергается ли RTS.

Можно. Осцилл лень доставать с полки. ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Можно. Осцилл лень доставать с полки. ;)

Включил AT+IFC=2,2. RTS на GND, наблюдаю за СTS осцилографом - тишина, все время 0.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Работает почти стабильно в режиме потока при наличии небольших пауз (на неск. мс) после каждой команды AT+BTSPPSEND. Без пауз - не работает.

Автодетект скорости, надеюсь, отключили ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Доброго дня, уважаемые. Подскажите, обязательно ли задействовать выводы RTS/CTS для надежной работы связи SM800C/STM32.

TCP использую только в командном режиме (AT+CIPMODE=0).

Использовать желательно, но как показывает практика, в командном режиме необязательно.

Многие на форуме говорили, что при коротких пакетах работают без контроля потока.

 

Поток может прерываться (RTS=1) только в прозрачном режиме передачи данных?

Поток может прерываться только на отправке большого объема данных по TCP или и на обычных AT командах тоже?

В прозрачном режиме RTS/CTS точно нужно, т.к. тут все непредсказуемые задержки сети скрыты.

 

У модема на прием есть буфер около 1.5 кБайт, так что пакеты максимальной длины в 1460 байт должен принимать без проблем.

А на прием в МК просто нужен буфер побольше, тогда тоже проблем не будет.

Я у себя RTS поднимаю только когда хочу иногда полностью почистить приемный буфер.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Автодетект скорости, надеюсь, отключили ?

Не знаю. А что значит "отключил"?

После старта, в ходе начальной инициализации, среди прочих команд я даю ему AT+IPR=... И так при каждом старте ПО (не сохраняю AT&W).

 

А на прием в МК просто нужен буфер побольше, тогда тоже проблем не будет.

На стороне МК проблем нет и быть не может - у меня на CM4 на 120МГц загрузка потоком МК->SIM808 скоростью в ~18-20КБ/сек составляет в среднем менее 1% времени МК.

И это без оптимизации (DEBUG).

А бОльшую скорость SIM808 уже не тянет. По-крайней мере - без FC не тянет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

AT+IPR - я это и имел в виду, тогда правильно. У меня была сходная проблема - пока не начал устанавливать принудительно, команды (вообще любые) нельзя было давать без пауз, даже эхоконтроль искажение (SIM900).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

После старта, в ходе начальной инициализации, среди прочих команд я даю ему AT+IPR=... И так при каждом старте ПО (не сохраняю AT&W).

Есть нюанс с автосохранением во флеш. В разных модемах Simcom все по разному. Какие то команды имеют автосохранение, какие то нет. В новых модемах вообще нет сохранения во флеш (почти нет :))

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

 

На стороне МК проблем нет и быть не может - ...

Если вы просто кидаете данные дальше - то проблем быть не может.

А если после принятия порции данных нужно время на обработку - то без RTS не обойтись.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вобщем - написал драйвер BT-канала (на SIM808). Тестирую. Впечатления пока самые грустные.

Модуль вобщем работает, работает нормально.... а потом в какой-то момент виснет обмен по UART. :(((((

Использую только BT (+CFUN: 4, симка не вставлена и GPS выключен).

AT+BTSPPCFG=MC,0

AT+BTSPPCFG=TT,0

модуль в режиме сервера (принимает входящее подключение).

Скорость по UART - фиксированная 460800 бод.

Режим APP.

Использую только SPP профиль. Режим AT+BTSPPGET - Manual (вначале написал обмен используя Auto mode, но обнаружил, что модуль теряет входящие данные, если в данный момент идёт передача по AT+BTSPPSEND; а мне нужен полный дуплекс). Но ладно - фиг с ним - переписал на использование +BTSPPMAN и AT+BTSPPGET.

Как всё происходит:

Процессы коннекта/дисконнекта - всё ок (только одно соединение), спаривание - тоже ок.

Приём данных от удалённого устройства - тоже всё ок (но в эту сторону мне нужно мало данных передавать).

А вот с передачей (AT+BTSPPSEND) - затык. Передаю данные из кольцевого буфера (его заполняет отдельная задача ОС псевдослучайными данными).

Передаю так:

1. шлю "AT+BTSPPSEND".

2. жду предложения "> " или ERROR. Если получил первое - к след.шагу, ERROR - прерывание процесса.

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

4. жду "SEND OK" или "SEND FAIL" или "ERROR".

5. Если есть ещё данные в кольцевом буфере - перехожу к шагу 1.

Между 4 и 5 шагами периодически вставляются другие команды: запрос наличия входящих данных (AT+BTSPPGET), периодический опрос статуса (AT+BTSTATUS).

Вобщем всё работает нормально пока в очередной команде AT+BTSPPSEND на шаге 4 модуль перестаёт отвечать. От слова "совсем". Ожидание длится бесконечно долго - от модуля ничего.

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

Данная ситуация наблюдается что с выключенным FC (AT+IFC=0,0) что с включенным hardware FC (AT+IFC=2,2). Причём я вообще никогда не наблюдаю чтобы модуль ставил CTS=1 в процессе работы (лог.анализатор всё время видит "0"). Только когда подаёшь RESET модуль ставит CTS=1.

Данный затык может произойти уже на 2...3 команде AT+BTSPPSEND от начала потока данных, а может и 20 команд передать, а потом повиснуть.

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

Пробовал понизить скорость UART до 230400 бод - опять то же самое, но чуть больше команд AT+BTSPPSEND успевают передаться.

Даже сохранил +IPR и +IFC во флешь (AT&W) на всякий случай.

Единственное что помогает - вставить задержку не менее 4 мсек между 4-м и 5-м шагом. В этом случае передача идёт нормально, но всё равно в какой-то момент происходит то же самое зависание. Но успевает передаться иногда до 10 МБ данных (один раз удалось даже 24МБ передать). Но тем не менее всё равно происходит зависон.

Дальнейшее увеличение задержки до 8 мсек никак не влияет на ситуацию.

Опять-же - всё это время сигнал CTS никак не шевелится!

И зависания всегда происходят в одном и том же месте - на шаге 4.

 

PS: Вобщем пока не знаю что делать.... :((((((

Ещё буду дальше искать баги в своём ПО (надеюсь что всё-таки где-то у меня баг). Но ощущение скверное - такое чувство, что где-то в SIM808 серьёзный баг в работе с UART.

Может ещё попробую перешить модуль новой прошивкой, но на это надежды почти нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...