[Sergiy_master 0]

Добрый день

 

Проблема соединения 3G модема Telit к RL-TCPNet на STM32F4 используя PPP соединение.

 

Начал с того, что проверил RL-TCPNet стек PPP соединение подключившись к нему с компьютера, как указано в демо для данного Keil стека. Микроконтроллер ждет соединение после команды "ppp_listen ( "Keil","");". Компьютер первым начинает передавать данные (LCP, NCP and e.t.c.), все работает отлично.

 

Теперь пытаюсь подключить UL-865 (Telit, 3G) к STM32F4 для выхода в интернет. После команды модему "ATD*99***1#" он отвечает "CONNECT" и начинает первым передавать пакеты для соединения. STM32F4 находиться в ждущем режиме команда "ppp_listen ( "Keil","");SendToPPPStack ("CLIENT");". Модем видно отсылает одинаковые пакеты, около 10-ти и затем разъединяет связь "NO CARRIER". Стек не отвечает на данные запросы и связь не устанавливается. Мне кажеться, что Keil стек не разработан для работы с модемами и готов только подключаться к компьютеру или неправильные настройки PPP. Кто сталкивался с данной проблемой?

Кто может подсказать, по данному вопросу?

 

Я раньше пробывал подключить STM32F4 к USB модему E220, данное подключение работает т.к. модем находится в ожидании пакетов PPP после команды "ATD*99***1#". Стек в режиме "client" ( использую команды ppp_connect ("","", "");SendToPPPStack ("CLIENTSERVER");" Созданная тема здесь.

Такую же схему использовал для подключения к модему GL-865 ( Telit). В таком модеме есть возможность настроить его как PPP Server и он ожидает подключения. То же все работает.

 

 

[Sergiy_master 0]

Всем огромное спасибо за помощь....

 

Теперь ближе к делу.

Сначала совет: советую подключить компьютер к модему через COM соединение. Win XP имеет достаточно инструментов для этого. Первое, что станет ясно, так это правильно ли указан APN ( Access Point Name). Работает ли модем с данным оператором и т.д.

 

Теперь непосредственно к RL-TCPNet from Keil:

1. Демо которое предлогают вместе со стеком это хорошо, но увеличить буфер приема и передачи по USART рекомендую с 256 до 1600. Насколько я помню, максимум размер полного TCP пакета 1514 ( Ethernet Frame Max Transfer Unit from Net_Config.h). Я предлогаю этот Frame покрыть, иначе кто его знает сколько инфы вы передаете.

2. Разделить буфер когда модем инициируеться и непосредственно общается по РРР. RL-TCPNet не очень любит видеть у себя в буфере "ATD*99***1#" и другие команды, а так же "CONNECT" в ответ. Заполняйте буфер для стека информацией от модема после подсоединения к 3G сети ( ответ от модема "CONNECT" ).

3. Будьте аккуратны с IRQ по USART, особенно если работаете под RTOS. Еще раз, когда Keil дает демо это здорово, и далее по тексту...

4. Даже если модем начинает связь первым ( отсылает LCP пакеты ), Я использовал команду ppp_connect ( "","","" );os_dly_wait ( 500 );SendToPPPStack ("CLIENTSERVER");

 

Это мои личные заметки.

 

Проблема решена.

 

 

[kan35 7]

Я заметил, что beeline и megafon работают отлично даже с неправильными настройками APN, мтс не проверял. Хотя важно внести корректные конечно.

1. 1514 - это размер ethernet пакета, но у вас нет ethernet, кроме того, в процессе LCP модем стек договаривается с сервером какие у обоих возможности по буферам, по возможностям сборки дефрагментированных пакетов и т д, неправильные настройки могут только привести к пониженной производительности. Если протокол не может самонстроиться - стоит обратить внимание на другие стеки.

2. логично, хотя полагаю, это не может завалить стек

3. Да, будьте аккуратны:-)

4. Тут не могу ничего сказать, в свое время я использовал lwIP с модемом и там все очень просто было. Был в конфигурации с FreeRTOS, при которой создавалось 2 потока: PPP и TCP, и для использования стека требовалось сделать только 2 кастомных функции - передачу и прием байтов в UART (в PPP мессадж бокс), никаких буферов не надо было создавать вне стека, стек сам делал все необходимое.

 

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

Изменено 3 января, 2015 пользователем kan35

[Sergiy_master 0]

У меня такое ощущение, что Я прохожу kan35 у вас экзамен. Ваша помощь требовалась 25 декабря, когда создавался топик. Я написал для тех у кого есть вопросы и нет ответов.

 

kan35, где в Demo from Keil указан размер принимаемого и передающего буферов, которые TCP stack использует для "договаривается с сервером "?

 

Когда пишешь вопрос, то иногда отвечают, что вопрос или тех. задание не совсем ясно. Я пишу про размер буфера RL-TCPNet PPP стека. В ответе: "я использовал lwIP с модемом и там все очень просто было". Разные люди - разное восприятие. Проехали...

 

Админ, если возможно, то отпишите в имени топика [РЕШЕНО], может кому поможет.

[kan35 7]

для конфигурации размера пакета нужно подкручивать TCP_MAX_SEG_SIZE, соответственно из этого числа формируется размер пакета PPP, и в момент работы LCP negotiation сервер и клиент сообщают друг другу какой размер пакета у того и другого и принимают для работы наименьший. Потому, ошибиться в размере невозможно, спасибо википедии))).

Вы задали вопрос, потом отвечаете на него якобы, но я вижу, что пункты 1-4 из вашего решения не соответствуют или слабо коррелируют с поставленной вами же проблемой. А раз вы пишите, что проблема решена, но интересно было бы понять в чем именно было дело, пока вы сами не знаете в чем, и как это поможет кому то еще - не понятно. Мне самому интересно, так как в свое время повозился с другим стеком. Не обижайтесь.

[Sergiy_master 0]

для конфигурации размера пакета нужно подкручивать TCP_MAX_SEG_SIZE, соответственно из этого числа формируется размер пакета PPP, и в момент работы LCP negotiation сервер и клиент сообщают друг другу какой размер пакета у того и другого и принимают для работы наименьший. Потому, ошибиться в размере невозможно, спасибо википедии))).

Вы задали вопрос, потом отвечаете на него якобы, но я вижу, что пункты 1-4 из вашего решения не соответствуют или слабо коррелируют с поставленной вами же проблемой. А раз вы пишите, что проблема решена, но интересно было бы понять в чем именно было дело, пока вы сами не знаете в чем, и как это поможет кому то еще - не понятно. Мне самому интересно, так как в свое время повозился с другим стеком. Не обижайтесь.

 

 

Значиться так, в RL-TCPNet параметра TCP_MAX_SEG_SIZE я не нашел. Укажите файл где этот параметр храниться! Я нашел #define TCP_MAXSEGSZ 1460 из файла Net_Config.c. А теперь берем демо файл "Serial_STM32x.с" в котором объявляеться буфер

/* Local variables */
struct buf_st  {
  U8 in;
  U8 out;
  U8 buf [256];
};

А теперь вопрос. Где тут: "стек договаривается с сервером какие у обоих возможности по буферам, по возможностям сборки дефрагментированных пакетов"? Если вы не поняли о чем речь с начала, то поверю. Это то, что я имел ввиду.

 

Теперь открываем страницу с ткаимим словами: The Windows client sends the string "CLIENT". The Keil evaluation board must then send the string "CLIENTSERVER". When operating as a server, the Keil evaluation board must send the string "CLIENT". The Windows client must respond with the string "CLIENTSERVER". Я надеюсь вам теперь ясно, что имелось в виду под именами: Server/Client?

 

В первом сообщении Я изложил проблему с вопросом. Затем нашел в чем я ошибся и по пунктам написал решение для тех, кто имеет проблему как я: подключения TCP stack к модему по протоколу PPP.