реклама на сайте
подробности

 
 
4 страниц V   1 2 3 > »   
Reply to this topicStart new topic
> STM32F407: Ethernet + CHECKSUM_BY_SOFTWARE
k000858
сообщение Apr 28 2017, 08:13
Сообщение #1


Местный
***

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



В проект включены LwIP (1.4.0) и FreeRTOS. Ethernet интерфейс работает на прерывании, которое освобождает семафору. Задача по освобождению семафоры забирается пакеты.

Версия проекта со включенной ETH_CHECKSUM_BY_HARDWARE (в драйвере Ethernet и LwIP стеке) хорошо выдерживает тест на шторм трафика, ничего не виснет
Версия проекта с софтовым расчетом контрольной суммы при тесте на шторм трафика виснет: Ethernet прерывание перестает выстреливать при получении пакетов, LwIP перестает получать пакеты. необходима именно эта версия проекта.

Кто нибудь сталкивался с таким эффектом? есть идеи как можно подебажить проблему?
Go to the top of the page
 
+Quote Post
Forger
сообщение Apr 28 2017, 09:24
Сообщение #2


Знающий
****

Группа: Свой
Сообщений: 737
Регистрация: 22-02-05
Пользователь №: 2 831



Цитата(k000858 @ Apr 28 2017, 11:13) *
освобождает семафору

"Семафору" как вы говорите не освобождают, (освобождать принято мьютексы), а им лишь сигналят - "семафорят", именно оттуда и взялся такой термин. sm.gif


Цитата
Кто нибудь сталкивался с таким эффектом?

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

Цитата
есть идеи как можно подебажить проблему?

Очень рекомендую подключить (для сборки DEBUG) вот такую штуку.
Мне она уже неоднократно помогала быстро находить подобные корявые баги. Жалею, что раньше не применял, иначе съэкономил бы вагон времени и нервов ))
Подключается быстро, т. к. там уже есть порт, заточенный под freertos.
Go to the top of the page
 
+Quote Post
jcxz
сообщение Apr 28 2017, 09:33
Сообщение #3


Гуру
******

Группа: Свой
Сообщений: 3 776
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Forger @ Apr 28 2017, 11:24) *
"Семафору" как вы говорите не освобождают, (освобождать принято мьютексы), а им лишь сигналят - "семафорят", именно оттуда и взялся такой термин. sm.gif

В uCOS например, для разделения ресурсов, кроме мьютексов, можно юзать семафоры. И их можно и занимать и освобождать.
Go to the top of the page
 
+Quote Post
k000858
сообщение Apr 28 2017, 09:44
Сообщение #4


Местный
***

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



Цитата(Forger @ Apr 28 2017, 12:24) *
Очень рекомендую подключить (для сборки DEBUG) вот такую штуку.
Мне она уже неоднократно помогала быстро находить подобные корявые баги. Жалею, что раньше не применял, иначе съэкономил бы вагон времени и нервов ))
Подключается быстро, т. к. там уже есть порт, заточенный под freertos.

к сожалению J-Link'а не имею, в моем распоряжении только ST-Link v2
Go to the top of the page
 
+Quote Post
Forger
сообщение Apr 28 2017, 09:58
Сообщение #5


Знающий
****

Группа: Свой
Сообщений: 737
Регистрация: 22-02-05
Пользователь №: 2 831



Цитата(k000858 @ Apr 28 2017, 12:44) *
к сожалению J-Link'а не имею, в моем распоряжении только ST-Link v2

В настоящее время полно вполне бюджетных клонов jlink, все они и работают быстрее этого st-link и возможностей дают больше.
Если речь идет про отладочную плату типа discovery от st, то ее встроенный st-link можно легко перешить в j-link (обратимая операция), вот подробности


Цитата(jcxz @ Apr 28 2017, 12:33) *
В uCOS например, для разделения ресурсов, кроме мьютексов, можно юзать семафоры.

В принципе, можно вполне успешно забивать гвозди даже лопатой, но не все это поймут sm.gif

Для самых "настырных": (выдержка из мануала на ucos-3):
Цитата
13-5 SHOULD YOU USE A SEMAPHORE INSTEAD OF A MUTEX?
A semaphore can be used instead of a mutex if none of the tasks competing for the shared
resource have deadlines to be satisfied.
However, if there are deadlines to meet, you should use a mutex prior to accessing shared
resources. Semaphores are subject to unbounded priority inversions, while mutex are not.
Go to the top of the page
 
+Quote Post
jcxz
сообщение Apr 28 2017, 10:46
Сообщение #6


Гуру
******

Группа: Свой
Сообщений: 3 776
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Forger @ Apr 28 2017, 11:58) *
В принципе, можно вполне успешно забивать гвозди даже лопатой, но не все это поймут sm.gif
Для самых "настырных": (выдержка из мануала на ucos-3):

Не понял - и для чего это? Что за deadlines и какой от них прок?
Go to the top of the page
 
+Quote Post
Axel
сообщение Apr 28 2017, 11:09
Сообщение #7


Местный
***

Группа: Свой
Сообщений: 467
Регистрация: 21-11-04
Пользователь №: 1 188



Фраза:
Цитата(k000858 @ Apr 28 2017, 11:13) *
Версия проекта со включенной ETH_CHECKSUM_BY_HARDWARE (в драйвере Ethernet и LwIP стеке)...

наталкивает на мысль, что доступ к софтовой считалке происxодит из разных потоков. Я бы начал поиск граблей с этого места.
Go to the top of the page
 
+Quote Post
Forger
сообщение Apr 28 2017, 11:39
Сообщение #8


Знающий
****

Группа: Свой
Сообщений: 737
Регистрация: 22-02-05
Пользователь №: 2 831



Цитата(Axel @ Apr 28 2017, 14:09) *
наталкивает на мысль, что доступ к софтовой считалке происxодит из разных потоков. Я бы начал поиск граблей с этого места.

Уже было озвучено sm.gif


Цитата(jcxz @ Apr 28 2017, 13:46) *
Не понял - и для чего это? Что за deadlines и какой от них прок?

Если важна предсказуемость времени доступности ресурса (deadline), то вместо семафора нужно пользовать мьютекс, он как минимум будет бороться с инверсией приоритетов,
когда занятый ресурс ожидают несколько задач с разными приоритетами и может возникнуть взаимоблокировка (deadlock).

В простейших случаях, когда лишь одна задача ожидает объект (например, пришел байт в прерывании, который положили в буфер и просигналили об этом),
как раз лучше использовать семафор (причем, в случае с байтом по uart лучше использовать счетный семафор).

Кстати, во FreeRTOS для этого есть более быстрый метод - уведомление (notify), он жрет заметно меньше ресурсов.

Другими словами: использовать семафор как средство разделения общего ресурса - это неправильно в разных смыслах.
Цитирую: "Мьютекс отличается от семафора тем, что только владеющий им поток может его освободить, т.е. перевести в отмеченное состояние." (из википедии)


Ну, теперь понятно? sm.gif
Go to the top of the page
 
+Quote Post
jcxz
сообщение Apr 28 2017, 12:02
Сообщение #9


Гуру
******

Группа: Свой
Сообщений: 3 776
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Forger @ Apr 28 2017, 13:39) *
Если важна предсказуемость времени доступности ресурса (deadline), то вместо семафора нужно пользовать мьютекс, он как минимум будет бороться с инверсией приоритетов,
когда занятый ресурс ожидают несколько задач с разными приоритетами и может возникнуть взаимоблокировка (deadlock).

Вообще-то - взаимоблокировка - это нечто другое. Взаимоблокировка - это баг в ПО.
Это когда например задача1 владеет неким ресурсом1 и в это время пытается занять ресурс2, занятый задачей2. Она соответственно уходит в ожидание. И в этот время задача2 если попытается занять ресурс1, то вот тут как раз и возникнет deadlock - взаимоблокировка.
Сомневаюсь, что мьютекс спасёт от такого.

А вот уже инверсия приоритетов задач - это уже третье. laughing.gif
И не уверен что мьютекс спасёт от неё.

Цитата(Forger @ Apr 28 2017, 13:39) *
В простейших случаях, когда лишь одна задача ожидает объект (сигнал семафора или освобождение мьютекса), как раз лучше использовать семафор, бинарный (двоичный) семафор.
Другими словами: использовать семафор как средство разделения общего ресурса - это неправильно в разных смыслах.

Уже лет 10 пишу под uCOS-II. Куча разного ПО. И не только я (в группе разработчиков). Почти везде для разделения ресурсов используем семафоры (в некоторых ПО - по несколько десятков семафоров и почти десяток задач), устройств десятки тысяч уже у заказчиков работают - и всё ок. Странно, да? rolleyes.gif

Цитата(Forger @ Apr 28 2017, 13:39) *
Кстати, во FreeRTOS для этого есть более быстрый метод - уведомление (notify), он жрет заметно меньше ресурсов.

В uCOS для этого есть mailbox wink.gif
Go to the top of the page
 
+Quote Post
Forger
сообщение Apr 28 2017, 13:00
Сообщение #10


Знающий
****

Группа: Свой
Сообщений: 737
Регистрация: 22-02-05
Пользователь №: 2 831



Цитата(jcxz @ Apr 28 2017, 15:02) *
Вообще-то - взаимоблокировка - это нечто другое. Взаимоблокировка - это баг в ПО.
Это когда например задача1 владеет неким ресурсом1 и в это время пытается занять ресурс2, занятый задачей2. Она соответственно уходит в ожидание. И в этот время задача2 если попытается занять ресурс1, то вот тут как раз и возникнет deadlock - взаимоблокировка.
Сомневаюсь, что мьютекс спасёт от такого.

Если приоритеты задач разные, то спасет. Но для борьбы с инверсией приоритетов существуют разные методы. Не всякий метод может помочь.
Я лично не сталкивался с таким, т. к. всегда всячески избегал подобных построений проекта.
Но тем не менее, лишь в мьютекс заложен механизм борьбы с подобными бедами.

Цитата
А вот уже инверсия приоритетов задач - это уже третье. laughing.gif

В данном случае первое является лишь причиной, а второе - следствием, но, однако, сути это не меняет wink.gif

Цитата
Уже лет 10 пишу под uCOS-II. Куча разного ПО. И не только я (в группе разработчиков). Почти везде для разделения ресурсов используем семафоры (в некоторых ПО - по несколько десятков семафоров и почти десяток задач), устройств десятки тысяч уже у заказчиков работают - и всё ок. Странно, да? rolleyes.gif

У вас видать были приняты такие непривычные правила, которые со временем переросли в традицию, полагаю, что лет через 20 это превратится уже в некую "религию" ...
Особенно сложно новичкам - они всегда поддаются чужим необычным традициям. Через 10 лет чужая традиция становится как "родная" biggrin.gif


Цитата
В uCOS для этого есть mailbox wink.gif

В uCOS-1 и uCOS-2 очередь сообщений глубиной 1 называется Message Mailbox, остальные - Message Queue
В uCOS-3 Message Mailbox, упразднили и вместо нее нужно уже использовать Message Queue с параметром - один.
Однако, любая очередь сообщений - самый "тяжелый" ресурс в любой RTOS. Т. е. в данном случае это неправильное сравнение.
Я же говорю про примитивное уведомление задачи, в этом случае не создаются никакие объекты, для хранения используется лишь 4 байта внутри TCB задачи, которую нужно "уведомить".
Эта фишка появилась во FreeRTOS сравнительно недавно, она реально экономит ресурсы камня (такты, флеш и озу).
В uCOS такого нет.
Go to the top of the page
 
+Quote Post
scifi
сообщение Apr 28 2017, 13:10
Сообщение #11


Гуру
******

Группа: Свой
Сообщений: 2 787
Регистрация: 7-02-07
Пользователь №: 25 136



Цитата(Axel @ Apr 28 2017, 14:09) *
наталкивает на мысль, что доступ к софтовой считалке происxодит из разных потоков. Я бы начал поиск граблей с этого места.

Знаете, что такое "софтовая считалка"? Это обычный код, которые исполняется своим чередом и не хранит какие-либо статические данные, привязанные к потоку. Следовательно, ничего подобного там быть не может.
Go to the top of the page
 
+Quote Post
Forger
сообщение Apr 28 2017, 13:16
Сообщение #12


Знающий
****

Группа: Свой
Сообщений: 737
Регистрация: 22-02-05
Пользователь №: 2 831



Цитата(scifi @ Apr 28 2017, 16:10) *
Знаете, что такое "софтовая считалка"? Это обычный код, которые исполняется своим чередом и не хранит какие-либо статические данные, привязанные к потоку. Следовательно, ничего подобного там быть не может.
Но ни что не мешает саму переменную, где хранится текущее значение контрольно суммы, сделать глобальной ...
Дабы не спорить, ждем код считалки в студию!
Go to the top of the page
 
+Quote Post
jcxz
сообщение Apr 28 2017, 13:59
Сообщение #13


Гуру
******

Группа: Свой
Сообщений: 3 776
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Forger @ Apr 28 2017, 15:00) *
Если приоритеты задач разные, то спасет.

Каким образом? Мьютекс спасёт от программного бага??? wacko.gif Вы уверены, что правильно прочитали мой пример?

Цитата(Forger @ Apr 28 2017, 15:00) *
Но тем не менее, лишь в мьютекс заложен механизм борьбы с подобными бедами.

Имхо - у Вас путаница в терминологии. Я знаю что такое инверсия приоритетов. Это есть и в других ОС. Мьютексы от этого не спасают. Спасает другое.

Цитата(Forger @ Apr 28 2017, 15:00) *
Я же говорю про примитивное уведомление задачи, в этом случае не создаются никакие объекты, для хранения используется лишь 4 байта внутри TCB задачи, которую нужно "уведомить".
Эта фишка появилась во FreeRTOS сравнительно недавно, она реально экономит ресурсы камня (такты, флеш и озу).
В uCOS такого нет.

Я сравнивал исходный код FreeRTOS и uCOS-II. Второй - гораздо компактнее. Можете сами убедиться. Так что не надо сказки рассказывать.
И я не знаю как там в uCOS-III, но mailbox-ы в uCOS-II - это совсем не очереди сообщений. Для них совершенно отдельных набор своих функций существует.
И исходя из чисто функционала, mailBox в uCOS-II - это самый лёгкий тип объекта синхронизации. Что там может быть тяжёлого? Одна переменная для указателя. Если в неё пишется !=NULL - объект переходит в сигнальное состояние. При чтении она обнуляется и переходит в несигнальное состояние. Всё.
Go to the top of the page
 
+Quote Post
Axel
сообщение Apr 28 2017, 14:16
Сообщение #14


Местный
***

Группа: Свой
Сообщений: 467
Регистрация: 21-11-04
Пользователь №: 1 188



Цитата(scifi @ Apr 28 2017, 16:10) *
Знаете, что такое "софтовая считалка"?

Естественно не знаю, пока не увижу. Так что да,
Цитата(Forger @ Apr 28 2017, 16:16) *
код считалки в студию!

Go to the top of the page
 
+Quote Post
Forger
сообщение Apr 28 2017, 14:19
Сообщение #15


Знающий
****

Группа: Свой
Сообщений: 737
Регистрация: 22-02-05
Пользователь №: 2 831



Цитата(jcxz @ Apr 28 2017, 16:59) *
Каким образом? Мьютекс спасёт от программного бага??? wacko.gif Вы уверены, что правильно прочитали мой пример?

Если для вас возникновение взаимоблокировки двух задач есть программый баг, то мьютекс поможет в устранении этого "бага", а вот семафор уже не поможет.


Цитата
Имхо - у Вас путаница в терминологии.
У меня как раз все чотко wink.gif
Однако, речь о совсем другом - о разнице в применении мьютекса и семафора: одним делают одно, другим - другое.
По крайней мере так было задумано теми, кто их придумал. Иначе они бы были одним и тем же и назывались одинаково.

Цитата
Я сравнивал исходный код FreeRTOS и uCOS-II. Второй - гораздо компактнее. Можете сами убедиться.
Вполне возможно так и есть.
Я могу сравнить время реакции и размер кода для обычного ресурса и уведомления. Разница существенная. Это в пределах чисто FreeRTOS.
У ТС стоит как раз FreeRTOS, ни о какой uCos речь не велось. При чем здесь она?

Цитата
При чтении она обнуляется и переходит в несигнальное состояние. Всё.

Я не поленился и залез в код os_mbox.c (uCos-2 v2.90).
Нужно объявлять объект "ящика" через OSMboxCreate, заранее создав его экземпляр. Т.е. тратим ОЗУ.
В остальном при передачи и ожидании событий для этого ящика, в соотв. функции нужно передавать указатель на него, что мало чем отличается от семафора или мьютекса.
Во FreeRTOS для использования уведомлений не нужно создавать никаких объектов, кроме самой задачи, которая ждет уведомления.
Передавать можно не только сам факт уведомления (бинарный семафор), но и 4-байтное значение (аналог MailBox в uCos).
Цитируя ваши же слова: "не надо сказки рассказывать" sm.gif
Go to the top of the page
 
+Quote Post

4 страниц V   1 2 3 > » 
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 23rd November 2017 - 02:06
Рейтинг@Mail.ru


Страница сгенерированна за 0.01374 секунд с 7
ELECTRONIX ©2004-2016