STM32F407: Ethernet + CHECKSUM_BY_SOFTWARE Опции

[k000858]

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

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

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

[Forger]

освобождает семафору

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

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

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

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

Очень рекомендую подключить (для сборки DEBUG) вот такую штуку.
Мне она уже неоднократно помогала быстро находить подобные корявые баги. Жалею, что раньше не применял, иначе съэкономил бы вагон времени и нервов ))
Подключается быстро, т. к. там уже есть порт, заточенный под freertos.

[jcxz]

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

В uCOS например, для разделения ресурсов, кроме мьютексов, можно юзать семафоры. И их можно и занимать и освобождать.

[k000858]

Очень рекомендую подключить (для сборки DEBUG) вот такую штуку.
Мне она уже неоднократно помогала быстро находить подобные корявые баги. Жалею, что раньше не применял, иначе съэкономил бы вагон времени и нервов ))
Подключается быстро, т. к. там уже есть порт, заточенный под freertos.

к сожалению J-Link'а не имею, в моем распоряжении только ST-Link v2

[Forger]

к сожалению J-Link'а не имею, в моем распоряжении только ST-Link v2

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

В uCOS например, для разделения ресурсов, кроме мьютексов, можно юзать семафоры.

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

Для самых "настырных": (выдержка из мануала на 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.

[jcxz]

В принципе, можно вполне успешно забивать гвозди даже лопатой, но не все это поймут
Для самых "настырных": (выдержка из мануала на ucos-3):

Не понял - и для чего это? Что за deadlines и какой от них прок?

[Axel]

Фраза:

Версия проекта со включенной ETH_CHECKSUM_BY_HARDWARE (в драйвере Ethernet и LwIP стеке)...

наталкивает на мысль, что доступ к софтовой считалке происxодит из разных потоков. Я бы начал поиск граблей с этого места.

[Forger]

наталкивает на мысль, что доступ к софтовой считалке происxодит из разных потоков. Я бы начал поиск граблей с этого места.

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

Не понял - и для чего это? Что за deadlines и какой от них прок?

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

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

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

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


Ну, теперь понятно?

[jcxz]

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

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

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

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

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

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

В uCOS для этого есть mailbox

[Forger]

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

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

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

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

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

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

В uCOS для этого есть mailbox

В uCOS-1 и uCOS-2 очередь сообщений глубиной 1 называется Message Mailbox, остальные - Message Queue
В uCOS-3 Message Mailbox, упразднили и вместо нее нужно уже использовать Message Queue с параметром - один.
Однако, любая очередь сообщений - самый "тяжелый" ресурс в любой RTOS. Т. е. в данном случае это неправильное сравнение.
Я же говорю про примитивное уведомление задачи, в этом случае не создаются никакие объекты, для хранения используется лишь 4 байта внутри TCB задачи, которую нужно "уведомить".
Эта фишка появилась во FreeRTOS сравнительно недавно, она реально экономит ресурсы камня (такты, флеш и озу).
В uCOS такого нет.

[scifi]

наталкивает на мысль, что доступ к софтовой считалке происxодит из разных потоков. Я бы начал поиск граблей с этого места.

Знаете, что такое "софтовая считалка"? Это обычный код, которые исполняется своим чередом и не хранит какие-либо статические данные, привязанные к потоку. Следовательно, ничего подобного там быть не может.

[Forger]

Знаете, что такое "софтовая считалка"? Это обычный код, которые исполняется своим чередом и не хранит какие-либо статические данные, привязанные к потоку. Следовательно, ничего подобного там быть не может.

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

[jcxz]

Если приоритеты задач разные, то спасет.

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

Но тем не менее, лишь в мьютекс заложен механизм борьбы с подобными бедами.

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

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

Я сравнивал исходный код FreeRTOS и uCOS-II. Второй - гораздо компактнее. Можете сами убедиться. Так что не надо сказки рассказывать.
И я не знаю как там в uCOS-III, но mailbox-ы в uCOS-II - это совсем не очереди сообщений. Для них совершенно отдельных набор своих функций существует.
И исходя из чисто функционала, mailBox в uCOS-II - это самый лёгкий тип объекта синхронизации. Что там может быть тяжёлого? Одна переменная для указателя. Если в неё пишется !=NULL - объект переходит в сигнальное состояние. При чтении она обнуляется и переходит в несигнальное состояние. Всё.

[Axel]

Знаете, что такое "софтовая считалка"?

Естественно не знаю, пока не увижу. Так что да,

код считалки в студию!

[Forger]

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

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

Имхо - у Вас путаница в терминологии.

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

Я сравнивал исходный код FreeRTOS и uCOS-II. Второй - гораздо компактнее. Можете сами убедиться.

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

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

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

[jcxz]

мьютекс поможет в устранении этого "бага", а вот семафор уже не поможет.

Ещё раз: Каким образом???
Я знаю как это делается например в Win. Но там это свойство - всей системы объектов синхронизации. Вне зависимости от того, что это - мьютекс или event. Т.е. - не зависит от типа объекта.

Нужно объявлять объект "ящика" через OSMboxCreate, заранее создав его экземпляр. Т.е. тратим ОЗУ.

Это, к сожалению, так.

[Forger]

Ещё раз: Каким образом???

Очень просто - средствами самой os, а точнее, встроенными механизмами борьбы с инверсией приоритетов: протокол наследования приоритета (Priority inheritance protocol), протокол увеличения приоритета (Priority ceiling protocol).
Например, вот как это сделано на примере tnkernel.:

Возвращаясь к началу разговора:

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

Это, к сожалению, так.

А чего тогда было спорить?

[scifi]

Дабы не спорить, ждем код считалки в студию!

Всё есть здесь.
За исключением драйвера Ethernet, который сделал неизвестно кто. Вот там бы я и искал проблему. Может быть, просто переписал бы его, потому что всё время так и делаю. Там нужно около 300 строк всего.

[Forger]

Может быть, просто переписал бы его, потому что всё время так и делаю. Там нужно около 300 строк всего.

Кстати, просветите меня - неуча: почему так настойчиво юзают lwip версию 1.4 даже в новых проектах, коли уже давно существует 2.хх?

[jcxz]

Очень просто - средствами самой os, а точнее, встроенными механизмами борьбы с инверсией приоритетов:

Передёргиваете.
Вы утверждали выше, что мьютекс сам по себе решает проблему инверсии приоритетов.
Я Вам написал, что это не так, что мьютекс и инверсия приоритетов - это как горячее и зелёное - никакого отношения одно к другому не имеет.
Средства для борьбы с инверсией приоритетов, если таковые есть, они сами по себе, и они не являются свойством мьютекса, а если они есть, то имеются в разных средствах синхронизации (мьютексы, семафоры, критические секции и т.п.).
Т.е. - в каких-то ОС они есть, в каких-то - нет. Я знаю, что такие средства есть в Win, но их нет в uCOS. Но мьютексы есть и там и там.

А чего тогда было спорить?

Спорить о чём? Где я утверждал, что для объектов синхронизации uCOS не нужна ОЗУ???

[Forger]

Вы утверждали выше, что мьютекс сам по себе решает проблему инверсии приоритетов.

Перечитайте мои посты еще раз отсюда, пожалуйста.
На всякий случай еще раз продублирую мануал uCos: "Semaphores are subject to unbounded priority inversions, while mutex are not."
и википедию: "Мютекс представляет собой двоичный семафор с дополнительными свойствами (например, протоколы обхода неограниченной инверсии приоритетов)."

"...Почти везде для разделения ресурсов используем семафоры.."

Спорить о чём?

.

[jcxz]

Перечитайте мои посты еще раз

Зачем? Вы в сообщении 8 уже небылицы рассказываете.

и википедию: "Мютекс представляет собой двоичный семафор с дополнительными свойствами (например, протоколы обхода неограниченной инверсии приоритетов)."

Очевидно, что такого бреда не может быть в википедии. Хотя бы потому, что "мютексов" никаких не существует в природе, а есть "мьютексы". А отсюда следует, что эту фразу Вы ниоткуда не скопировали, а высосали из пальца.
Вы сами то почитайте хотя-бы википедию, https://ru.wikipedia.org/wiki/Мьютекс
и узнаете что такое мьютекс и deadlock и многое другое.

PS: И про отличие семафора от мьютекса там тоже сказано. Совсем не то что Вы думаете.

[Forger]

....небылицы рассказываете. ....такого бреда не может быть в википедии. ...
..."мютексов" никаких не существует в природе, а есть "мьютексы".

Когда все объективные аргументы исчерпаны, в ход идет "тяжелая артиллерия": придирка к грамматическим ошибкам, обвинения в "бреде", "небылицах", "высосано из пальца" т.п. ...

А отсюда следует, что эту фразу Вы ниоткуда не скопировали, а высосали из пальца.

"Высосано" отсюда.

И про отличие семафора от мьютекса там тоже сказано. Совсем не то что Вы думаете.

Значит врут книги или я просто не умею читать.
А мануалы к uCos, freeRTOS, tnkernel и другим осям вообще рассказывают целые "небылицы".... Нда, как все печально-то
Уж сделайте милость, просветите неучей - в чем же состоит Истинное Отличие семафора от мьютекса!

[scifi]

Кстати, просветите меня - неуча: почему так настойчиво юзают lwip версию 1.4 даже в новых проектах, коли уже давно существует 2.хх?

Полгода всего. Это недавно, почти вчера.
Скажем, если сравнивать с C99, понадобилось лет 10, чтобы начало внедряться.
Кстати, насчёт "новых проектов" я бы уточнил. Скажем, порт lwip для FreeRTOS - это старый проект. Кубический куб - тоже. А вот чтобы кто-то самостоятельно взял исходники lwip с официального сайта и прикрутил к своему проекту - это редкость. Обычно возникают вопросы типа "ой, у меня не работает, где там галочку поставить в кубическом кубе?"

[jcxz]

Когда все объективные аргументы исчерпаны, в ход идет "тяжелая артиллерия": придирка к грамматическим ошибкам, обвинения в "бреде", "небылицах", "высосано из пальца" т.п. ...

Может Вы не поняли, но это не придирка к грамматике. Вы написали про википедию и типа привели выдержку из неё. Я указал, что это не может быть ссылкой оттуда, так как в википедии даже слово "мютекс" не находится. Значит Ваш аргумент выдуман. И в википедии кстати в описании мьютекса ничего не говорится о его возможностях по инверсии приоритета. Как и следовало ожидать. И статья там безотносительно ОС - для всех ОС.

"Высосано" отсюда.
Значит врут книги или я просто не умею читать.

Вот это похоже на правду - что не умеете читать.
Отсюда Вы и дёрнули эту цитату. И совсем не поняли, что она относится к конкретной ОС - tnkernel. Т.е. - как я и писал ранее - средства борьбы с инверсией приоритетов - это свойство данной ОС, а не в целом всех мьютексов как класса объектов синхронизации. Мьютексы в других ОС могут не иметь таких средств или иметь другие и от этого они не перестают быть мьютексами.

А мануалы к uCos
Уж сделайте милость, просветите неучей - в чем же состоит Истинное Отличие семафора от мьютекса!

Отличия описаны в той же википедии.
Лучше Вы - сделайте милость - укажите каким образом мьютекс в uCOS-II борется с инверсией приоритетов. Мне очень интересно. А то пользуюсь uCOS-II уже лет 10 и не знал о такой её замечательной особенности!
Если докажете что мьютексы умеют это делать, вот ей богу - перейду исключительно на них

А вот чтобы кто-то самостоятельно взял исходники lwip с официального сайта и прикрутил к своему проекту - это редкость.

А чтобы кто-то самостоятельно взял и написал TCP-стек самостоятельно, не беря lwIP?

[Forger]

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

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

[jcxz]

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

Слились значит. Что и следовало ожидать.
Так как никаких средств борьбы с инверсией приоритетов мьютекс (сам по себе, как класс объектов синхронизации в разных ОС) не имеет.

[Forger]

Так как никаких средств борьбы с инверсией приоритетов мьютекс (сам по себе, как класс объектов синхронизации в разных ОС) не имеет.

Нда, случай тяжелый ... поэтому последняя попытка: открывайте исходники вашей (оси os_sem.c и os_mutex.c) и изучайте разницу между аналогичными функциями.
На всякий случай подскажу - ищите фразу "OS_ERR_PIP_LOWER" в файле os_mutex.c.

[jcxz]

Справитесь самостоятельно или нужно разжевать и тут?

Разжуйте. Какую именно строку надо изучать?

На всякий случай подскажу - ищите фразу "OS_ERR_PIP_LOWER" в файле os_mutex.c.

Нет такой фразы! Т.е. - вообще нет ни в одном файле.
Опять из пальца высасываете.

[Forger]

Разжуйте. Какую именно строку надо изучать?

Все ясно: привычка "забивать гвозди лопатой" за 10 лет практики уже превратилась в религию
А менять чужую религию - самое последнее, что стоит делать.

Нет такой фразы! Т.е. - вообще нет ни в одном файле.Опять из пальца высасываете.

У меня есть последняя версия uCos-II v2.90, но это появилось уже в версии 2.80, а в 2.76 нет.
Обновите ось.

А в uCos-III (у меня под боком V3.03.00) мьютекс стал еще более умным - появилось еще больше возможных ошибок применения.

[jcxz]

У меня есть последняя версия uCos-II v2.90, но это появилось уже в версии 2.80, а в 2.76 нет.
Обновите ось.

Последняя какого года у Вас?
Уже в 2013-м была:

Код

*                                              uC/OS-II
*                                        The Real-Time Kernel
*
*                            (c) Copyright 1992-2013, Micrium, Weston, FL
*                                           All Rights Reserved
*
* File    : uCOS_II.H
* By      : Jean J. Labrosse
* Version : V2.92.10

И кому теперь надо обновлять ОС и читать мануал?

[Forger]

Последняя какого года у Вас?

2.90, но я не пользуюсь uCos, поэтому не ищу самые свежие версии.
Смотрите в вашей версии оси список ошибок, которые может возвращать вызов соотв. сервисов для работы с мьютексами и сравните это с соотв. сервисами семафоров.
Вполне возможно, что в более свежей версии их названия немного изменили.
Но сути это не меняет - функционал мьютекса и семафора разный: мьютекс сложнее обычного семафора, впрочем, это написано в книжках, манулах и интернетах.

И кому теперь надо обновлять ОС и читать мануал?

В очередной раз списываю это на вашу слепую религиозность (в данном случае речь про повсеместное применении семафоров где надо и не надо) ...

[jcxz]

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

Почитал мануал на uCOS-II. Да, действительно в мьютексе в ней заложен механизм для борьбы с инверсией приоритетов.
Впрочем - похожий механизм я применял самостоятельно с семафорами (вручную повышал приоритет до некоего специально выделенного).
Но это не очень хорошее решение. Так как задачи в uCOS-II идентифицируются как раз этим самым приоритетом. И при такой динамической смене приоритета перестают работать некоторые функции управления задачами.
И самое главное - при таком решении возникает обратная инверсия приоритетов. Так что это скорее плохое решение.
Ну хорошо - буду иметь в виду, что есть и какие-то встроенные средства.

В очередной раз списываю это на вашу слепую религиозность (в данном случае речь про повсеместное применении семафоров где надо и не надо) ...

"Повсеместное" использование у меня не из-за какой-то "религиозности", а потому что семафор гораздо легче мьютекса и ПО своё стараюсь строить так, чтобы инверсия приоритетов не была слишком страшна.
Да и когда я последний раз читал мануал на uCOS-II, то в его мьютексах не было такой возможности.

[Forger]

Почитал мануал на uCOS-II.

Я рад, что был правильно услышан, даже несмотря на то, что на это "ушло" две с лишним страницы в этой теме

з.ы. Начиная с uCos-3 появился механизм непосредственного уведомления задач, простых сообщений и семафоров, которые не требуют создавать и объявлять экземпляры соотв. сервисов.
По аналогии как это сделано во FreeRTOS. Я рекомендую перейти на uCos-3 хотя бы лишь из-за этого - ресурсы экономятся весьма существенно. Подробности см. в мануале на uCos-3

[jcxz]

Я рад, что был правильно услышан, даже несмотря на то, что на это "ушло" две с лишним страницы в этой теме

Вообще-то всё началось с Вашего безосновательного наезда типа "кто-то что-то забивает лопатой".
И утверждения, что мьютекс - круче.
Как видим из этой самой документации - ничем он не лучше, и проблему инверсии приоритетов тоже не решает. Он её только инвертирует.

з.ы. Начиная с uCos-3 появился механизм непосредственного уведомления задач, простых сообщений и семафоров, которые не требуют создавать и объявлять экземпляры соотв. сервисов.
По аналогии как это сделано во FreeRTOS. Я рекомендую перейти на uCos-3 хотя бы лишь из-за этого

А Вы смотрели остальные различия uCOS-II и uCOS-III? нет? А я смотрел, когда полгода назад подумывал перейти. И отказался от этого. Достаточно взглянуть хотя-бы на вызовы API этих ОС - там где у uCOS-II 1-2 аргумента, у uCOS-III - 5-6шт! И в чём упрощение? Может где-то в чём-то там уменьшилось, зато остальное всё значительно утяжелилось.
И uCOS-II у меня своя - доработанная с оптимизированным переключателем контекста, раза в 1.5 меньше штатного.

[Forger]

И утверждения, что мьютекс - круче.

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

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

А Вы смотрели остальные различия uCOS-II и uCOS-III?

Не смотрел, пока не пользую эту ось.

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

[jcxz]

Вообще не пользуюсь осями в "чистом виде" - у меня реализованы обертки вокруг разных осей под единый привычный мне стиль.

У меня тоже есть такие обёртки
Сразу с обработкой ошибок, возвращаемых API ОС.

во freertos сравнительно недавно появилась возможность статически создавать объекты, как это обычно принято в других осях.

Да, я тоже, когда подумывал о переходе, видел что появилась эта возможность - это конечно очень хорошо, что добавили. Непонятно - почему не сделали этого раньше?

[Forger]

У меня тоже есть такие обёртки

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

Сразу с обработкой ошибок, возвращаемых API ОС.

Вот, подумываю прикрутить к своей обертке оси еще нормальную обработку исключений Exception. но нужно проверять оверхед и главное - целесообразность в оносительно мелких проектах....
Но это уже отдельная тема для беседы ))

Непонятно - почему не сделали этого раньше?

Такая же хрень со встроенной осью в keil - RTX. Привлекает встроенный плагин под эту ось в самом Keil, даже пытался сделать такой плагин под TNKernel, но так и не доделал, хотя в целом работало.

Вообще, когда я искал ось на замену, эти "фишки" отпугнули. Тогда FreeRTOS тоже страдала такой "заразой" )))
Но теперь во FreeRTOS появилась статика, это сделало контроль над софтом более прогнозируемым.
Тоже не понимаю, почему сразу не сделать - ведь это проще всякий динамики.

[jcxz]

Вот, подумываю прикрутить к своей обертке оси еще нормальную обработку исключений Exception. но нужно проверять оверхед и главное - целесообразность в оносительно мелких проектах....

У меня эта обработка уже есть - таскаю её во все проекты на Cortex-M. Без неё уже вообще никуда.
Это мой аналог синего экрана смерти винды
Вынес ошибки API ОС в подкласс программных исключений этого обработчика.

[Forger]

У меня эта обработка уже есть - таскаю её во все проекты на Cortex-M. Без неё уже вообще никуда.
Это мой аналог синего экрана смерти винды
Вынес ошибки API ОС в подкласс программных исключений этого обработчика.

И как по оверхеду? Сильно жрет стек?

[jcxz]

И как по оверхеду? Сильно жрет стек?

Кто? Обработчик? А какая разница? У меня же это - аналог "экрана смерти": после защёлкивания события, он сохраняет информацию о событии в соотв. область памяти и (в зависимости от ключа компиляции) или дёргает reset девайса (режим release) или уходит в бесконечный цикл индикации ошибки (режим debug).
На входе в этот обработчик у меня предполагается, что состояние системы - любое, разрушенное, так что - сразу запрет всех прерываний/фаултов, инит стека и железа в откл. состояние. Стек для этого режима (это у меня называется "режим ловушки") устанавливаю на какую-нить область в ПО, содержимое которой не важно в режиме ловушки (чтобы можно было при необходимости посмотреть нужные переменные). Например - на область видеоОЗУ.
Опционально, в некоторых проектах, после рестарта системы, содержимое области памяти, хранящей инфу о ловушке, сохраняется в журнал событий в энергонезависимой памяти.

[Forger]

У меня же это - аналог "экрана смерти":

Интересное решение, взял на заметку ...

[k000858]

пока удалось выяснить вот что:
1) при шторме UDP трафика на не открытый порт происходит сбой работы Ethernet интерфейса (дело не в стеке TCP), перестает срабатывать Eth прерывание. устройство перестает обрабатывать входящие запросы (пинг, арп и тд)
2) при этом устройство уходит в HardFault_Handler, но благодаря наличию RTOS, зависнув в вечном цикле обработчика HardFault_Handler, продолжает генерировать исходящий трафик на eth интерфейсе
3) при попытке вставать отладочный код в HardFault_Handler приводит к снятию эффекта зависания Eth интерфейса. к аналогичному эффекту приводит и хаотичное отключение различных программных блоков в ПО устройства

При этом на события нехватки стека памяти для задач ОС и кучи самой ОС стоят отладочные заглушки, памяти судя по всему хватает.

[Forger]

пока удалось выяснить вот что:

Я бы эту проблему решал поэтапно - для начала полностью вылечить пункт 1.
Для этого вырезал бы из проги все, что можно, кроме драйвера Eth, или даже проще - создал бы пустой отладочный проект, где отлаживается именно этот драйвер Eth (по возможности, испытать его на все случаи жизни).

[k000858]

Я бы эту проблему решал поэтапно - для начала полностью вылечить пункт 1.
Для этого вырезал бы из проги все, что можно, кроме драйвера Eth, или даже проще - создал бы пустой отладочный проект, где отлаживается именно этот драйвер Eth (по возможности, испытать его на все случаи жизни).

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

[Forger]

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

Вероятно, код спроектирован не совсем неудачно.
Лечится создание пустого проекта и отладкой каждого модуля по-отдельности, независимо от других.
Собираем все вместе только после этого. И то собираем все по-одному модуля, проверяя и тестируя каждый шаг.

Если оставить один Eth, подозреваю висяка не будет

Все подозрения и предположения нужно заменять фактами

[jcxz]

Вероятно, код спроектирован не совсем неудачно.

Удалённая отладка по сообщениям на форуме - вещь неблагодарная!

PS: Имхо - вначале нужно сделать хотя-бы обработку исключений. С этого я начинаю любой проект. Тогда, возможно, некоторые исключения уже сами покажут на места багов.

[k000858]

Может быть кому то поможет. Нашлось решение проблемы, пока сам не допонял, чем именно помогло

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

Так же пофиксить зависание удалось следующим способом: в функции приёма фрейма в месте

Код

  /* Set Own bit in Rx descriptors: gives the buffers back to DMA */
  for (i=0; i< EthHandle.RxFrameInfos.SegCount; i++)
  {  
    dmarxdesc->Status |= ETH_DMARXDESC_OWN;
    dmarxdesc = (ETH_DMADescTypeDef *)(dmarxdesc->Buffer2NextDescAddr);
  }

  /* Clear Segment_Count */
  EthHandle.RxFrameInfos.SegCount =0;

сделать так:

Код

  /* Set Own bit in Rx descriptors: gives the buffers back to DMA */
  FlagStatus next_owned    = RESET;    // флаг занятости следующего дескриптора
  for (i=0; i< EthHandle.RxFrameInfos.SegCount; i++)
  {  
    dmarxdesc->Status |= ETH_DMARXDESC_OWN;
    dmarxdesc = (ETH_DMADescTypeDef *)(dmarxdesc->Buffer2NextDescAddr);

    // MY: если после смены дескриптора на следующий он не свободен
    if((dmarxdesc->Status & ETH_DMARXDESC_OWN) == (uint32_t)RESET)
        next_owned    = SET;
  }

  /* Clear Segment_Count */
  if(next_owned == RESET)    // если следующий дескриптор не занят DMA
      EthHandle.RxFrameInfos.SegCount =0;

Есть у кого то понимание, как это могло помочь?