tcp_check_send выдает нулевое значение, Стек Keil 4.72 Опции

[smk]

Функция

Код

tcp_check_send (my_socket)

стала возвращать нулевое значение. Из-за этого не происходит передачи. Раньше все работало хорошо. Внесенные изменения коснулись лишь сохранения значений во внешнюю EEPROM. Хочу спросить как можно узнать что повлияло и что вообще может повлиять. Спасибо.

[smk]

Попробовал прежние рабочие проекты. Там тоже не работает. Что бы это значило?

[Golikov A.]

провод сетевой отвалился...
Поменялся хаб и перестала автонегатинация проходить,
погорело железо
забилось окно приемника виндуса
повис драйвер...

[smk]

провод сетевой отвалился...
Поменялся хаб и перестала автонегатинация проходить,
погорело железо
забилось окно приемника виндуса
повис драйвер...

Я тоже подозревал, что дело не в программе. Однако линк есть и пингуется. Веб-страничку показывает. Соединение прямое с компьютером, стоит отдельная сетевая карта.

[Golikov A.]

Данные что шлете на стороне компьютера вычитываете? Может окно забилось? Управление потоком есть?

[smk]

Данные что шлете на стороне компьютера вычитываете? Может окно забилось? Управление потоком есть?

Тут наоборот. Я шлю из компьютера, МК получаети дает ответ. Данные приходят, а ответ не уходит т.к. вышеупомянутая функция не дает сделать отправку.

[Golikov A.]

а что tcp_get_state возвращает? Может коннект по какой-то причине закрылся?

[smk]

а что 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.]

простите, с LwIP перепутал, у него есть дебугер встроенный в стэк.

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

[smk]

простите, с LwIP перепутал, у него есть дебугер встроенный в стэк.

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

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

[Golikov A.]

Ну по описанию эта функция вернет 0, если
1. Нет соединения по сокету
2. Нет акак на прошлые посланные данные

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

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

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

[smk]

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

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

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

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


Вынес передачу из tcp_callback и все заработало. В tcp_callback выставляю флаг а все остальное делаю по флагу в основном цикле. Не уверен что это хорошее решение если ответ требуется как можно быстрее или с лимитом времени на ответ.

[Golikov A.]

ОООО! а разве можно в TCP калбеке что-то слать? Туда же валятся не только приход данных, но и приемы подтверждений и прочее...

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

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