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

 
 
 
Reply to this topicStart new topic
> Обработка длительных процессов в RTOS
Harvester
сообщение Dec 10 2014, 15:53
Сообщение #1


Местный
***

Группа: Участник
Сообщений: 338
Регистрация: 1-02-06
Из: Королев, М.О.
Пользователь №: 13 846



Имеем простую RTOS (REX, если кому интересно).
Одна из особенностей этой оси - в ней есть системный процесс сторожевого таймера.
Соответственно, в каждом процессе создается таймер, по сигналу от которого процесс "пинает" сторожевой таймер. Этот сигнал вместе со всеми остальными мониторится в теле процесса.

Собственно, я не могу решить, как следует поступать, если в процессе вызывается функция, время выполнения которой может оказаться больше периода сторожевого таймера.
Что мне приходит в голову:
1. Увеличить период стор. таймера - непонятно на сколько, т.к. время выполнения функции неизвестно;
2. Отслеживать сигнал таймера процесса и "пинать" стор. таймер в этой долгой функции - как-то некрасиво и возможность такого решения зависит от алгоритма самой функции (есть в этой функции "суперлуп" или нет);
3. Отключать сторожевой таймер для данного процесса перед вызовом функции и включать после возврата (в ОС такие функции предусмотрены) - почему-то тоже не нравится wink.gif
В общем, все три варианта мне не нравятся. Посему прошу вашего совета и других идей.
Может я вообще велосипед изобретаю и уже все давно придумано?

Сообщение отредактировал Harvester - Dec 10 2014, 20:50


--------------------
-Да как так-то?/-Да как-то так/-Ну так-то да
Go to the top of the page
 
+Quote Post
Russky
сообщение Feb 23 2015, 23:13
Сообщение #2


Частый гость
**

Группа: Участник
Сообщений: 84
Регистрация: 17-11-11
Пользователь №: 68 371



Цитата(Harvester @ Dec 10 2014, 19:53) *
...
В общем, все три варианта мне не нравятся. Посему прошу вашего совета и других идей.
Может я вообще велосипед изобретаю и уже все давно придумано?


Подходящих выриантов как мне кажется два:
1. Как Вы и сказали, сделать период таймера больше чем любой из возможных процессов. Это норма. Так всегда как правило и делают.
2. Запускать ф-ю долгих вычислений в задаче с меньшим приоритетом чем тред где пинается таймер. А зависла эта задача или нет, пишите свою обработку тогда.

sm.gif
Go to the top of the page
 
+Quote Post
megajohn
сообщение Feb 24 2015, 04:16
Сообщение #3


Профессионал
*****

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



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

пример:
Код
//------------------------------------------------------------------------------
void debug_replace_fw_cb( UINT copy, UINT total )
{
    static UINT prev = 0;
    if( ( copy - prev ) > 50000 )
    {
        prev = copy;
        dprintf( "copy %u/%u", copy, total );
    }

// тут ваш ватчдог, или еще что нужно
}

FRESULT fret = data_storage_file_copy( "firmware.bin", "firmware.old", debug_replace_fw_cb, NULL );


--------------------
Марс - единственная планета, полностью населенная роботами (около 7 штук).
Go to the top of the page
 
+Quote Post
Russky
сообщение Feb 24 2015, 11:18
Сообщение #4


Частый гость
**

Группа: Участник
Сообщений: 84
Регистрация: 17-11-11
Пользователь №: 68 371



Цитата(megajohn @ Feb 24 2015, 08:16) *
вариант 4: при вызове долгих функций лучше передавать еще указатель на callback-функцию, в которой можно смотреть процент выполнения. И вот там то и делать ваш сброс WD


Вариант хорош!
Go to the top of the page
 
+Quote Post

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

 


RSS Текстовая версия Сейчас: 13th July 2025 - 22:54
Рейтинг@Mail.ru


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