Добрый день!

Просматривая тему "SIM900 Подключение к GPRS", один из участников сказал следующее , другой из участников привел аргументы в пользу PPP , но аргументов, почему от использования PPP следует отказаться (кроме того что реализация внешних стеков TCP\IP и PPP, требует значительных аппаратных ресурсов) я так и не увидел.

Хотел бы узнать у сообщества, почему про PPP "лучше забыть вообще"...

Они просто не знают что такое PPP или имеют его примитивные реализации.
PPP используется в VPN и никто от него отказываться не собирается.
Правда в былые времена в Win XP был встроенный PPP сервер. И можно было просто подключившись к RS232 компьютера включить автоматом броузер с WEB страницей дивайса.
Нынче такую фичу с PPP убрали из Windows. Но есть RNDIS и можно подключившись по USB автоматом открыть WEB страницу дивайса.
Хотя будущее за BLE 5.0 с профилем TCP, так что любители малинок и ардуин могут себе позволить забыть про PPP.

Использую PPP из LWIP. Мне кажется удобно не привязываться к строенному стеку.

Пример для SIM800 кто-нибудь может показать в качестве отправной точки? У меня есть устройство с эзернетом и lwIP, заказчик хочет сделать резервный канал на SIM800. Полагаю, поднять ppp будет гораздо проще, чем дублировать весь код обмена с использованием внутреннего стека модема. Точнее, какие-то примеры я в интернете бегло находил, но они начинаются с

pppoe? Есть такое, правда, уже так часто, как в эпоху модемов, не используется.

И да, понятное дело, этой штуке нужен внешний сервак с хотя бы серым айпишником. А при таких делах проще без ppp наладить обычную связь tcp/ip.

все USB-свистки 3G/4G имеют интерфейс подключения к ПК - COM over USB.
а затем поверх этого COM комп поднимает PPP-сессию с провайдером, где фигурируют APN, login и password.
просто потому, что так задумано и поддерживается microsoft и её виндой.

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

Прям все!?
Может все-таки CDC-ECM?
Там не нужен никакой PPP.

ну удивите меня.
назовите пять наиболее популярных USB-свистков, в которых в качестве основного транспорта используется ваш Ethernet-over-USB aka CDC-ECM?

Свистки сами по себе уже пережиток.
Так что в историю я углублятся не буду.
Ну вот пару лет назад у меня был AX326. Так вот он обычный network adapter в системе. Никаких PPP не было.

Плюсую. Есть у меня "свисток" от билайна, поддерживающий 4G. В системе он — как обычная USB'шная сетевуха. И никаких ppp не надо, я уж забыл, когда последний раз надо было на "свистке" в бубен бить и ppp поднимать. Сейчас они вполне себе хорошо работают, главное — если ядро самосборное, не забыть всяких разных модулей понакомпилять для них. Иначе придется, как мне в аэропорту, ядро пересобирать, чтобы интернет получить (да-да, уже года 3-4 назад в московских аэропортах "бесплатный" wifi практически не работал, сейчас ситуация еще хуже).

Статью "STM32 + PPP (GSM) + LwIP" смотрели?

В который раз убеждаюсь, что ничего приличного на БХ не выкладывают! Какой же автор наHAL!

Нет, не смотрел. Спасибо.

Почему применение библиотеки HAL вызывает негатив?

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

А как в случае PPP обрабатывать входящие/исходящие звонки и смс?

Видимо использовать сигнал RI для определения есть ли входящие звонки и смс, если есть, то переход в командный режим (+++), обработка звонков и смс и обратный переход в data режим (ATO)?

Поднимаете CMUX. По одному каналу гоняете PPP, по другому всякие смс, звонки и т.п. При этом максимально используете стандартные АТ команды, которые поддерживают все производители.
Вот буквально недавно поменял в устройстве телит на симком и все работает как и работало.

У SIM800 есть второй UART порт. По одному можно лазить в PPP, а с другого ловить URC. Если обратитесь к док.SIM800 Series_Serial Port_Application Note_V1.хх, то там все найдете.

Судя по доке SIM800 Series_Serial Port_Application Note_V1.01 UART1 не полный, а UART2. Для модуля SIM800C наоборот. Значит ли это что в таблице UART1 и UART2 для SIM800C нужно поменять местами?

А где вы в 800С при штатной прошивке вообще второй UART нашли?

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

>>>>Схемотехнически он обозначен.

Дык он даже и доступен, но только из EAT
В ЕАТ и USB пользователю доступно как третий UART

EatUart_enum - This enumerate all the UART ports!

EAT_UART_1
represents physical UART port 1

EAT_UART_2
represents physical UART port 2

EAT_UART_USB
represents physical USB port

Значит для модулей SIM800С использовать 2-ой UART для PPP не получится на текущих версиях ПО.

Rash, а чем не устраивает CMUX? Мне кажется, это проще, чем тянуть кучу дорожек от модема, использовать драгоценные ноги проца, и, главное, быть привязанным к определенному модему!

Думаю устроит и CMUX, просто поинтересовался, раз тема такая возникла. Вначале ещё в планах к PPP добраться нужно. Ножки проблема, если устройство малогабаритное, но и то есть корпуса QFN, а в основном 2 лишних дорожки не проблема.
Нашёл минимум одно ограничение, BT модуль не поддерживает CMUX, для этого случая 2 UART будут предпочтительнее.

Есть несколько подходов к реализации.
PPP нормальная реализация для того чтобы в контексте поднять подключение получить IP и радость и счастье. Все современные модемы несколько более функциональны, имеют встроенные стеки TCP/IP шифрование SSL и не к ночи помянутое HTTPS. Возможно в 1 контексте поднять подключение и раздавать на хост интернет а в других контекстах работать на прямую со стеком TCP/IP модема.
Второй подход Intel CDC-ECM драйвер через USB открывает пачку USB-COM и пачку Ethernet.
Третий подход Qualcomm так же через USB только QMI интерфейсы. Некоторые производители выпускают свои библиотеки QMI и драйвера, чтобы можно было делать более сложны вещи. Агрегацию каналов управление трафиком по качеству обслуживания и так далее.

PPP иногда не совсем правильно настраивают, он начинает отваливаться например при 2 - 5 секундных задержках на слабых БС, по этому вот такие категоричные мнения.

2 дорожки для модема - не считаю, что это хорошо. Без контроля передачи - могут быть проблемы!

Это да, по документации есть такие грабли.
Хотя, я так вообще не понимаю, как можно одновременно использовать BT и GSM часть без MUX... Ведь каждая из подсистем будет иметь свои "плавающие задержки" То есть, к примеру, при регистрации модуля в сети будет таймаут на передачу данных по BT...
ИМХО, BT в модуле без MUX нужно использовать исключительно из под EAT.

Контроль можно и программно сделать. А задержки, это я уже молчу, всех устраивает, все этому явлению могут найти адекватное объяснение (на дворе 2017 год, а тут задержки в секунды, в следующем году, с новой операционкой, до минут дойдут)

не верно, получится.

Feature list SIM800C:
Dual UART
SIM800C24 - yes
SIM800C32 - yes

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