|
|
  |
STM32F4 Ethernet + Dallas: перетягивание каната |
|
|
|
Aug 27 2015, 08:03
|
Гуру
     
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713

|
Цитата(mantech @ Aug 27 2015, 12:17)  Лично я для такой задачи ртос бы не использовал. ОС никак не мешает никаким самым жёстким времянкам если думаешь головой когда пишешь. У меня например в текущей задаче имеется планировщик, выполняющийся на уровне ISR и осуществляющий приоритетный арбитраж доступа к шине SPI для нескольких устройств сидящих на этой шине (неск. flash и FRAM), а также осуществляющий сервисное управление этими микросхемами. Частота SCLK==30МГц, плотность потока данных по шине - до 3МБ/сек (причём это не равномерный поток, а множество отдельных мелких операций с разными микросхемами в произвольном порядке, некоторые операции очень короткие (типа опроса статуса FLASH или передаче мелких команд FLASH/FRAM) другие - передачи больших массивов на запись/чтение через SPI+DMA. Планировщик обслуживает множество клиентов, которые могут обратиться к хранилищу на микросхемах FLASH или FRAM как из задач ОС так и из ISR. В случае плотной загрузки шины транзакции на шине могут запускаться в произвольном порядке с интервалами порядка нескольких мкс. При этом на этом-же ядре нормально себе живёт uCOS. И всё это на тактовой 120МГц всего. Планировщик реализован на обычной машине состояний (switch-case), но часть его будет реализована на переключаемом стеке. А у ТС вообще порядок временных интервалов в 1000 раз ниже - единицы мсек.
|
|
|
|
|
Aug 27 2015, 08:33
|

Местный
  
Группа: Участник
Сообщений: 319
Регистрация: 31-01-12
Пользователь №: 69 978

|
Цитата(SasaVitebsk @ Aug 27 2015, 11:29)  Вот кидаю вам картинку, где виден плагин FreeRTOS, видны задачи, расположение стека, его заполнение и граница. вот бы для эклипса такое )) в общем кажется основное уяснил: 1) задачи с нормальным приоритетом!!! 2) переработка отдельных функций под концепцию ОС со стеком разобрался, диагностировать научился. пока вопросов больше нет. буду прорабатывать. всем спасибо
|
|
|
|
|
Aug 27 2015, 09:34
|
Гуру
     
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713

|
Цитата(k000858 @ Aug 27 2015, 15:02)  при начале работы задача 2 очищает серийники и показаний. может ли так быть, что при запросе вэбки, девайс начал обрабатывать задачу 2 (очистил серийники, начал опрашивать шину 1wire в поиске устройств) и выплюнул страницу не успев дообработать задачу? изза чего, я сделал вывод что работа задачи 2 нарушена? Ну если у Вас так криво реализовано межзадачное взаимодействие - то может быть всякое. Корректней завести два экземпляра структуры с показаниями датчиков. Задача 2 заполняет одну структуру. После её заполнения, копирует её во вторую структуру, доступ к которой закрыт критической секцией. Задача 1 считывает 2-ю структуру целиком (тоже через критическую секцию) в свою локальную переменную, а потом её обрабатывает.
|
|
|
|
|
Aug 27 2015, 10:41
|

Местный
  
Группа: Участник
Сообщений: 319
Регистрация: 31-01-12
Пользователь №: 69 978

|
Цитата(jcxz @ Aug 27 2015, 12:34)  Ну если у Вас так криво реализовано межзадачное взаимодействие - то может быть всякое. Корректней завести два экземпляра структуры с показаниями датчиков. Задача 2 заполняет одну структуру. После её заполнения, копирует её во вторую структуру, доступ к которой закрыт критической секцией. Задача 1 считывает 2-ю структуру целиком (тоже через критическую секцию) в свою локальную переменную, а потом её обрабатывает. вот примерно так сейчас реализовал! попутно обнаружил баг: ошибку в работе с указателем памяти, что было причиной части глюков. теперь все по красоте: хотя саму функцию по обслуживанию шины 1-w еще не переработал в OS-стайл всем спасибо думаю вопросы по RTOS еще будут
|
|
|
|
|
Aug 28 2015, 02:47
|

Местный
  
Группа: Участник
Сообщений: 319
Регистрация: 31-01-12
Пользователь №: 69 978

|
Цитата(SasaVitebsk @ Aug 27 2015, 14:27)  Я бы никаких критических секций не делал. И даже не сталбы синхронизировать. массив структур. 1-ая задача заполняет текущую структуру и передаёт сообщением указатель на неё 2-ой задаче. 2-ая отображает. Если вторая работает быстрее первой, что логично, то по выполнению она засыпает, ожидая нового сообщения. В этом случае, в массиве требуется лишь 2 экземпляра структур. Если вторая задача работает медленней первой, то количество структур надо рассчитать. Ну и иногда будут пропуски. Это некритично. Можно конечно усыплять и 2 задачи, но я бы не стал. Я придерживаюсь принципа регулярной работы с оборудованием и асинхронной её обработки. как бы 1я задача (Ethernet) подразумевает собой не только web (на котором, к слову, помимо датчиков Даллас, отображено еще куча данных, изменений и показаний других датчиков), но и SNMP (с аналогичным функционалом) и еще кучу интернет сервисов. ждать этой задачее более мелку подзадачу не вариант никак. пока реализовал вышеописанным способом, в последствии возможно пересмотрю
|
|
|
|
|
Aug 28 2015, 05:47
|

Местный
  
Группа: Участник
Сообщений: 319
Регистрация: 31-01-12
Пользователь №: 69 978

|
Что бы не создавать вторую тему, задам вопрос в этой, касаемо 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] - для короткого!!!
|
|
|
|
|
Aug 28 2015, 06:37
|
Гуру
     
Группа: Свой
Сообщений: 3 020
Регистрация: 7-02-07
Пользователь №: 25 136

|
Цитата(k000858 @ Aug 28 2015, 08:47)  Подозреваю, необходимо подкрутить некоторые настройки Lwip в файлике lwipopts.h - размеры памяти/буферов сделать побольше Сомневаюсь. Скорее всего, всё упирается не в память, а в быстродействие, а его так просто не подкрутишь. Самый простой выход - не надо включать этот прибор в сеть, по которой гуляет IPTV. В конце концов, это же не игрушка (надеюсь). Можно, зная тип пакетов, которые мешают, организовать раннюю фильтрацию, чтобы пакеты отбрасывались как можно раньше и не грузили процессор. ЕМНИП, некоторые MAC'и могут это делать аппаратно. Естественно, для этого нужно лезть внутрь lwip и править код. Но в любом случае в условиях недостатка быстродействия всегда будет способ устроить DoS атаку, никуда от этого не деться. Хотя не исключён вариант, что просто где-то не хватает буферов. Сразу бежать и крутить какие-то настройки - это танец с бубном. Для начала нужно замерить загрузку процессора и загрузку буферов, а потом решать, что делать.
|
|
|
|
|
Aug 28 2015, 06:50
|

Местный
  
Группа: Участник
Сообщений: 319
Регистрация: 31-01-12
Пользователь №: 69 978

|
Цитата(scifi @ Aug 28 2015, 09:37)  Сомневаюсь. Скорее всего, всё упирается не в память, а в быстродействие, а его так просто не подкрутишь. Самый простой выход - не надо включать этот прибор в сеть, по которой гуляет IPTV. В конце концов, это же не игрушка (надеюсь). Можно, зная тип пакетов, которые мешают, организовать раннюю фильтрацию, чтобы пакеты отбрасывались как можно раньше и не грузили процессор. ЕМНИП, некоторые MAC'и могут это делать аппаратно. Естественно, для этого нужно лезть внутрь lwip и править код. Но в любом случае в условиях недостатка быстродействия всегда будет способ устроить DoS атаку, никуда от этого не деться. Хотя не исключён вариант, что просто где-то не хватает буферов. Сразу бежать и крутить какие-то настройки - это танец с бубном. Для начала нужно замерить загрузку процессора и загрузку буферов, а потом решать, что делать. достаточно запустить броадкаст флудер (UDPшный) и пинг пропадает. от широковещательного трафика никуда не деться, его становится со временем все больше. в принципе то производительно довольно высокая: 168МГц камень, езернет 100мб/с фулл, даже без ос (и остальных задач).
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|