[haker_fox 60]

12 minutes ago, jcxz said:

Любая задача ОС у меня это: цикл в котором ждётся какой-то объект синхронизации ядра (мэйлбокс, семафор, ...),

Интересный подход. А как справляетесь с "подтормаживанием" пингуемой задачи? Бывает же наверно так, что задача не зависла, а немного "задумалась"? Или такое убирается в ходе тестирования и отладки ПО?

[jcxz 199]

16 минут назад, haker_fox сказал:

А как справляетесь с "подтормаживанием" пингуемой задачи? Бывает же наверно так, что задача не зависла, а немного "задумалась"? Или такое убирается в ходе тестирования и отладки ПО?

Я же написал:

29 минут назад, jcxz сказал:

Для каждой задачи в списке WDT-задача знает максимальное время реакции задачи на пинг и ждёт, дёргая WDI, не более этого времени. Потом дёргать WDI перестаёт.

А если у контролируемой задачи есть какие-то редкие длительные действия, но не хочется чтобы всегда WDT-задача ждала её так долго, то можно во время этих операций иногда вызывать ILivePing().

[Forger 19]

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

По сути реализуется работа диспетчера задач как в винде, где зависший процесс через некоторое время (настраивается в реестре) будет убит.

Тут убивать задачи нельзя, но можно делать соотв. запись в журнал событий и идти на ресет.

WDT по сути вырождается в некую watchdog task, которая мониторит другие задачи. Т.е. что-то по типу программного вочдога.

Но аппаратный WDT все же нужен, он может работать в паре с watchdog task, а может даже и ее саму контролировать.

[jcxz 199]

3 минуты назад, Forger сказал:

Но аппаратный WDT все же нужен, он может работать в паре с watchdog task, а может даже и ее саму контролировать.

У меня именно так и есть. И есть внутренний WDT (в МК) и внешний, контролирующий внутренний.  

[Forger 19]

1 minute ago, jcxz said:

и внешний, контролирующий внутренний.  

А кто контролирует внешний? 

[jcxz 199]

Внешний - железный, с простой RC-цепью внутрях. Такое простое не должно виснуть. Оно должно быть надёжным как лом.  

[Forger 19]

5 minutes ago, jcxz said:

Внешний - железный, с простой RC-цепью внутрях. Такое простое не должно виснуть. Оно должно быть надёжным как лом.  

Шучу я ))

 

Если серьезно, то функционал, который описал выше, можно встроить прямо в саму RTOS, добавив соотв. поле в TCB каждой задачи.

Ведь по сути watchdog task работает с максимальным приоритетом и вызывается чуть ли не каждый системный такт. В таком случает нет смысла создавать для этого отдельную задачу.

Т. е. делаем соотв. hook в task sheduler и немного расширяем структуру TCB. Наверняка в более серьезных ОС это и так уже сделано.

[amiller 2]

Можно примерно так:
Формируется набор флагов.
Каждый флаг устанавливается отдельно в своем критичном таске или прерывании.

С определенным интервалом происходит проверка флагов.

Если хотя бы один флаг не установлен, то сброса WDT не происходит.

А после успешного сброса WDT все флаги сбрасываются и снова всё по кругу.

И неважно при этом задействован внешний таймер или внутренний.

[jcxz 199]

1 минуту назад, amiller сказал:

Каждый флаг устанавливается отдельно в своем критичном таске или прерывании.

С определенным интервалом происходит проверка флагов.

Если хотя бы один флаг не установлен, то сброса WDT не происходит.

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

[haker_fox 60]

53 minutes ago, jcxz said:

Оно должно быть надёжным как лом.

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

[simark1979 0]

А как такой вариант?
В своём цикле каждая задача обновляет свой индивидуальный таймстамп (taskX_timestamp), который равен xTaskGetTickCount() ,
И есть task_watchdog, которая проверяет чтобы разница между xTaskGetTickCount() и taskX_timestamp, не превышала какой-то порог
Если этот порог по какой-то задаче превышен, застреваем в бесконечном цикле, и не дергаем IWD, который потом сбросит контроллер.
Естественно, данные о времени между задачами передаем правильным способом

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

Изменено 12 апреля, 2019 пользователем simark1979

[haker_fox 60]

38 minutes ago, simark1979 said:

В своём цикле каждая задача обновляет свой индивидуальный таймстамп (taskX_timestamp), который равен xTaskGetTickCount()

А где вы "таймстамп" будете хранить для каждой задачи?

[simark1979 0]

50 minutes ago, haker_fox said:

А где вы "таймстамп" будете хранить для каждой задачи?

Сделаю очереди в них и буду хранить

[haker_fox 60]

1 minute ago, simark1979 said:

Сделаю очереди в них и буду хранить

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

[simark1979 0]

4 minutes ago, haker_fox said:

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

Если честно, я не в теме, что такое TCB, нужно изучить)