реклама на сайте
подробности

 
 
2 страниц V  < 1 2  
Reply to this topicStart new topic
> lwIP (PPP) проблема, странная
cpl
сообщение Nov 3 2011, 07:38
Сообщение #16


Местный
***

Группа: Свой
Сообщений: 378
Регистрация: 6-12-04
Пользователь №: 1 340



Цитата(kan35 @ Nov 3 2011, 10:08) *
у вас какая версия? (у меня 7.0.0).


6.0.3
Go to the top of the page
 
+Quote Post
kan35
сообщение Nov 3 2011, 13:14
Сообщение #17


Знающий
****

Группа: Участник
Сообщений: 537
Регистрация: 22-02-06
Пользователь №: 14 594



Цитата(cpl @ Nov 3 2011, 11:38) *
6.0.3

а большие пакеты принимать пробовали?
скажем, от 100кб
Go to the top of the page
 
+Quote Post
cpl
сообщение Nov 3 2011, 13:46
Сообщение #18


Местный
***

Группа: Свой
Сообщений: 378
Регистрация: 6-12-04
Пользователь №: 1 340



Цитата(kan35 @ Nov 3 2011, 16:14) *
а большие пакеты принимать пробовали?
скажем, от 100кб


Пакет 100кб ?!

Расматриваю приходящие даные как поток с последующей разборкой того что пришло.
Для теста всял большой текстовый файл 250кб и отправил с сервера через инет клиенту (своей железке)
минут 5 может больше приходили данные неприрывно, пока все не пришло, система живет.

У Вас значение TCP_MSS = 1500-40, зачем такое значение ?
и почему ?
Какой у Вас размер буфера для принятых данных из модема ?
Go to the top of the page
 
+Quote Post
kan35
сообщение Nov 3 2011, 14:11
Сообщение #19


Знающий
****

Группа: Участник
Сообщений: 537
Регистрация: 22-02-06
Пользователь №: 14 594



Я начал работать на аппноте от ST - там был ethernet и это (1500-40) - максимальный пакет для eth. В принципе, в PPP получается примерно такой же размер - 1260-1460 байт и я его не стал менять. Я пробовал уменьшать до 600 и до 100 байт как я писал в одном из прошлых сообщений- - результат отрицательный.
Буфер приема (PBUF) - 5кБ:
#define PBUF_POOL_SIZE 10
#define PBUF_POOL_BUFSIZE 500
Пробовал увеличивать - не влияет.
Исходники на lwIP скачал с их сайта, и полностью файлы в проекте заменил, чтобы не было шанса что я что то не то сделал...
FreeRTOS обновил до 7.0.2 на всякий случай.
Еще не понятно почему раньше было 9 пакетов - теперь 35... Хотя ничего не изменилось.
Go to the top of the page
 
+Quote Post
cpl
сообщение Nov 3 2011, 14:29
Сообщение #20


Местный
***

Группа: Свой
Сообщений: 378
Регистрация: 6-12-04
Пользователь №: 1 340



Цитата(kan35 @ Nov 3 2011, 17:11) *
Еще не понятно почему раньше было 9 пакетов - теперь 35... Хотя ничего не изменилось.


Раньше были проблемы с FlowControl, или не всчет !?

Цитата
Какой у Вас размер буфера для принятых данных из модема ?

Подругому: Какой размер очереди queue_gprs_bytes ?

Код
#define TCPIP_THREAD_PRIO             (tskIDLE_PRIORITY)
#define PPP_THREAD_PRIO        (tskIDLE_PRIORITY)


По приоритетам, не маловато ли ?


Go to the top of the page
 
+Quote Post
kan35
сообщение Nov 3 2011, 15:42
Сообщение #21


Знающий
****

Группа: Участник
Сообщений: 537
Регистрация: 22-02-06
Пользователь №: 14 594



нет, с FlowControl нет проблем и не было (просто тогда было совпадение).
queue_gprs_bytes сейчас 2000 байт, когда было 200 байт - то иногда не успевал обрабатывать и получались dropped.
Приоритетами играл - не то.

Вот еще что, я немного переделал функцию приема и вот что получилось:
Код
void get_rest_of_FW(unsigned long bytesleft, File * file)
{
    LED_RedBlink(10);
    struct netbuf * in_buf;
    unsigned short k = 2;
    while (bytesleft)
    {
        if (in_buf = netconn_recv(conn))
        {
            // успешно приняли что то
            char * incoming_data;
            unsigned long buflen = netbuf_len(in_buf);
            if (incoming_data = (char *)pvPortMalloc(buflen))
            {
                {
                    char * data; u16_t len;
                    netbuf_data(in_buf, (void **)&data, &len);
                    printf_diagn("%d: %lX->%lX (%d:%d)\r\n\r\n", k, data, incoming_data, buflen, bytesleft-buflen );
                }
                netbuf_copy(in_buf, incoming_data, buflen);
                if ( ((signed long)bytesleft - (signed long)buflen) < 0 ) //// заплатка
                    buflen = bytesleft;
                file_write(file, buflen, (unsigned char *)incoming_data);
                vPortFree(incoming_data);
            }
            else
            {
                LED_RedBlink(4);
            }

            bytesleft -= buflen;
            netbuf_delete(in_buf);
            k++;
        }
        else
        {
            //bytesleft = 0;
            netconn_write(conn, "#M#push\r\n", strlen("#M#push\r\n"), NETCONN_NOCOPY); // заплатка
        }
    }
    LED_RedBlink(0);
}

Здесь собственно что: когда данные из модема перестают поступать я кидаю строчку "#M#push\r\n" в сервер (это типа просто текстовое сообщение от клиента), после этого сервер начинает опять слать очередную порцию данных. И так соответственно 2 раза за 130кБ.
В конце массива я на 2 своих текстовых сообщения получаю 2 текстовых ответа-подтверждения (в рамках протокола Wialon). Просто не беру эти куски в учет и все... - файл передан.
В этой связи вопрос такой: может ли быть на сервере или у оператора gsm какое то ограничение на время отправки пакета с таким вот эффектом запора?
Go to the top of the page
 
+Quote Post
kan35
сообщение Nov 17 2011, 11:48
Сообщение #22


Знающий
****

Группа: Участник
Сообщений: 537
Регистрация: 22-02-06
Пользователь №: 14 594



Проблема решена, оказывается дело не в стеке и даже не в моем софте, а в сервере Wialon который почему то вот так дробил пакеты и зависал. После 2-недельного обвинений меня в том, что у меня кривые руки виалоновские инженеры все таки поправили баг и стало мне счастье.
Go to the top of the page
 
+Quote Post
cpl
сообщение Nov 17 2011, 13:10
Сообщение #23


Местный
***

Группа: Свой
Сообщений: 378
Регистрация: 6-12-04
Пользователь №: 1 340



Примите мои искрение поздравления.
Go to the top of the page
 
+Quote Post

2 страниц V  < 1 2
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 18th June 2025 - 08:09
Рейтинг@Mail.ru


Страница сгенерированна за 0.0238 секунд с 7
ELECTRONIX ©2004-2016