[jcxz 184]

34 минуты назад, adnega сказал:

Практика показывает что нужны.

Тестировал на +GMR:A011B05A7672M7_F

Серьёзно?

Гладиолус!

[adnega 10]

В 10.10.2023 в 02:43, jcxz сказал:

Серьёзно?

Гладиолус!

A7672E, P/N:S2-109ZS-Z31DH, 921600 бод.

 

[jcxz 184]

1 минуту назад, adnega сказал:

A7672E, P/N:S2-109ZS-Z31DH, 921600 бод.

Ну вот, хоть что-то....

Т.е. - хотите сказать, что параметры современных A7672E стали даже хуже, чем у SIM868E (которым вроде они рекомендуются на замену)?

На SIM868E делал проект, в котором была интенсивная передача файлов (не какие-то отдельные команды, а объёмные файлы). Да - изначально заложили в схему CTS/RTS. Но при разработке прошивки выяснилось, что прекрасно работает и без flow control. Правда я работал на 460800 бод. Не помню - пробовал ли выше, возможно не пробовал. Но я тестировал передачами файлов большого объёма и ничего не терялось.

[adnega 10]

В 10.10.2023 в 03:34, jcxz сказал:

Ну вот, хоть что-то....

Т.е. - хотите сказать, что параметры современных A7672E стали даже хуже, чем у SIM868E (которым вроде они рекомендуются на замену)?

На SIM868E делал проект, в котором была интенсивная передача файлов (не какие-то отдельные команды, а объёмные файлы). Да - изначально заложили в схему CTS/RTS. Но при разработке прошивки выяснилось, что прекрасно работает и без flow control. Правда я работал на 460800 бод. Не помню - пробовал ли выше, возможно не пробовал. Но я тестировал передачами файлов большого объёма и ничего не терялось.

Я несколько дней гонял A7672E. У одного Оператора связи - все прекрасно. У другого - такой лес на FC. Есть огромное желание подключить модуль по USB, т.к. требуется максимальная скорость.

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

 

Кста, я на ESP8266 в AT-прошивке тоже получал потери байтов (при передаче в ESP8266) без использования FC.

Там есть прозрачный режим, который сносно работает, если трафик умеренный.

При работе на скорости 80МГц/24=3.3Мбод на непрерывном потоке получал порядка 8% потерь:

Цитата

rx_count = 97278080, tx_count = 106877488,
tx_time = 320s,
tx_speed = 326kB/s, rx_speed = 296kB/s,
delta = 9599408B, delta% = 8

При интенсивности 2048 байт каждые 10 мс потери меньше 1%, но есть:

Цитата

rx_count = 64677888, tx_count = 65239040,
tx_time = 318s,
tx_speed = 200kB/s, rx_speed = 198kB/s,
delta = 561152B, delta% = 0

(указаны число принятых байт, переданных байт, общее время работы, средняя скорость, число потерянных байт и процент потерь)

При работе с FC - потерь нет вообще.

[Arlleex 131]

Может, скорости самого UART чуть-чуть, но различаются? Из-за этого и потери.

[adnega 10]

В 10.10.2023 в 08:31, Arlleex сказал:

Может, скорости самого UART чуть-чуть, но различаются? Из-за этого и потери.

Нет. Явно видно, что модуль "задумывается". Да, и с FC проблема принципиально исчезает - если бы проблема была в различии скоростей, то она бы осталась.

[jcxz 184]

6 часов назад, adnega сказал:

Я несколько дней гонял A7672E. У одного Оператора связи - все прекрасно. У другого - такой лес на FC. Есть огромное желание подключить модуль по USB, т.к. требуется максимальная скорость.

Вот это странно.... Странно, что у вас FC активируется не при передаче данных от модуля к вашему МК, а при передаче команды к модулю. Там же серьёзный процессор стоит. И как такое может быть, на незагруженном даже (каким-то мощным потоком) процессоре??? Такого даже на самом простом Cortex-M не должно быть.

Я бы понял, если бы RTS поднимал ваш МК, чтобы остановить поток от SIMCOM (потому как занят чем-то). Но мощный CPU SIMCOM, да ещё в простое....  

Складывается ощущение, что вы что-то нарушаете в условиях подключения или использования SIMCOM (питание, уровни сигналов, etc.).  

6 часов назад, adnega сказал:

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

Как он может это делать?

6 часов назад, adnega сказал:

Кста, я на ESP8266 в AT-прошивке тоже получал потери байтов (при передаче в ESP8266) без использования FC.

Какая версия прошивки? В старых версиях были баги, очень криво работали.

Но с последними AT-прошивками всё ок. У меня есть давно работающий проект на ESP8266+STM32F429. В котором работа с ESP (с AT-командной прошивкой) идёт на 1843200 бод. Подключен он 2-мя проводами (без FC). Никаких потерь не наблюдается. Поток (максимальный) состоит из:

1 сокет на приём (ESP->STM) на постоянной скорости <=320 кбит/с (но иногда выше - вплоть до полной загрузки канала);

2 сокет на передачу (отладочный вывод в виртуальный COM-порт);

3 сокет на всякие периодические кратковременные запросы (SNTP, служба погоды, etc.)

Никаких потерь не наблюдается. Работает часами. Играет интернет-радио через него. Оно почти постоянно включено и я бы заметил если бы были потери - сразу было бы нарушения в звуке. Уже несколько лет работает.

Я не помню - пробовал ли скорость выше 1843200 бод. Просто в этом проекте уже этой скорости хватает с большим запасом. И нет никакой нужды поднимать выше.

На бОльших входящих потоках тоже не могу проверить, так как не нашёл MP3- или AAC- станций, вещающих на скоростях выше 320 кб/с.  

6 часов назад, adnega сказал:

При работе на скорости 80МГц/24=3.3Мбод на непрерывном потоке получал порядка 8% потерь:

80 МГц - это частота вашего МК? Мой STM работает на 96МГц. Но иногда довольно хорошо нагружен: когда декодирует AAC+ идущий с HTTPS-сервера (в STM32F429 нет аппаратной криптографии, всё приходится делать программно). И при этом ещё на экранчике 320x240 рисует динамику. Но впрочем - там загрузка CPU не особо страшна драйверу ESP: UART работает и на TX и на RX через циклический DMA с большими буферами (есть SDRAM).

39 минут назад, adnega сказал:

Нет. Явно видно, что модуль "задумывается". Да, и с FC проблема принципиально исчезает - если бы проблема была в различии скоростей, то она бы осталась.

Это очень странно. В момент передачи команды к SIMCOM, он вроде как даже ничем не занят. А там очень мощный процессор стоит. Скорость 921600 бод - даже для слабого Cortex-M (ничем не занятого) - это ни о чём.

Имхо: Или нарушения условий использования модуля с Вашей стороны; или баги в прошивке SIMCOM.

[adnega 10]

В 10.10.2023 в 10:51, jcxz сказал:

Там же серьёзный процессор стоит. И как такое может быть, на незагруженном даже (каким-то мощным потоком) процессоре???

Процессор любой мощности можно напрячь по-полной.

Я точно не знаю - лишь впечатления. Были плохие условия связи, видимо, проц был полностью вовлечен в дела радиочасти, а AT-задачи стали менее приоритетными.

Видно, что uart потреблял данные блоками по 16 байт, а затем тормозил прием - видимо насыщался какой-то FIFO буфер.

В 10.10.2023 в 10:51, jcxz сказал:

Складывается ощущение, что вы что-то нарушаете в условиях подключения или использования SIMCOM (питание, уровни сигналов, etc.).  

Пользуюсь оригинальной отладочной платой - там должно все быть ок.

Если есть желание, могу скинуть дамп логического анализатора всего обмена - там тоже все ок))

Кста, приделал антенну получше и заменил оператора связи - все взлетело.

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

В 10.10.2023 в 10:51, jcxz сказал:

Какая версия прошивки? В старых версиях были баги, очень криво работали.

AT version:1.6.0.0(Feb 3 2018 12:00:06)
SDK version:2.2.1(f42c330)
compile time:Feb 12 2018 16:31:26
Bin version(Wroom 02):1.6.1

Может, и старая - дело было в марте 2018 - на тот момент прошивка свежайшая.

В 10.10.2023 в 10:51, jcxz сказал:

У меня есть давно работающий проект на ESP8266+STM32F429.

У меня ESP использовалась в режиме сквозного канала - по сути UART-TCP.

AT+CWJAP_DEF="ssid","password"// настройка сети
AT+SAVETRANSLINK=1,"192.168.0.200",12345,"TCP"// настройка сервера

В 10.10.2023 в 10:51, jcxz сказал:

На бОльших входящих потоках тоже не могу проверить

Мне от ESP в том эксперименте была важна не пропускная способность, а как можно большее число пакетов в секунду, т.к. целевой протокол был "запрос-ответ".

Тестирование скорости - это побочная часть эксперимента.

По итогу поправили протокол, ввели в него команды более высокого уровня, чтоб "запрос-ответов" снизить, и чтоб рутинную часть обмена убрать.

В 10.10.2023 в 10:51, jcxz сказал:

80 МГц - это частота вашего МК?

Да у STM, чтоб скорости совпадали. У меня МК в эксперименте прохлаждался - молотили UART+DMA, он только статистику вел без какой-либо полезной работы.

В 10.10.2023 в 10:51, jcxz сказал:

Это очень странно. В момент передачи команды к SIMCOM, он вроде как даже ничем не занят. А там очень мощный процессор стоит.

Ага, там стоит мощный проц только для обработки АТ-команд ))

В 10.10.2023 в 10:51, jcxz сказал:

Имхо: Или нарушения условий использования модуля с Вашей стороны;

По железу - исключено, по софту - могу дамп анализатора скинуть со всем обменом))

В 10.10.2023 в 10:51, jcxz сказал:

или баги в прошивке SIMCOM.

Удобно называть все, что требует FC - забагованным))

[jcxz 184]

43 минуты назад, adnega сказал:

Процессор любой мощности можно напрячь по-полной.

Можно, да.... криворукий программист может что угодно завалить. 

43 минуты назад, adnega сказал:

Я точно не знаю - лишь впечатления. Были плохие условия связи, видимо, проц был полностью вовлечен в дела радиочасти, а AT-задачи стали менее приоритетными.

У SIMCOM-овских модулей вроде как для радиочасти отдельный CPU/DSP.

Здесь есть специалист по ним - CADiLO. Он поправит если что.

43 минуты назад, adnega сказал:

AT version:1.6.0.0(Feb 3 2018 12:00:06)
SDK version:2.2.1(f42c330)
compile time:Feb 12 2018 16:31:26
Bin version(Wroom 02):1.6.1

Позже гляну какая у меня прошивка.

43 минуты назад, adnega сказал:

Мне от ESP в том эксперименте была важна не пропускная способность, а как можно большее число пакетов в секунду, т.к. целевой протокол был "запрос-ответ".

Тогда для SIMCOM это ещё более лёгкий режим должен быть.

43 минуты назад, adnega сказал:

Ага, там стоит мощный проц только для обработки АТ-команд ))

Именно так. Если у вас не запущено никаких TLS-сессий, то так и есть.

Иначе - как Вы думаете он сможет тяжёлую TLS да ещё на потоке обслуживать, если у него не хватает сил даже просто принять несколько байт команды???

Ди и какая "обработка"? У вас же тормоза до обратботки команды. На стадии только её приёма. Принять пару десятков байт по UART - это что - непосильная задача по вашему?

Эта "задача" по силам даже STM8. Без всяких FC. Если бы у него конечно тактовой хватило, запустить UART с таким baudrate. И написатель кода имеет голову на плечах не только чтобы в неё есть.

43 минуты назад, adnega сказал:

Удобно называть все, что требует FC - забагованным))

А как ещё называть? если имеем ESP8266, гораздо более слабый МК; работающий на в 2 раза большей скорости; загруженный обработкой потока (даже нескольких параллельных потоков - несколько открытых TCP-сокетов) и прекрасно справляется с этим, не требуя FC. Как в таком случае называть ещё?

 

PS: Ну если конечно может в этом A7672 SIMCOM-овцы сэкономили на отдельном DSP для радио, и всё взвалили на один CPU. Тогда может он реально занят чем-то связанным с эфиром.

Но здесь только CADiLO нам сможет ответить. Ну или может кто-то снимал крышечку с модуля и смотрел - что там внутри?

Да, кстати - у ESP8266 нет отдельного ядра для радио. Там одно единственное ядро справляется со всем. И с радио и с TCP-стеком и даже - с обработкой AT-команд!  И не тупит. Тем более - на элементарном приёме команды в приёмный буфер UART.

[CADiLO 9]

Все как и раньше - чипсет имеет несколько ядер.

Радиочасть на Baseband DSP, периферия на ARM.

Application Processor
- ARM Cortex-R5 up to 614MHz clock
 32K I-Cache
 32K D-Cache
 64KB ATCM and 64KB BTCM
- 64KB ROM and 64KB on-chip SRAM for application usage

 

[adnega 10]

В 10.10.2023 в 13:39, jcxz сказал:

Можно, да.... криворукий программист может что угодно завалить. 

Нельзя все валить на программиста. Есть еще такое понятие как "архитектура ПО". Любое спроектированное ПО будет иметь свои ограничения.

В 10.10.2023 в 13:39, jcxz сказал:

Тогда для SIMCOM это ещё более лёгкий режим должен быть.

В моих примерах SIMCOM и ESP - это две абсолютно несвязанные вещи. Общее у них - есть примеры ситуаций, где FC пригождается. 

В 10.10.2023 в 13:39, jcxz сказал:

если у него не хватает сил даже просто принять несколько байт команды???

Просто, он может обрабатывать другие более приоритетные задачи. Обратите внимание на "фаршированность" модуля - там много чему нужно работать помимо AT.

В 10.10.2023 в 13:39, jcxz сказал:

Принять пару десятков байт по UART - это что - непосильная задача по вашему?

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

А в это время проц пытается правдами и неправдами вытащить полезную инфу из сетевого трафика.

В 10.10.2023 в 13:39, jcxz сказал:

И написатель кода имеет голову на плечах не только чтобы в неё есть.

)) Если вы имеете дело только с миганием светодиодом, то вам неизвестна вся боль, возникающая при организации связи с интеллектуальной второй стороной.

Под "миганием", я понимаю, ваш полный контроль за выполнением команд. Как только появляется нечто, что может не ответить, или может задуматься, то появляются совершенно новые

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

В 10.10.2023 в 13:39, jcxz сказал:

 Ну если конечно может в этом A7672 SIMCOM-овцы сэкономили на отдельном DSP для радио, и всё взвалили на один CPU. Тогда может он реально занят чем-то связанным с эфиром.

)) я вас понял - 51-е ядро туда - для обработки АТ хватит с горкой. А SIMCOMовцы туда аж Cortex-R5 засунули, причем, R - это жжж не спроста.

Я так понял, вы конкретно с A7672E не работали. Их, кста, как минимум две версии есть, и вторая вообще не про АТ-команды))

[CADiLO 9]

>>> В очереди стоят две SIM-карты, SDIO-карточка, дисплей, клавиатура и т.п. - и каждый так же про себя думает.

>>> А в это время проц пытается правдами и неправдами вытащить полезную инфу из сетевого трафика.

 

SIM800C на ЕАТ эту периферию сожрет и не заметит, включая софтовый SPI для ENC28J60 еще и поспать успеет.

 

>>>Я так понял, вы конкретно с A7672E не работали. Их, кста, как минимум две версии есть, и вторая вообще не про АТ-команды))

 

Неверно - есть с GNSS и без. Остальное одинаковое.

 

А вот с АТ и под Linux это уже CAT4 - A7602E-H --- разные модули с разными чипсетами. 

[jcxz 184]

3 часа назад, adnega сказал:

Нельзя все валить на программиста. Есть еще такое понятие как "архитектура ПО". Любое спроектированное ПО будет иметь свои ограничения.

А "архитектуру" эту кто разрабатывает? Не программист-ли? Или какой-то дядя?

3 часа назад, adnega сказал:

Просто, он может обрабатывать другие более приоритетные задачи. Обратите внимание на "фаршированность" модуля - там много чему нужно работать помимо AT.

Это вы можете бабушкам на лавочке у подъезда рассказывать. А не на форуме, где есть разработчики firmware.

Типичный драйвер UART - это приём данных в ISR (в худшем случае, если нет DMA). Заблокировать ISR может только или более приоритетный ISR или длинные запреты прерываний. Выше вы же сами писали, что "блокировки происходят через примерно каждые 16 байт". Что косвенно свидетельствует о наличии аппаратного FIFO на 16 байт.

Считаем: 16/92160 = ~174мкс. Программа, в которой прерывания блокируются на 174мкс(!) на мощном CPU без критической в том потребности в нормальном режиме работы - совершенно очевидно написана криворуким программистом. Можете бабушек у подъезда пытаться убедить в обратном. Здесь не надо такое рассказывать.

 

Ну или дело не в программе, а условиях работы вашего SIMCOM-модуля. Может вы ему питание нормальное не обеспечили? И, из-за просадок, у него какой-нить внутренний монитор переводит его в sleep. Это только предположение. Или ещё чего. Но такое поведение (останов FC посреди вводимой команды) - это явно ненормально.

 

3 часа назад, adnega сказал:

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

Да хоть 10 клавиатур. Всё это такие слёзы, что самый дохлый Cortex-M с несколькими такими задачами справится.

Я же выше писал:

1. Декодирование тяжёлого AAC+ 128 кбит/сек + динамическая графика на 320x240 ЖКИ == ~56% загрузки Cortex-M4 96МГц.

2. Декодирование MP3 192 кбит/сек + программный TLS (HTTPS) + динамическая графика на 320x240 ЖКИ == ~30% загрузки Cortex-M4 96МГц.

Это кроме того, что работает драйвер для AT-командной прошивки ESP8266.

Это кроме того что в это же время на этом же МК выполняется ещё куча остальных мелких задач, где и клавиши и ИК-приёмник и touchscreen-драйвер и драйвер nRF24L01+ и кучка датчиков и куча прочей мелочи.

 

3 часа назад, adnega сказал:

)) Если вы имеете дело только с миганием светодиодом, то вам неизвестна вся боль, возникающая при организации связи с интеллектуальной второй стороной.

Чукча не читатель, чукча - писатель?

3 часа назад, adnega сказал:

Под "миганием", я понимаю, ваш полный контроль за выполнением команд. Как только появляется нечто, что может не ответить, или может задуматься, то появляются совершенно новые

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

Это троллинг? Вы в состоянии оценить сколько какая задача требует ресурсов? У меня появляются сомнения в этом...

Что такое "TLS", "декодер MP3", "декодер AAC+" - понимаете? Когда-нить хоть что-то близкое по сложности приходилось реализовывать?

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

 

Заключение: Принять в буфер из UART 16 байт, не повесив при этом намертво ARM с тактовой в 614 МГц - для вас непосильная задача за гранью фантастики. Это мы уже поняли.  

[adnega 10]

В 10.10.2023 в 17:34, jcxz сказал:

А "архитектуру" эту кто разрабатывает? Не программист-ли? Или какой-то дядя?

Я не думаю, что с выходом нового модуля программисту начинают придумывать архитектуру ПО с нуля.

Конечно, есть наработки - их используют. Но разговор не об этом.

Я вас понял, вы можете реализовать обмен по UART, не используя FC, я тоже могу и мне ни разу не приходилось тормозить поток.

А SIMCOM то ли не могут, то ли не хотят, раз у них такой функционал есть и он живой. Может, там историческая подоплека.

В 10.10.2023 в 17:34, jcxz сказал:

Ну или дело не в программе, а условиях работы вашего SIMCOM-модуля. Может вы ему питание нормальное не обеспечили? И, из-за просадок, у него какой-нить внутренний монитор переводит его в sleep. Это только предположение. Или ещё чего. Но такое поведение (останов FC посреди вводимой команды) - это явно ненормально.

Повторю: я использую оригинальную отладочную плату. В разных условиях связи она работает по-разному.

В 10.10.2023 в 17:34, jcxz сказал:

Да хоть 10 клавиатур.

Я не знаю чем в модуле проц занят. Но это похоже не на то, что он не умеет в UART, а скорее на отказ в обслуживании, мол, данные ты, конечно, можешь заслать, но их модуль все равно в сеть не отправит.

В 10.10.2023 в 17:34, jcxz сказал:

Чукча не читатель, чукча - писатель?

Я не защищаю ни SIMCOM, ни пытаюсь вас оспорить в части правильного ПО - я лишь привел примеры с чем лично сталкивался, где без FC в некоторых случаях будет грустно.

Ваше право распорядится этой информацией как посчитаете нужным.

В 10.10.2023 в 17:34, jcxz сказал:

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

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

Кроме UART модуль может заниматься и другими делами. Поскольку там стоит МК профиля R, осмелюсь предположить, что и задачами реального времени.

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

Чем именно занимается проц и сколько это длится по времени - я знать не могу.

В 10.10.2023 в 17:34, jcxz сказал:

С вами всё ясно.

Я-то тут причем? Обсуждаем не меня, а факты. Хотите - можете повторить поведение модулей. Ваши советы строятся на вашем же понимании качественного ПО.

Вы, не сомневаюсь, можете запустить любой модуль и любой проц, чтоб не глючило, и даете советы. Кому? Профессионалам - дык, они сами с усами.

Новичкам? Увы, они не смогут все и сразу сделать правильно, столкнутся с неидеальностью модулей - тут-то их FC и выручит.

Я на A7672E вообще основным каналом постараюсь сделать USB, поэтому FC - не актуально. Использую SIM868 без FC - и тоже не грущу.

Чтоб закрыть тему про меня, доложу: АТ-команды, в моем понимании, устаревшая технология.

На ESP пишу софт непосредственно под ESP, на SIMCOM использую EAT где возможно.

Постараюсь на новых модулях уйти от UART в сторону USB, где есть интерфейсы сетевой карты и CDC (debug+GSM+GNSS).

Если конкретно у вас нет FC-опыта, то это не значит, что FC не существует))

В 10.10.2023 в 16:27, CADiLO сказал:

А вот с АТ и под Linux это уже CAT4 - A7602E-H --- разные модули с разными чипсетами. 

Вы правы, я этого не знал, и какое-то время пытался работать с ним через АТ-команды. Что-то работало, но соединение так установить и не получилось))

[jcxz 184]

14 минут назад, adnega сказал:

Я не знаю чем в модуле проц занят. Но это похоже не на то, что он не умеет в UART, а скорее на отказ в обслуживании, мол, данные ты, конечно, можешь заслать, но их модуль все равно в сеть не отправит.

Знать мы не можем, но можем взять МК, занимающийся задачей примерно такого же класса. И сравнить. Именно поэтому и я привёл для сравнения ESP8266: Процессор близкой производительности (всего-то в несколько раз медленнее  ), задача примерно такая же - обслуживание WiFi-стека, обработка примерно таких-же AT-команд.

Но всё-же:

1. ESP8266 примерно в 4 раза медленнее (а может и более, так как там ядро не ARM, а менее эффективное).
2. Скорость UART у ESP - в 2 раза выше чем в вашем примере (1843200 vs 921600).
3. Обслуживание всех потребностей радио-части (в чём бы они не заключались) - лежит полностью на том же ядре (нет отдельного DSP, как у A7672).

Судя по этим 3-м пунктам -> ESP даже и на 115200 бод не должен работать без FC. Но он почему-то работает на 1843200 бод.

 

14 минут назад, adnega сказал:

Ваши советы строятся на вашем же понимании качественного ПО.

Я разве что-то советовал? Где?

Я всего лишь говорю что, те симптомы, которые вы привели на осциллограммах - ОЧЕНЬ странные. Я бы даже сказал - неправдоподобно странные. Ибо такого - не должно быть.

А если "быть не должно, но есть", то нужно искать причину - "почему?" А не складывать лапки, что "так и должно быть". Именно в этом и была моя мысль. О чём я несколько раз писал.

 

Кроме причин, о которых говорил выше, ещё причина может быть в контрафактности модуля. Может он у вас контрафактный? И там левая прошивка?

У нас была такая же ситуация перед тем, как мы применили SIM868 - сначала мы взяли SIM808. И начали работать с ним. Вот там как раз была куча подобных глюков - и пропуски байт и многие другие "чудеса".

Но спасибо ув. CADiLO - он просветил нас, что SIM808 вообще для нашего рынка не поставляется. А если мы его где-то всё же купили - то это контрафакт, и что там внутри него - одному Ляо известно.

 

 

14 минут назад, adnega сказал:

Если конкретно у вас нет FC-опыта, то это не значит, что FC не существует))

Вы опять не читаете что я пишу, а что-то выдумываете:

15 часов назад, jcxz сказал:

На SIM868E делал проект, в котором была интенсивная передача файлов (не какие-то отдельные команды, а объёмные файлы). Да - изначально заложили в схему CTS/RTS. Но при разработке прошивки выяснилось, что прекрасно работает и без flow control. Правда я работал на 460800 бод. Не помню - пробовал ли выше, возможно не пробовал. Но я тестировал передачами файлов большого объёма и ничего не терялось.