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


Потоком подавать не анализируя ответы это... просто кю, дешевая поделка.

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

Да не совсем религиозный. В командном режиме нет возможности контролировать переполнение буфера. При переполнении при попытке отправить пакет получите ERROR, при этом часть данных может таки быть отправлена поэтому просто повторить передачу не получится. CTS в этом режиме не работает(и IPR, и #CFLO, и #FLO все пробовал - пофиг). Гарантировать же непереполнение буфера при том, что возможны "замирания" в GPRS канале секунд порядка 30сек тяжковато. В прозрачном режиме CTS работает как положено.



Вообще со скоростью ситуация непонятная. Есть 2 девайса с GL868(оба модуля из одной партии), один на STM32 другой на PIC32 и в том и другом выход UARTа, для согласования уровней, сконфигурирован как ОК. PIC32 на 115200 с модулем работает без ошибок, а вот на STM32 вышеописанная проблема. Пока грешу на то, что STMовская библиотека через которую конфигурировался UART не точно выставляет скорость. Как будет чуток времени буду копать дальше, а пока оставил на 57600.

Совсем религиозный задачи у всех разные и самое главное ПРОТОКОЛЫ. Меня переполнение не трогает ни разу - протокол основан на запросах с сервера. Если гнать потоком, то конечно - непрозрачный режим не годится. Так что нельзя сказать однозначто что этот режим дерьмо, а второй идеальный. Для унивесальности в модеме обязаны быть оба режима.


Точно так же: GL868 + STM32 с ОК = проблем ноль (ну кроме вышеупомянутых URC). От библиотек отказаля сразу - поглядел на исходники - волосы на голове зашевелились. Да еще и с ошибками.