Доброго дня, уважаемые. Подскажите, обязательно ли задействовать выводы 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-командами (мне он не нужен), но думаю всё должно быть аналогично.

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

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

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

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


А подробнее?

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


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

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

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

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

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

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


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

У модема на прием есть буфер около 1.5 кБайт, так что пакеты максимальной длины в 1460 байт должен принимать без проблем.
А на прием в МК просто нужен буфер побольше, тогда тоже проблем не будет.
Я у себя RTS поднимаю только когда хочу иногда полностью почистить приемный буфер.

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


На стороне МК проблем нет и быть не может - у меня на CM4 на 120МГц загрузка потоком МК->SIM808 скоростью в ~18-20КБ/сек составляет в среднем менее 1% времени МК.
И это без оптимизации (DEBUG).
А бОльшую скорость SIM808 уже не тянет. По-крайней мере - без FC не тянет.

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

Есть нюанс с автосохранением во флеш. В разных модемах 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.
Может ещё попробую перешить модуль новой прошивкой, но на это надежды почти нет.

Так может, hardware flow control (RTS/CTS) нужно еще и специально активировать? А по умолчанию он без него старается вывезти, да не получается.