Перейти к содержанию
    

STM32F407: Ethernet + CHECKSUM_BY_SOFTWARE

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

Обновите ось.

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

Уже в 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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

2.90, но я не пользуюсь uCos, поэтому не ищу самые свежие версии.

Смотрите в вашей версии оси список ошибок, которые может возвращать вызов соотв. сервисов для работы с мьютексами и сравните это с соотв. сервисами семафоров.

Вполне возможно, что в более свежей версии их названия немного изменили.

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

И самое главное - при таком решении возникает обратная инверсия приоритетов. Так что это скорее плохое решение.

Ну хорошо - буду иметь в виду, что есть и какие-то встроенные средства.

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Вообще-то всё началось с Вашего безосновательного наезда типа "кто-то что-то забивает лопатой".

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

Как видим из этой самой документации - ничем он не лучше, и проблему инверсии приоритетов тоже не решает. Он её только инвертирует. :biggrin:

 

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

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

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

И uCOS-II у меня своя - доработанная с оптимизированным переключателем контекста, раза в 1.5 меньше штатного.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Не стоить заново все начинать, подобных утверждений я не озвучивал, а лишь цитировал выдержки из мануалов разных осей,

где четко было указано чем мьютекс отличается от семафора.

Посыл был простой - для каждой цели свой инструмент. Или вы хотите и с этим спорить?

 

Ничего против экономии тактов, озу и флэш не имею, но, если это имеет смысл в конкретном проекте.

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

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

 

А Вы смотрели остальные различия uCOS-II и uCOS-III?
Не смотрел, пока не пользую эту ось.

 

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Когда сделал обертку под FreeRTOS, то благодаря уже существующей обертке по TNKernel,

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

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

Это еще учитывая, что в свое время полностью переписывал переключалку контекста у TNKernel на более быструю (содрано с FreeRTOS).

 

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

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

Но это уже отдельная тема для беседы ))

 

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

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

 

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

Но теперь во FreeRTOS появилась статика, это сделало контроль над софтом более прогнозируемым.

Тоже не понимаю, почему сразу не сделать - ведь это проще всякий динамики.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

У меня эта обработка уже есть - таскаю её во все проекты на Cortex-M. Без неё уже вообще никуда.

Это мой аналог синего экрана смерти винды :biggrin:

Вынес ошибки API ОС в подкласс программных исключений этого обработчика.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У меня эта обработка уже есть - таскаю её во все проекты на Cortex-M. Без неё уже вообще никуда.

Это мой аналог синего экрана смерти винды :biggrin:

Вынес ошибки API ОС в подкласс программных исключений этого обработчика.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

2) при этом устройство уходит в HardFault_Handler, но благодаря наличию RTOS, зависнув в вечном цикле обработчика HardFault_Handler, продолжает генерировать исходящий трафик на eth интерфейсе

3) при попытке вставать отладочный код в HardFault_Handler приводит к снятию эффекта зависания Eth интерфейса. к аналогичному эффекту приводит и хаотичное отключение различных программных блоков в ПО устройства

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Я бы эту проблему решал поэтапно - для начала полностью вылечить пункт 1.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я бы эту проблему решал поэтапно - для начала полностью вылечить пункт 1.

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

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

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...