Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: stm32f7+Lwip+lan8742
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
Kot_Schrodingera
Nov 28 2017, 07:52
Всем доброго дня
Нуждаюсь в помощи с 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
Nov 29 2017, 15:26
Ставим на комп wireshark, смотрим лог временных меток принятия пакетов. Думаем.
У меня картинка 768кб (bmp) по http заливается за 100-120 мс.
32f429, обработка ethernet в прерывании.
scifi
Nov 29 2017, 15:36
Цитата(sadat @ Nov 29 2017, 18:26) *
32f429, обработка ethernet в прерывании.

Прерывание или нет - не так важно. Важно настроить правильно размеры и число буферов, коих немало. Ну и не нарушать правила использования API.
sadat
Nov 29 2017, 15:41
Цитата(scifi @ Nov 29 2017, 18:36) *
Прерывание или нет - не так важно. Важно настроить правильно размеры и число буферов, коих немало. Ну и не нарушать правила использования API.

Опытным путём дошел, что обработка состояния ethernet оптимальна при опросе 2мс. Чаще - нет никакого выигрыша по скорости, реже - паузы между пакетами увеличиваются.
Ну и не забывать в настройках увеличивать реально выделенную память под буфера приёма и передачи.
kolobok0
Nov 29 2017, 22:46
Цитата(sadat @ Nov 29 2017, 18:41) *
Опытным путём дошел,...


под форточками, есть параметр для уровня TCP - задержка перед передачей. в lwip не помню - функция есть, реализация или заглушка - давно было дело.
Оно?

(круглый)
Kot_Schrodingera
Nov 30 2017, 06:40
wireshark не вариант, потому что обмен идет между железками и нужен хаб или настраиваемый свитч
Цитата
правила использования API.
- можно об этом поподробнее?
Цитата
Важно настроить правильно размеры и число буферов, коих немало.
не подскажите где об этом можно найти информацию?
Еще раз повторюсь, те настройки, которые предлагает lwip.wikia не удовлетворяют меня
Kot_Schrodingera
Nov 30 2017, 12:24
Нашел еще кое-что, когда виснет передача, основное время забирает передача ровно 2 пакетов (2920 байт). Время передачи 2 пакетов равно примерно 1-2 сек
sadat
Nov 30 2017, 14:35
Цитата(Kot_Schrodingera @ Nov 30 2017, 15:24) *
Нашел еще кое-что, когда виснет передача, основное время забирает передача ровно 2 пакетов (2920 байт). Время передачи 2 пакетов равно примерно 1-2 сек

Без внешнего мониторинга будете долго ходить "вокруг да около". За это время вполне можно хаб достать и поставить программу.
Вот пример файла, вполне себе работоспособного. В своё время пробовал несколько разных из разных источников, остановился на этом.
Нажмите для просмотра прикрепленного файла
BioWolf2000
Dec 1 2017, 07:30
В такой связке тоже были проблемы. Долго изучал пакеты 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;
  }
scifi
Dec 1 2017, 07:37
Цитата(BioWolf2000 @ Dec 1 2017, 10:30) *
В такой связке тоже были проблемы. Долго изучал пакеты Wireshark и видел непонятные паузы. Проблема решилась правкой в файле stm32f7xx_hal_eth.c функции HAL_ETH_TransmitFrame добавлением строки __DSB();

Кстати, у меня давно сложилось ощущение, что то, как они портировали lwip на STM32, - это, скорее, некая демонстрация. Как небольшая демка вроде бы как-то работает. А если хотите сделать что-то серьёзное - используйте на свой страх и риск. Если взорвётся, сожгёт ваш дом, уронит на кого-то бетонную плиту - сами виноваты.
Kot_Schrodingera
Dec 1 2017, 07:43
Цитата
Без внешнего мониторинга будете долго ходить "вокруг да около".

Поставил вторую сетевуху и сделал мост
Нашел эту большую паузу, оказалось вот что
Код
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
Dec 1 2017, 07:45
Цитата(Kot_Schrodingera @ Dec 1 2017, 10:43) *
Поставил вторую сетевуху и сделал мост
Нашел эту большую паузу, оказалось вот что
Код
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
Dec 1 2017, 08:12
Цитата
Проблема решилась правкой в файле stm32f7xx_hal_eth.c функции HAL_ETH_TransmitFrame добавлением строки __DSB();

Данная строка присутствует, но увы...не помогло
sadat
Dec 1 2017, 09:44
Почитать ERRATу на чип?
http://www.st.com/content/ccc/resource/tec....DM00145382.pdf
Полная уверенность в работоспособности второго устройства?
Kot_Schrodingera
Dec 1 2017, 10:39
Да, уверен
sadat
Dec 1 2017, 13:39
Цитата(Kot_Schrodingera @ Dec 1 2017, 13:39) *
Да, уверен

В таких случаях выкладывают часть кода для анализа - то, что не составляет коммерческую тайну. Телепатические приёмы уже не работают.
kolobok0
Dec 1 2017, 19:23
Цитата(scifi @ Dec 1 2017, 10:37) *
..скорее, некая демонстрация....


+1
немного другая мысль - что типа специально немного удалили пару блоков кода. не серьёзно но вот как раз паузы создаёт sm.gif - но думаю мысля та-же..


(круглый)
Kot_Schrodingera
Dec 4 2017, 04:28
Цитата
В таких случаях выкладывают часть кода для анализа - то,

Я думаю не имеет смысла выкладывать часть, которая относится к lwip, там я ничего не менял
CODE
void netconn_thread(void const *argument)
{
HAL_GPIO_WritePin(GPIOE, USB_PWR_GPIO_Pin, GPIO_PIN_SET);
HAL_Delay(10000);
struct netconn *conn, *newconn;


err_t err;
conn = netconn_new(NETCONN_TCP);

if(conn != NULL) {
err = netconn_bind(conn, NULL, 20020);

if(err == ERR_OK) {

netconn_listen(conn);

for(;;) {
err = netconn_accept(conn, &newconn);
connNoErr = true;

//netconn_set_recvtimeout(newconn, 50);
while((!ERR_IS_FATAL(netconn_err(newconn)))&(connNoErr)) {
recv_and_resp_netconn(newconn);
}

//if(err != ERR_OK)
//continue;

netconn_close(newconn);
netconn_delete(newconn);


}
} else {
debug("Can not bind netconn");
}
} else {
debug("Can not create netconn");
}

}
static void recv_and_resp_netconn(struct netconn *conn)
{
struct netbuf *inbuf;
err_t res;
char *buf;
u16_t buflen;
uint8_t type;
uint8_t buff_img[165000];

res = netconn_recv(conn, &inbuf);
if(res == ERR_OK) {

netbuf_data(inbuf, (void**)&buf, &buflen);

if(buflen >= sizeof(packet_tx_t)) {

uint8_t buffer[buflen];
memcpy(&buffer, buf, buflen);
search_object_t *packet = (search_object_t *)&buffer[1];

if(packet->header.cmd != PB_PVS_CMD_LED) {
pb_menu_process(buff_img, IMAGE_SIZE, buffer, buflen, packet->header.cmd);
}

packet_rx_t *packet_rx = (packet_rx_t *)&buff_img[1];

if(packet->header.cmd) {

if(packet->header.cmd == CMD_GET_SCAN) {
size_t size_rx;

if(packet_rx->status) {
size_rx = 20;
} else {
size_rx = IMAGE_SIZE + 14;
};
static uint32_t lt1, lt2, ltd, lt, ltpr;
//taskENTER_CRITICAL();
lt1 = xTaskGetTickCount();
netconn_write(conn, buff_img, size_rx, NETCONN_NOCOPY);
lt2 = xTaskGetTickCount();
ltd = lt2-lt1;
//taskEXIT_CRITICAL();
debug("qwerty\t%u", ltd);

} else {

netconn_write(conn, buff_img, 80, NETCONN_NOCOPY);
}
}
memset(buff_img, 0, 20);
}
} else {
debug("Error receiver : %d", res);
connNoErr = false;

}

netbuf_delete(inbuf);
}



И еще, раз возникает retransmission, то есть мой девайс не может дождаться ответа от хоста, может можно как-то увеличить это время?
scifi
Dec 4 2017, 07:33
Цитата(Kot_Schrodingera @ Dec 4 2017, 07:28) *
И еще, раз возникает retransmission, то есть мой девайс не может дождаться ответа от хоста, может можно как-то увеличить это время?

Просто теряется пакет. Либо при приёме, либо при передаче. Это баг. В нормально работающей системе ничто не теряется.
Kot_Schrodingera
Dec 4 2017, 09:55
Увеличил буффер TCP_SND_BUF
И получил следующее
Код
"1213","5.672845","172.29.21.156","172.29.21.190","TCP","1514","20020  >  56571 [ACK] Seq=712117 Ack=1693 Win=1498 Len=1460"
"1214","5.672951","172.29.21.156","172.29.21.190","TCP","1514","20020  >  56571 [ACK] Seq=713577 Ack=1693 Win=1498 Len=1460"
"1215","5.673065","172.29.21.156","172.29.21.190","TCP","1514","20020  >  56571 [ACK] Seq=715037 Ack=1693 Win=1498 Len=1460"
"1216","5.673137","172.29.21.190","172.29.21.156","TCP","60","56571  >  20020 [ACK] Seq=1693 Ack=710657 Win=65535 Len=0"
"1217","5.673416","172.29.21.156","172.29.21.190","TCP","1514","[TCP Previous segment not captured] 20020  >  56571 [ACK] Seq=717957 Ack=1693 Win=1498 Len=1460"
"1218","5.673745","172.29.21.190","172.29.21.156","TCP","60","56571  >  20020 [ACK] Seq=1693 Ack=713577 Win=65535 Len=0"
"1219","5.673750","172.29.21.190","172.29.21.156","TCP","60","56571  >  20020 [ACK] Seq=1693 Ack=716497 Win=65535 Len=0"
"1220","5.674088","172.29.21.156","172.29.21.190","TCP","1514","20020  >  56571 [ACK] Seq=719417 Ack=1693 Win=1498 Len=1460"
"1221","5.674191","172.29.21.156","172.29.21.190","TCP","1514","20020  >  56571 [ACK] Seq=720877 Ack=1693 Win=1498 Len=1460"
"1222","5.674314","172.29.21.156","172.29.21.190","TCP","1514","20020  >  56571 [ACK] Seq=722337 Ack=1693 Win=1498 Len=1460"
"1223","5.674366","172.29.21.190","172.29.21.156","TCP","60","[TCP Dup ACK 1219#1] 56571  >  20020 [ACK] Seq=1693 Ack=716497 Win=65535 Len=0"
"1224","5.675012","172.29.21.190","172.29.21.156","TCP","60","[TCP Dup ACK 1219#2] 56571  >  20020 [ACK] Seq=1693 Ack=716497 Win=65535 Len=0"
"1225","5.675019","172.29.21.190","172.29.21.156","TCP","60","[TCP Dup ACK 1219#3] 56571  >  20020 [ACK] Seq=1693 Ack=716497 Win=65535 Len=0"
"1226","5.675024","172.29.21.190","172.29.21.156","TCP","60","[TCP Dup ACK 1219#4] 56571  >  20020 [ACK] Seq=1693 Ack=716497 Win=65535 Len=0"
"1227","5.675320","172.29.21.156","172.29.21.190","TCP","1514","[TCP Fast Retransmission] 20020  >  56571 [ACK] Seq=716497 Ack=1693 Win=1498 Len=1460"
"1228","5.676263","172.29.21.190","172.29.21.156","TCP","60","56571  >  20020 [ACK] Seq=1693 Ack=723797 Win=65535 Len=0"
"1229","5.676315","172.29.21.156","172.29.21.190","TCP","1514","[TCP Previous segment not captured] 20020  >  56571 [ACK] Seq=725257 Ack=1693 Win=1498 Len=1460"
"1230","5.676904","172.29.21.190","172.29.21.156","TCP","60","[TCP Dup ACK 1228#1] 56571  >  20020 [ACK] Seq=1693 Ack=723797 Win=65535 Len=0"
"1231","5.677312","172.29.21.156","172.29.21.190","TCP","1514","20020  >  56571 [ACK] Seq=726717 Ack=1693 Win=1498 Len=1460"
"1232","5.678181","172.29.21.190","172.29.21.156","TCP","60","[TCP Dup ACK 1228#2] 56571  >  20020 [ACK] Seq=1693 Ack=723797 Win=65535 Len=0"
"1244","7.145808","172.29.21.156","172.29.21.190","TCP","1514","[TCP Retransmission] 20020  >  56571 [ACK] Seq=723797 Ack=1693 Win=1498 Len=1460"
"1245","7.146624","172.29.21.190","172.29.21.156","TCP","60","56571  >  20020 [ACK] Seq=1693 Ack=728177 Win=65535 Len=0"
"1246","7.146985","172.29.21.156","172.29.21.190","TCP","1514","20020  >  56571 [ACK] Seq=728177 Ack=1693 Win=1498 Len=1460"
"1247","7.147109","172.29.21.156","172.29.21.190","TCP","1514","20020  >  56571 [ACK] Seq=729637 Ack=1693 Win=1498 Len=1460"
"1248","7.147869","172.29.21.190","172.29.21.156","TCP","60","56571  >  20020 [ACK] Seq=1693 Ack=729637 Win=65535 Len=0"
"1249","7.147884","172.29.21.190","172.29.21.156","TCP","60","56571  >  20020 [ACK] Seq=1693 Ack=731097 Win=65535 Len=0"

Я правильно понимаю, что проблемы не у меня?
Grape
Dec 4 2017, 10:16
а какая версия lwip?
Kot_Schrodingera
Dec 4 2017, 10:43
Цитата
а какая версия lwip?

2.0.0
Grape
Dec 5 2017, 09:37
Цитата(Kot_Schrodingera @ Dec 4 2017, 13:43) *
2.0.0


я бы попробовал 2.0.3 и включил бы статистику.
У меня были похожие затыки, в результате нашлась ошибочка в lwip.

Kot_Schrodingera
Dec 11 2017, 04:54
Цитата
я бы попробовал 2.0.3 и включил бы статистику.

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