Kot_Schrodingera 0 28 ноября, 2017 Опубликовано 28 ноября, 2017 · Жалоба Всем доброго дня Нуждаюсь в помощи с Lwip В распоряжение железка stm32f745 Передаю картинку(размер 156к) Прочитал все статьи которые есть на форуме, я даже получилась передача картинки за 30 мс Во первых, как я понял из многих статей, увеличение скорости передачи достигается путем настройки TCP_WND, TCP_MSS, PBUF_POOL_BUFSIZE, PBUF_POOL_SIZE Многие писали, что последние два параметра устанавливают порядка 100 и 16 соответственно, но это противоречит тому, что описано здесь http://lwip.wikia.com/wiki/Tuning_TCP Могли бы вы объяснить почему так или дать путь, в котором нужно искать информацию Во вторых, при передаче картинки бывают лаги, и вместо 30мс она передается за 1-3 с(использую API Netconn), время замерял следующим образом: static uint32_t lt1, lt2, ltd; lt1 = xTaskGetTickCount(); netconn_write(conn, buff_img, size_rx, NETCONN_NOCOPY); lt2 = xTaskGetTickCount(); ltd = lt2-lt1; То есть висит на этой функции Не могу понять, это в драйвере ethernet проблемы или lwip так устроен?и почему тогда данная проблема происходит через раз Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sadat 0 29 ноября, 2017 Опубликовано 29 ноября, 2017 · Жалоба Ставим на комп wireshark, смотрим лог временных меток принятия пакетов. Думаем. У меня картинка 768кб (bmp) по http заливается за 100-120 мс. 32f429, обработка ethernet в прерывании. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 29 ноября, 2017 Опубликовано 29 ноября, 2017 · Жалоба 32f429, обработка ethernet в прерывании. Прерывание или нет - не так важно. Важно настроить правильно размеры и число буферов, коих немало. Ну и не нарушать правила использования API. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sadat 0 29 ноября, 2017 Опубликовано 29 ноября, 2017 · Жалоба Прерывание или нет - не так важно. Важно настроить правильно размеры и число буферов, коих немало. Ну и не нарушать правила использования API. Опытным путём дошел, что обработка состояния ethernet оптимальна при опросе 2мс. Чаще - нет никакого выигрыша по скорости, реже - паузы между пакетами увеличиваются. Ну и не забывать в настройках увеличивать реально выделенную память под буфера приёма и передачи. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kolobok0 0 29 ноября, 2017 Опубликовано 29 ноября, 2017 · Жалоба Опытным путём дошел,... под форточками, есть параметр для уровня TCP - задержка перед передачей. в lwip не помню - функция есть, реализация или заглушка - давно было дело. Оно? (круглый) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kot_Schrodingera 0 30 ноября, 2017 Опубликовано 30 ноября, 2017 · Жалоба wireshark не вариант, потому что обмен идет между железками и нужен хаб или настраиваемый свитч правила использования API. - можно об этом поподробнее? Важно настроить правильно размеры и число буферов, коих немало. не подскажите где об этом можно найти информацию? Еще раз повторюсь, те настройки, которые предлагает lwip.wikia не удовлетворяют меня Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kot_Schrodingera 0 30 ноября, 2017 Опубликовано 30 ноября, 2017 · Жалоба Нашел еще кое-что, когда виснет передача, основное время забирает передача ровно 2 пакетов (2920 байт). Время передачи 2 пакетов равно примерно 1-2 сек Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sadat 0 30 ноября, 2017 Опубликовано 30 ноября, 2017 · Жалоба Нашел еще кое-что, когда виснет передача, основное время забирает передача ровно 2 пакетов (2920 байт). Время передачи 2 пакетов равно примерно 1-2 сек Без внешнего мониторинга будете долго ходить "вокруг да около". За это время вполне можно хаб достать и поставить программу. Вот пример файла, вполне себе работоспособного. В своё время пробовал несколько разных из разных источников, остановился на этом. lwipopts.txt Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
BioWolf2000 3 1 декабря, 2017 Опубликовано 1 декабря, 2017 · Жалоба В такой связке тоже были проблемы. Долго изучал пакеты Wireshark и видел непонятные паузы. Проблема решилась правкой в файле stm32f7xx_hal_eth.c функции HAL_ETH_TransmitFrame добавлением строки __DSB(); heth->TxDesc = (ETH_DMADescTypeDef *)(heth->TxDesc->Buffer2NextDescAddr); } } ////////////////////// __DSB(); ///////////////////// /* When Tx Buffer unavailable flag is set: clear it and resume transmission */ if (((heth->Instance)->DMASR & ETH_DMASR_TBUS) != (uint32_t)RESET) { /* Clear TBUS ETHERNET DMA flag */ (heth->Instance)->DMASR = ETH_DMASR_TBUS; /* Resume DMA transmission*/ (heth->Instance)->DMATPDR = 0; } 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 1 декабря, 2017 Опубликовано 1 декабря, 2017 · Жалоба В такой связке тоже были проблемы. Долго изучал пакеты Wireshark и видел непонятные паузы. Проблема решилась правкой в файле stm32f7xx_hal_eth.c функции HAL_ETH_TransmitFrame добавлением строки __DSB(); Кстати, у меня давно сложилось ощущение, что то, как они портировали lwip на STM32, - это, скорее, некая демонстрация. Как небольшая демка вроде бы как-то работает. А если хотите сделать что-то серьёзное - используйте на свой страх и риск. Если взорвётся, сожгёт ваш дом, уронит на кого-то бетонную плиту - сами виноваты. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kot_Schrodingera 0 1 декабря, 2017 Опубликовано 1 декабря, 2017 · Жалоба Без внешнего мониторинга будете долго ходить "вокруг да около". Поставил вторую сетевуху и сделал мост Нашел эту большую паузу, оказалось вот что 5288 69.077155 172.29.21.156 172.29.21.190 TCP 1514 [TCP Previous segment not captured] 20020 → 40392 [ACK] Seq=1814255 Ack=3988 Win=1865 Len=1460 5289 69.077975 172.29.21.190 172.29.21.156 TCP 60 [TCP Dup ACK 5286#1] 40392 → 20020 [ACK] Seq=3988 Ack=1812795 Win=65535 Len=0 5311 70.366679 172.29.21.156 172.29.21.190 TCP 1514 [TCP Retransmission] 20020 → 40392 [ACK] Seq=1812795 Ack=3988 Win=1865 Len=1460 то есть я правильно понял?что процесс retransmission занимает секунду? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
BioWolf2000 3 1 декабря, 2017 Опубликовано 1 декабря, 2017 · Жалоба Поставил вторую сетевуху и сделал мост Нашел эту большую паузу, оказалось вот что 5288 69.077155 172.29.21.156 172.29.21.190 TCP 1514 [TCP Previous segment not captured] 20020 → 40392 [ACK] Seq=1814255 Ack=3988 Win=1865 Len=1460 5289 69.077975 172.29.21.190 172.29.21.156 TCP 60 [TCP Dup ACK 5286#1] 40392 → 20020 [ACK] Seq=3988 Ack=1812795 Win=65535 Len=0 5311 70.366679 172.29.21.156 172.29.21.190 TCP 1514 [TCP Retransmission] 20020 → 40392 [ACK] Seq=1812795 Ack=3988 Win=1865 Len=1460 то есть я правильно понял?что процесс retransmission занимает секунду? У меня без Data Synchronization Barrier тоже около секунды было. В STM32F7 серии из-за кэшей может неккоректно DMA работать. И вообще, мне кажется, с выходом F7 серии ST бездумно перенесла код драйверов с 4-ой серии. Очень уж сырые библиотеки Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kot_Schrodingera 0 1 декабря, 2017 Опубликовано 1 декабря, 2017 · Жалоба Проблема решилась правкой в файле stm32f7xx_hal_eth.c функции HAL_ETH_TransmitFrame добавлением строки __DSB(); Данная строка присутствует, но увы...не помогло Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sadat 0 1 декабря, 2017 Опубликовано 1 декабря, 2017 · Жалоба Почитать ERRATу на чип? http://www.st.com/content/ccc/resource/tec....DM00145382.pdf Полная уверенность в работоспособности второго устройства? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kot_Schrodingera 0 1 декабря, 2017 Опубликовано 1 декабря, 2017 · Жалоба Да, уверен Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться