SIM808 - кривее некуда!, нет слов.... :((((((((((( Опции

[jcxz]

Вожусь уже который день пытаясь заставить SIM808 хоть как-то передавать по Bluetooth через SPP.
Но блуждания по граблям уже просто достали! Просто не понимаю - где они (SIMCOM) берут настолько безмозглых быдлокодеров???!!
Хочу просто элементарно передать с устройства на комп по Bluetooth поток данных. Ну и принять небольшой поток в обратном направлении.
Вроде казалось: бы чего может быть проще? Это же базовая вещь - должно работать как часы. Ага - как же!
Первый сюрприз был в том, что оказывается режим автоматического приёма (AT+BTSPPGET=0 - дефолтный) работает как звёзды сложатся - данные могут прийти, а могут и потеряться (видимо если в этот момент идёт передача (командой AT+BTSPPSEND) - то не судьба; видимо быдлокодеров из SIMCOM никто не предупредил, что UART - это оказывается полно-дуплексный интерфейс).
Ну ладно - обойдёмся и без автоматического режима. Переписываю всё на мануальный режим. Ну и в нём конечно же уже ожидаемо не работает уведомление о пришедших данных (+BTSPPMAN) видимо всё по той же причине (может прийти, а может не прийти). Ну в этом режиме хоть данные не теряются, а мирно лежат в буфере в SIM808.
Переписываю драйвер на периодический поллинг (командой AT+BTSPPGET=3,...) приёмного буфера SIM808. Что поделать - приходится пользовать то го#%о, что имеется.
Ладно - приём через пень-колоду заработал.
Дальше дело пошло смешнее - передача.
Если просто передать одиночный блок данных AT+BTSPPSEND, то он доходит до терминалки на компе.
Но если попытаться передавать поток данных (за первой AT+BTSPPSEND сразу вторую AT+BTSPPSEND и третью и так далее) начинаются чудеса чудесатые!
Сначала неприятным сюрпризом явилось то, что если вот так слать данные блок за блоком (даже небольшими блоками по 10 байт - без разницы), то на очередной команде после выдачи приглашения к вводу данных "> " и отправки мной этих данных модулю, он тупо зависает. И зависает намертво - пока с ноги RESET ему пендаля не дашь. Зависает - в смысле просто молчит и ничего не отвечает хоть минуту хоть 10. И ни на какие данные более не реагирует (думал - может у меня где-то косяк и какие-то символы не досылаются - переключал провода на переходник USB-UART и вручную с терминалки пытался добить ему данных - без толку).
На прошивке, что была в модуле изначально (1418B02SIM808M32_BT_EAT) зависание случалось обычно уже буквально секунд через 2...5 после начала потока. Перешил на 1418B03SIM808M32_BT_EAT - стал виснуть уже позже - успевал проработать иногда даже полминуты, но один фиг! Что ещё интересно - ещё при этом на новой прошивке и скорость выросла - с максимум ~20КБ/сек до ~29КБ/сек (460800 бод).
Аппаратный flow control включен - без толку за всё время тестов CTS ни разу не шевельнулся (быдлокодеры SIMCOM в курсе, что у них в даташите написано про flow control?).
Да даже без FC в команде AT+BTSPPSEND уже есть свои возможности по управлению потоком (если вдруг вх.буфера не хватает): можно приглашение "> " выдать когда место в буфере освободится, можно "SEND OK" в конце отправки задержать также до момента освобождения буфера. Даже CTS то собственно и не нужен.
Так нет же - лучше просто тупо повиснуть!
Ладно - решил попробовать сразу после AT+BTSPPSEND слать какую-нить другую команду, запрос статуса например AT+BTSTATUS? - может она мозги прочистит модулю? (хотя надо их прочистить тем, кто писал прошивку для него). Так теперь иногда стал на эту команду (AT+BTSTATUS?) получать "SEND OK" Приехали!!!
Т.е. - отправил данные AT+BTSPPSEND, получил в конце "SEND OK", после этого сразу запросил статус AT+BTSTATUS? и опять в ответ - "SEND OK". А вот если сделать паузу между командами, то этого "SEND OK" уже нет. Ну это уже ни в какие ворота не лезет!!! Там похоже внутри не ПО, а какое-то недоразумение.
И это ещё не говоря о том, что иногда модуль ни с того ни с сего вдруг вообще может прислать какой-нить левый символ. Ну т.е. - установлено соединение, приёма/передачи нет, 10 минут нет, 15 нет - и тут вдруг БАЦ!! - из UART вылазит например 0xF1 или ещё какой мусор. Не в команде запроса данных, а просто из UART, когда никакая команда не выполняется.

Если после AT+BTSPPSEND ставить паузы в несколько мсек, то тогда он начинает более-менее устойчиво работать. Даже иногда несколько десятков МБ удавалось передать. Но всё равно в конце концов виснет. 40 минут непрерывной передачи - это был абсолютный рекорд, и ни разу потом его повторить не удалось.

PS: Вобщем - извините за такое повествование. Но просто накипело - уже который день кувыркаюсь с этим говноподелием SIM808. Уже никаких слов кроме нецензурных о нём не осталось.... ((((((((((((((

PSS: Условия мытарств: управление потоком включено AT+IFC=2,2 или выключено - без разницы; скорость по UART фиксирована - AT+IPR=460800 (пробовал и ниже - то же самое); функцинальность пробовал AT+CFUN=4 и AT+CFUN=1 и AT+CFUN=0 (в последнем работает наиболее устойчиво, GSM мне не нужно и симки не будет, только BT+GPS). Вначале тестил на 1418B02SIM808M32_BT_EAT, потом перешил на 1418B03SIM808M32_BT_EAT - стало лучше, но если без пауз после AT+BTSPPSEND работает пару минут - это уже счастье!

[Rash]

jcxz, и только не говорите, что Вас не предупреждали.
Ждите рассказов как Вы не правильно модуль используете.

То, что ПО модуля в эпоху ARMов корявое и тормознутое, я с Вами абсолютно согласен. То, что производители не хотят понять, что UART асинхронный, то ему ещё отводят лимитированное время на обработку из "мего крутой" операционной системы, к которой Симком не имеет ни какого отношения. Только это их разработчики выбирали этот чипсет, с такой операционкой. Про DMA режим и кольцевой буфер команд, думаю говорить им бесполезно. И напоследок, рекомендованная скорость это 9600 бит/сек.

Но если вы внимательно почитаете это форум, то найдёте кучу предупреждений, что это прежде всего GSM модуль. И даже, если Вы не используете GSM, в его ПО заложен приоритет на GSM, а не BT модуль. Также следующее предупреждение будет, что модуль это не пулемёт и не ждите от него быстрой реакции. Посылать команды сразу, даже спецификация не позволяет. Задержка между приёмом ответом на предыдущую команду и передачей следующей команды должна быть не менее 50мсек. Но если бы это работало так, это можно было бы назвать счастьем. А так послал команду, а она может прийти тебе когда угодно.

Повторю, из собственного опыта, что передача и приём по BT работают в автоматическом режиме на модуле SIM800С, период посылки 500 мсек, длина пакета порядка 60 байт. Работает часами, модуль от этого не виснет. Работает как с присутствием СИМ карты, так и без неё.

[jcxz]

Ждите рассказов как Вы не правильно модуль используете.

Я вообще-то использую его согласно документации. В каком именно месте я отступаю от документации - укажите?

То, что ПО модуля в эпоху ARMов корявое и тормознутое, я с Вами абсолютно согласен. То, что производители не хотят понять, что UART асинхронный, то ему ещё отводят лимитированное время на обработку из "мего крутой" операционной системы, к которой Симком не имеет ни какого отношения. Только это их разработчики выбирали этот чипсет, с такой операционкой. Про DMA режим и кольцевой буфер команд, думаю говорить им бесполезно. И напоследок, рекомендованная скорость это 9600 бит/сек.

Что значит "тормознутое"? Вот у меня работой с этим го#@о-модулем занимается одна из задач ОС на CPU с тактовой 120МГц. При старте драйвера общая загрузка CPU вырастает менее чем на 1%. Один процент - максимум, Карл! А для разбора этого протокола на той стороне нужно примерно столько же ресурсов.
Т.е. - если у них там стоит такой же CPU который всё время загружен на 99%, то да - наверное он не будет успевать. Но как нужно писать код чтобы загрузить их мощный ARM (мощнее моего ведь вроде) на 99% постоянно??? И что там такое нужно делать??
Какой бы ни был UART, хоть 115200, хоть 460800, с DMA или без - это всё доли процента загрузки такого CPU. Это всё ни о чём.

Но если вы внимательно почитаете это форум, то найдёте кучу предупреждений, что это прежде всего GSM модуль.

Если он так работает, то это прежде всего - хлам.

И даже, если Вы не используете GSM, в его ПО заложен приоритет на GSM, а не BT модуль.

Я писал, что использую режим +CFUN: 0, при этом как говорит даташит:
AT command ”AT+CFUN” can be used to set the module to a minimum functionality mode
without removing the power supply. In this mode, the RF part of the module will not work or
the SIM card will not be accessible, or both RF part and SIM card will be closed, and the
serial port is still accessible.
А каком GSM Вы тогда говорите? Всё выключено и GSM и SIM-карта. Чем он там может заниматься??? Этот мощный процессор?

Также следующее предупреждение будет, что модуль это не пулемёт и не ждите от него быстрой реакции. Посылать команды сразу, даже спецификация не позволяет. Задержка между приёмом ответом на предыдущую команду и передачей следующей команды должна быть не менее 50мсек.

Это где Вы такое вычитали? Приведите ссылку.
Я вообще не понимаю такую фразу, что значит "модуль это не пулемёт"? Это что так теперь можно оправдать любой говнокод???

Но если бы это работало так, это можно было бы назвать счастьем. А так послал команду, а она может прийти тебе когда угодно.

Вы похоже не поняли того, что я написал...
Дело не в том когда ко мне приходит ответ на команду. Естественно я жду прихода ответа на команду и ничего не передаю пока не получу этот ответ.
Дело же не в этом, а в том что если сразу после ответа на предыдущую команду послать сразу следующую (или через небольшой интервал времени), то после этого модуль может вообще перестать что-либо выдавать. А может вдруг прислать ответ на предыдущую команду! Никак логически не связанный с этой командой.
Это то почему такое может происходить?
Это говорит, что у них там в прошивке куча багов при работе с входными или выходными буферами UART: что-то не туда пишется, или баги взаимодействия обработчиков прерываний, которые принимают поток символов UART и задачи обработки или ещё где-то...

Повторю, из собственного опыта, что передача и приём по BT работают в автоматическом режиме на модуле SIM800С, период посылки 500 мсек, длина пакета порядка 60 байт. Работает часами, модуль от этого не виснет. Работает как с присутствием СИМ карты, так и без неё.

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

PS: Только что наступил на очередной баг SIM808. С приёмом данных из BT. На стороне компа порт открыт виндовым Гипертерминалом, просто жму и держу нажатой клавишу 'Z' в окне терминала. Мой драйвер периодически опрашивает SIM808 на предмет наличия входящих BT-данных. Какое-то время всё работает нормально (несколько секунд), потом вдруг получаю следующее:

CODE

14:46:40.01 SIMCOM.in: "+BTSPPMAN: 1"
14:46:40.01 SIMCOM.out: "AT+BTSPPGET=3,18"
14:46:40.03 SIMCOM.in: "+BTSPPGET: 1,1,Z"
14:46:40.03 SIMCOM.in: "OK"
14:46:40.04 SIMCOM.in: "+BTSPPMAN: 1"
14:46:40.06 SIMCOM.out: "AT+BTSPPGET=3,17"
14:46:40.06 SIMCOM.in: "+BTSPPGET: 1,1,Z"
14:46:40.06 SIMCOM.in: "OK"
14:46:40.07 SIMCOM.in: "+BTSPPMAN: 1"
14:46:40.07 SIMCOM.out: "AT+BTSPPGET=3,16"
14:46:40.09 SIMCOM.in: "+BTSPPGET: 1,1,Z"
14:46:40.09 SIMCOM.in: "OK"
14:46:40.14 SIMCOM.in: "+BTSPPMAN: 1"
14:46:40.14 SIMCOM.out: "AT+BTSPPGET=3,15"
14:46:40.15 SIMCOM.in: "+BTSPPGET: 1,1,Z"
14:46:40.15 SIMCOM.in: "+BTSPPMAN: 1"
14:46:40.15 SIMCOM.out: "AT+BTSPPGET=3,14"
14:46:40.15 SIMCOM.in: "+BTSPPMAN: 1"
14:46:40.15 SIMCOM.in: "+BTSPPGET: 1,0"
14:46:40.15 SIMCOM.in: "OK"
14:46:40.17 SIMCOM.out: "AT+BTSPPGET=3,14"
14:46:40.17 SIMCOM.in: ",Z"

Т.е. - в очередной раз получаю от модуля уведомление что есть входящие символы "+BTSPPMAN: 1", даю команду чтения этих символов "AT+BTSPPGET=3,14", получаю ответ что ничего нет "+BTSPPGET: 1,0", а через некоторое время после очередного опроса состояния входного BT-потока "AT+BTSPPGET=3,14" вдруг получаю что-то невразумительное: ",Z". Это что такое??? Похоже и приём в SIM808 нормально не работает. (((((((((((
Rash, а у Вас как приём работает? Или у Вас нет приёма?