Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: tcp_check_send выдает нулевое значение
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
smk
Функция
Код
tcp_check_send (my_socket)
стала возвращать нулевое значение. Из-за этого не происходит передачи. Раньше все работало хорошо. Внесенные изменения коснулись лишь сохранения значений во внешнюю EEPROM. Хочу спросить как можно узнать что повлияло и что вообще может повлиять. Спасибо.
smk
Попробовал прежние рабочие проекты. Там тоже не работает. Что бы это значило?
Golikov A.
провод сетевой отвалился...
Поменялся хаб и перестала автонегатинация проходить,
погорело железо
забилось окно приемника виндуса
повис драйвер...

smk
Цитата(Golikov A. @ Jul 27 2014, 22:07) *
провод сетевой отвалился...
Поменялся хаб и перестала автонегатинация проходить,
погорело железо
забилось окно приемника виндуса
повис драйвер...

Я тоже подозревал, что дело не в программе. Однако линк есть и пингуется. Веб-страничку показывает. Соединение прямое с компьютером, стоит отдельная сетевая карта.
Golikov A.
Данные что шлете на стороне компьютера вычитываете? Может окно забилось? Управление потоком есть?
smk
Цитата(Golikov A. @ Jul 28 2014, 09:45) *
Данные что шлете на стороне компьютера вычитываете? Может окно забилось? Управление потоком есть?

Тут наоборот. Я шлю из компьютера, МК получаети дает ответ. Данные приходят, а ответ не уходит т.к. вышеупомянутая функция не дает сделать отправку.
Golikov A.
а что tcp_get_state возвращает? Может коннект по какой-то причине закрылся?
smk
Цитата(Golikov A. @ Jul 28 2014, 18:39) *
а что tcp_get_state возвращает? Может коннект по какой-то причине закрылся?

Пробовал вот так переписывать, но результат тот же:
Код
void send_data (void)
{
  unsigned char remip[4] = {192,168,0,1};

    switch (tcp_get_state (my_socket))
    {
            case TCP_STATE_FREE:
            case TCP_STATE_CLOSED:
                /* Connection idle, send Connect Request. */
                tcp_connect (my_socket, remip, PortNumber, 0);
                break;
            case TCP_STATE_CONNECT:
                /* We are connected, send command to remote peer. */
                if (tcp_check_send (my_socket))
                    {
                        maxlen = tcp_max_dsize (my_socket);
                        if(maxlen > 255) maxlen = 255;
                        sendbuf = tcp_get_buf (maxlen);
                        memcpy (sendbuf, my_tx_buff, maxlen);
                        tcp_send (my_socket, sendbuf, maxlen);
                    }
                break;
        }
}


Попадает на ту же функцию и опять передачи нет.
Golikov A.
чудеса... а дебуг что говорит? Если включить его на полную и почитать что в порт идет?
smk
Цитата(Golikov A. @ Jul 28 2014, 22:50) *
чудеса... а дебуг что говорит? Если включить его на полную и почитать что в порт идет?

Не совсем понял что имеется в виду. Может шарком посмотреть что приходит? Хотя я так понимаю что коннект есть.
Golikov A.
простите, с LwIP перепутал, у него есть дебугер встроенный в стэк.

Шарком смотреть конечно можно, но надо понять что искать... я так понимаю эта функция еще до посылки возвращает 0...
А может быть такое что вы в Net_config.c настройки ТСР сбили?
smk
Цитата(Golikov A. @ Jul 29 2014, 10:52) *
простите, с LwIP перепутал, у него есть дебугер встроенный в стэк.

Шарком смотреть конечно можно, но надо понять что искать... я так понимаю эта функция еще до посылки возвращает 0...
А может быть такое что вы в Net_config.c настройки ТСР сбили?

Наврядли. Посмотрю конечно, но старые проекты тоже того... Проверю, напишу. Кстати при заходе на страничку все настройки отображаются правильно. Что можно еще посмотреть?
Golikov A.
Ну по описанию эта функция вернет 0, если
1. Нет соединения по сокету
2. Нет акак на прошлые посланные данные

Соединение по сокету есть, вы вроде проверили...
остается Шарком смотреть что идет в ответ на первые посланные данные. Не может же быть так что вообще ни одни данные послать нельзя с самого начала.

Ну еще раз проверить внутренности стека, число разрешенных сокетов, памяти и прочее...

Еще из стресс тестов, убрать эту проверку посмотреть что будет.
И еще можно попробовать добавить keep_alive режим, который проверяет с заданным таймаутом жизнеспособность сокета, может сокет накрывается а устройство об этом и не знает...
smk
Цитата(Golikov A. @ Jul 29 2014, 15:00) *
остается Шарком смотреть что идет в ответ на первые посланные данные. Не может же быть так что вообще ни одни данные послать нельзя с самого начала.

Ну еще раз проверить внутренности стека, число разрешенных сокетов, памяти и прочее...

Еще из стресс тестов, убрать эту проверку посмотреть что будет.
И еще можно попробовать добавить keep_alive режим, который проверяет с заданным таймаутом жизнеспособность сокета, может сокет накрывается а устройство об этом и не знает...

Вот что удалось увидеть шарком. Последние 3 строчки это посылка символов "123". tcp_check_send (my_socket) возвращает 0. Получается что сокет не готов к передаче. Почему?
Нажмите для просмотра прикрепленного файла

Вынес передачу из tcp_callback и все заработало. В tcp_callback выставляю флаг а все остальное делаю по флагу в основном цикле. Не уверен что это хорошее решение если ответ требуется как можно быстрее или с лимитом времени на ответ.
Golikov A.
ОООО! а разве можно в TCP калбеке что-то слать? Туда же валятся не только приход данных, но и приемы подтверждений и прочее...

А как передача была сделана? на прием данных? В описании написано при посыле данных резервируются данные на 1 пакет, и пока он не акнется буфер не освобождают, и новый выделить нельзя. Может получалось 2 вызова друг за другом?...

у меня все что пришло валится во входной буфер циклический, а все что я хочу отправить в другой выходной буфер. И в главном цикле программы я постоянно проверяю если есть что во входном буфере обрабатывают, если есть что отправить - отправляю. Все равно пока вы не вызовете главную функцию обработки стэка ничего не уйдет, так какой смысл мгновенно добавлять данные? А в таком режиме я по несколько пакетов собираю и разом отправляю!
smk
По приходу пакета я отправлял тестовый пакет, а пришедший копировал в буфер. Наоборот конечно правильней, но работало же. Смысл своевременных отправок в том, чтобы измеренные значения поступали в тот момент когда они соответствуют обстановке, а не когда все поменялось и сообщение фактически устарело. Скажем периодичность в десятки мС при размере в 256 байт устроила бы. Скажем раз в 25 мС.
Раньше отправка стояла там где сейчас Flags.Send_answer = 1;

CODE
void tcp_send_buff (void)
{
unsigned char remip[4] = {192,168,0,1};

switch (tcp_get_state (my_socket))
{
case TCP_STATE_FREE:
case TCP_STATE_CLOSED:
/* Connection idle, send Connect Request. */
tcp_connect (my_socket, remip, PortNumber, 0);
break;
case TCP_STATE_CONNECT:
Flags.Send_answer = 1;
break;
}
}


unsigned short tcp_callback (uint8_t soc, uint8_t evt, uint8_t *buf, uint16_t len)
{
unsigned int i = 0;
/* This function is called by the TCP module on TCP event */
/* Check the Net_Config.h for possible events. */
switch (evt)
{
case TCP_EVT_DATA: //
/* TCP data frame has arrived, data is located at *buf, */
/* data length is len. Allocate buffer to send reply. */
my_socket = soc;
my_len = len;
tcp_send_buff();
for(i = 0; i <= len; i++)
{
my_rx_buff[i] = *buf;
buf++;
}
break;

case TCP_EVT_CONREQ:
/* Remote host is trying to connect to our TCP socket. */
return (1);

case TCP_EVT_ABORT:
break;

case TCP_EVT_CONNECT:
/* Socket is connected to remote peer. */
return (1);

case TCP_EVT_CLOSE:
break;

case TCP_EVT_ACK:
/* Our sent data has been acknowledged by remote peer */
break;
}
return (0);
}


Теперь в основном цикле:
Код
        if(Flags.Send_answer)
        {
                /* We are connected, send command to remote peer. */
            my_temp = tcp_check_send (my_socket);
            if (my_temp != 0)
                    {
                        maxlen = tcp_max_dsize (my_socket);
                        if(maxlen > 255) maxlen = 255;
                        sendbuf = tcp_get_buf (maxlen);
                        memcpy (sendbuf, my_tx_buff, maxlen);
                        tcp_send (my_socket, sendbuf, maxlen);
                    }
            Flags.Send_answer = 0;
        }
Golikov A.
Да... чудно это все...

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

smk
Цитата(Golikov A. @ Jul 29 2014, 23:12) *
Да... чудно это все...

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

Интересно сколько оперативки кейловский стек под сокет ТСР резервирует.
Golikov A.
ну как бы это в net_config.c указывается...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.