STM32F4 Ethernet + Dallas: перетягивание каната Опции

[k000858]

Всем привет.
Есть девайс : stm + 1-wire шина (реализованная аппаратным UART'ом) + ethernet (обслуживается стеком Lwip), управляется FreeRTOS.

Есть 2 задачи (есть и другие, но они на работу не влияют):
1) Обслуживание Ethernet (приоритет realtime (highest))
2) Обслуживание шины 1 wire. (задача выполняется раз в секунду с osDelay(1000) Этапы:
- поиск устройств на шине
- запись инициализирующих данных (для каждого по серийнику из найденных)
- конвертация температуры (для всех)
- osDelay(100);
- конвертация напряжения/тока (для всех СКИП РОМ)
- osDelay(5);
- чтение памяти каждого датчика (по серийнику)

Если приоритет 2й задачи нормал или хай (ниже езернетного таска), езернет работает отлично (пинг без потерь, время ответа 1 мс), однако датчики Даллас работают с перебоем - видимо нарушаются задержки в протоколе общения (задержки аппаратные, т.к. 1-wire шина эмулируется ЮАРТом).
Если приоритет 2й задачи = приоритету езернета, езернет работает неситабильно, регулярно время ответа увеличивается до 10-100мс (при 3 датчика Даллас на шине 1-wire) (в этот момент видимо проц занят работой 2й задачи, по обслуживанию шины 1-wire).

Посоветуйте, плиз, как оптимизировать работу этих 2х задач, что бы задача 1 работала стабильно (с текущим приоритетом), задача 2 так же работала стабильно, выполняясь раз в секунду.



Второй вопрос по тему: FreeRTOS к девайсу прикрутил совсем недавно. Разбираюсь с распределением памяти. На данный момент определяюсь, сколько памяти отдать каждой задачи. Вроде как нужно определить функцию диагностики стэка ОС, которой определять, у какой задачи переполняется стек, увеличивать стек каждой задачи пока не прекратится переполнение. Верно? Как определить такую диагностическую функцию? не могу найти ее в исходниках. Как посчитать (хотя бы ориентировочно), сколько кучи выделить в целом ОС (configTOTAL_HEAP_SIZE) ? И влияет ли размер памяти, выделяемой для Ос на настройки стека/кучи всего Си проекта?

[k000858]

Что бы не создавать вторую тему, задам вопрос в этой, касаемо lwIP + FreeRTOS.
При большом количестве широковещательных пакетов (броадкаст) (ipTV к примеру) девайс в ообщей сети начинает задыхаться - потери пинг пакетов. Подобная проблема наблюдается и в проекте без FreeRTOS и без работы датчиков и прочего (только ethernet + lwIP)
Подозреваю, необходимо подкрутить некоторые настройки Lwip в файлике lwipopts.h - размеры памяти/буферов сделать побольше

CODE

/* ---------- Memory options ---------- */
/* MEM_ALIGNMENT: should be set to the alignment of the CPU for which
lwIP is compiled. 4 byte alignment -> define MEM_ALIGNMENT to 4, 2
byte alignment -> define MEM_ALIGNMENT to 2. */
#define MEM_ALIGNMENT 4

/* MEM_SIZE: the size of the heap memory. If the application will send
a lot of data that needs to be copied, this should be set high. */
#define MEM_SIZE (10*1024)

/* MEMP_NUM_PBUF: the number of memp struct pbufs. If the application
sends a lot of data out of ROM (or other static memory), this
should be set high. */
#define MEMP_NUM_PBUF 10
/* MEMP_NUM_UDP_PCB: the number of UDP protocol control blocks. One
per active UDP "connection". */
#define MEMP_NUM_UDP_PCB 6
/* MEMP_NUM_TCP_PCB: the number of simulatenously active TCP
connections. */
#define MEMP_NUM_TCP_PCB 10
/* MEMP_NUM_TCP_PCB_LISTEN: the number of listening TCP
connections. */
#define MEMP_NUM_TCP_PCB_LISTEN 6
/* MEMP_NUM_TCP_SEG: the number of simultaneously queued TCP
segments. */
#define MEMP_NUM_TCP_SEG 12
/* MEMP_NUM_SYS_TIMEOUT: the number of simulateously active
timeouts. */
#define MEMP_NUM_SYS_TIMEOUT 10


/* ---------- Pbuf options ---------- */
/* PBUF_POOL_SIZE: the number of buffers in the pbuf pool. */
#define PBUF_POOL_SIZE 10

/* PBUF_POOL_BUFSIZE: the size of each pbuf in the pbuf pool. */
#define PBUF_POOL_BUFSIZE 1524


/* ---------- TCP options ---------- */
#define LWIP_TCP 1
#define TCP_TTL 255

/* Controls if TCP should queue segments that arrive out of
order. Define to 0 if your device is low on memory. */
#define TCP_QUEUE_OOSEQ 0

/* TCP Maximum segment size. */
#define TCP_MSS (1500 - 40) /* TCP_MSS = (Ethernet MTU - IP header size - TCP header size) */

/* TCP sender buffer space (bytes). */
#define TCP_SND_BUF (4*TCP_MSS)

/* TCP_SND_QUEUELEN: TCP sender buffer space (pbufs). This must be at least
as much as (2 * TCP_SND_BUF/TCP_MSS) for things to work. */

#define TCP_SND_QUEUELEN (2* TCP_SND_BUF/TCP_MSS)

/* TCP receive window. */
#define TCP_WND (2*TCP_MSS)

Сообщение отредактировал IgorKossak - Aug 28 2015, 07:02

Причина редактирования: [codebox] для длинного кода, [code] - для короткого!!!

[scifi]

Подозреваю, необходимо подкрутить некоторые настройки Lwip в файлике lwipopts.h - размеры памяти/буферов сделать побольше

Сомневаюсь. Скорее всего, всё упирается не в память, а в быстродействие, а его так просто не подкрутишь.
Самый простой выход - не надо включать этот прибор в сеть, по которой гуляет IPTV. В конце концов, это же не игрушка (надеюсь).
Можно, зная тип пакетов, которые мешают, организовать раннюю фильтрацию, чтобы пакеты отбрасывались как можно раньше и не грузили процессор. ЕМНИП, некоторые MAC'и могут это делать аппаратно. Естественно, для этого нужно лезть внутрь lwip и править код.
Но в любом случае в условиях недостатка быстродействия всегда будет способ устроить DoS атаку, никуда от этого не деться.
Хотя не исключён вариант, что просто где-то не хватает буферов. Сразу бежать и крутить какие-то настройки - это танец с бубном. Для начала нужно замерить загрузку процессора и загрузку буферов, а потом решать, что делать.

[k000858]

Сомневаюсь. Скорее всего, всё упирается не в память, а в быстродействие, а его так просто не подкрутишь.
Самый простой выход - не надо включать этот прибор в сеть, по которой гуляет IPTV. В конце концов, это же не игрушка (надеюсь).
Можно, зная тип пакетов, которые мешают, организовать раннюю фильтрацию, чтобы пакеты отбрасывались как можно раньше и не грузили процессор. ЕМНИП, некоторые MAC'и могут это делать аппаратно. Естественно, для этого нужно лезть внутрь lwip и править код.
Но в любом случае в условиях недостатка быстродействия всегда будет способ устроить DoS атаку, никуда от этого не деться.
Хотя не исключён вариант, что просто где-то не хватает буферов. Сразу бежать и крутить какие-то настройки - это танец с бубном. Для начала нужно замерить загрузку процессора и загрузку буферов, а потом решать, что делать.

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

в принципе то производительно довольно высокая: 168МГц камень, езернет 100мб/с фулл, даже без ос (и остальных задач).

[kolobok0]

...в принципе то производительно довольно высокая: 168МГц камень, езернет 100мб/с фулл, даже без ос (и остальных задач).

и вполне хватает для сканирования эннного кол-ва 1Wire датчиков, с поддержкой 100МБит при максимальных 65535 пинговых пакетах, непрерывно,
фулл рефрэш вэб морды, модбасы, порты логические, аналоговые, управление шимом, логика работы всего устройства, поддержка wifi,
обработка бродкастов входящих, опрос локальной сети и опорного вэб сервера - всё этот камень протаскивает на ура в одной задаче...

Сам lwip надо грамотно посмотреть глазками. Лично сам - находил там пару косяков. Всё перетряс, где было подозрительно - переписал.
Особенно сам обработчик DMA прерывания, работа с памятью, ну и TCP состояния выпрямил(а то там косячёкс был в оригинале)...

Я было хотел вчерась ещё отписаться, но Вам всё уже выше грамотно изложили. Рекомендую прислушаться к товарищу scifi - судя по инет инфе - он
не мало соли переел по сетевым делам...