[Arlleex 180]

Посмотрите в сторону манипуляций с алгоритмом Нэйгла. Возможно, есть там что-то такое.

ИМХО, рассчитывать в байт-ориентированном протоколе TCP (как уже выше правильно заметили) на кадр-ориентированность как-то наивно.

[k155la3 27]

1 hour ago, tonyk_av said:

Даже три. Третий _WIZCHIP_IO_MODE_SPI_5500_, хотя он, вроде, идентичен FDM. Пробовал это менять, никак не влияет. Зато в примерах работы с Модбас показаны именно целые, не фрагментированные, пакеты. И разбивка одной посылки как 4+4+2 настораживает. Видимо, есть какая-то настройка у этого 5500, которая влияет на это. Только вот какая, где она описана?

Вы тут вскользь помянули Modbus.  Если реализуете Modbus-TCP то и смотреть приходящие пакеты надо утилитой-монитором, поддерживающим этот протокол на базе TCP (подобные modpoll, с TCP).  

Если есть желание работать именно с пакетами-фреймами, то

17 hours ago, jcxz said:

В протоколе. Если надо чтобы не делились - меняйте на другой. UDP например.

используйте датаграммы / UDP получите работу с пакетами в чистейшем-простейшем виде. Недостаток только один (вернее два) - подтверждения-повторы канала  вам придется реализовывать собственноручно. И "потока" со сборкой в готовый файл уже не будет. Зато будет существенное повышение производительности и "реалтаймовости" канала. Да, и "устойчивать" соединения будет зависить только от того, как Вы программно реализуете эту устойчивость (для TCP это задача по большей части в самом TCP).

Можете реализовать "свой" протокол на базе UDP где пакеты modbus будут "упакованы" в UDP в качестве данных.

Чтобы разобраться с W5500 "не методом тыка" Вам нужно подключить на Ethernet сниффер. "В чистую" нужен старый HUB + софтина для просмотра трафика TCP по Ethernet. 

[jcxz 239]

3 часа назад, k155la3 сказал:

Недостаток только один (вернее два) - подтверждения-повторы канала  вам придется реализовывать собственноручно. И "потока" со сборкой в готовый файл уже не будет.

Если автор будет из UDP-пакетов собирать какие-то свои, более крупные пакеты, то кроме подтверждений-повторов, нужно будет ещё озаботиться восстановлением последовательности отправленных кадров на стороне приёма.

3 часа назад, k155la3 сказал:

Зато будет существенное повышение производительности и "реалтаймовости" канала.

Если из UDP-кадров нужно будет собирать свои кадры (более крупные), то есть 2 пути:

1) каждый UDP-кусочек передавать в режиме запрос-ответ, не передавая следующий кусочек пока удалённая сторона не квитирует предыдущий;

2) передавать сразу несколько UDP-кусочков, не ожидая подтверждения ответа удалённой стороны (подтверждая сразу группу например - а-ля TCP).

В 1-м способе общая скорость передачи будет зависеть от задержек канала. И в общем случае большой скорости не добиться.

В 2-м способе общая скорость будет значительно выше, но надо будет бороться с перепутыванием последовательности кадров. И в целом придётся построить что-то типа TCP-поверх-UDP. Что для начинающего будет весьма сложно. Тем более для человека, никак не могущего взять толк, почему в TCP в принципе нельзя рассчитывать на какие-то "кадры".

Естественно - 1-й способ намного проще.

4 часа назад, tonyk_av сказал:

Видимо, есть какая-то настройка у этого 5500, которая влияет на это. Только вот какая, где она описана?

Когда уже наконец-то прочитаете - что такое TCP???

В TCP нет понятия кадров. В принципе нет. Это байтовый поток.

То что вы передаёте эти байты группами в W5500 - ничего не значит. Эти группы байт, далее, при движении через сеть, могут передаваться или сразу целиком или по кусочкам, хоть по одному байту. И на удалённой стороне, в выходной интерфейс (какой бы он у вас ни был), могут вылезать так же: или все сразу вместе или группами. Как повезёт. Сейчас они вылезли вместе, через минуту следующая посылка - разбившись на несколько групп. Какие бы настройки вы не нашли в W5500 - ничего не поможет. W5500 от себя в сеть может отправить сразу все байты, а по дороге эта группа байт может быть фрагментирована и доставлена в целевую точку в нескольких посылках.

 

PS: Чем раньше сядете за учебник по TCP/IP, тем меньше потеряете времени впустую.  

[tonyk_av 44]

И вот так все посылки от 5500 к ПК. В чём может быть причина?

[aaarrr 69]

Самого интересного недостаёт - таймстемпов.

[tonyk_av 44]

1 hour ago, aaarrr said:

Самого интересного недостаёт - таймстемпов.

 

Вызов wizchip_gettimeout( &to ) дал вот такие результаты. Вроде, адекватные значения.

[aaarrr 69]

Между пакетами аккурат по 10мс. Не бьётся с какими-нибудь времянками ПО?

[tonyk_av 44]

44 minutes ago, aaarrr said:

Между пакетами аккурат по 10мс. Не бьётся с какими-нибудь времянками ПО?

Ещё раз запустил сканер. Картина другая.

10мс есть. Пробовал менять её до 1с- разницы нет.

Изменено 31 мая, 2022 пользователем tonyk_av

[aaarrr 69]

6 minutes ago, tonyk_av said:

Картина другая.

Те же аккуратные 10мс между исходящими пакетами.

[tonyk_av 44]

9 minutes ago, aaarrr said:

Те же аккуратные 10мс между исходящими пакетами.

То есть пилит при отправке 5500, так что ли?

Изменено 31 мая, 2022 пользователем tonyk_av

[aaarrr 69]

9 minutes ago, tonyk_av said:

То есть пилит при отправке 5500, так что ли?

Если только в неё данные отгружаются без таких пауз.

[tonyk_av 44]

4 minutes ago, aaarrr said:

Если только в неё данные отгружаются без таких пауз.

Пардон, не понял. Можно пояснить?

[aaarrr 69]

3 minutes ago, tonyk_av said:

Пардон, не понял. Можно пояснить?

Если каким-то образом из вашего ПО в W5500 данные не отгружаются тремя частями с перерывом в 10мс (или просто медленно или с паузами).

[tonyk_av 44]

1 minute ago, aaarrr said:

Если каким-то образом из вашего ПО в W5500 данные не отгружаются тремя частями с перерывом в 10мс.

Я прошёл в отладчике Визнетовскую библиотеку и нигде не встретил никаких попыток повторной отправки: загрузили в 5500 3 управляющих байта и 10 байт посылки- и всё, вернули 10.

[k155la3 27]

Я бы посмотрел серверную часть. Потому как есть вероятность что идут очень частые запросы на клиента по каналу управления. 

И они "не сторговались" в этой части. Или вообще проблема не в W5500 а в работе софта-сервера (настройки).