[BAT 0]

Виснут процессы с более низким приоритетом.

При этом более старший процесс спокойно крутится и имеет у себя в цикле ожидание сообщения с таймаутом + Sleep.

Можно как-либо по переменным оси определить, где подвис младший процесс, или куда деваются ресурсы?

Версия оси 3.10.

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

[dxp 34]

Виснут процессы с более низким приоритетом.

При этом более старший процесс спокойно крутится и имеет у себя в цикле ожидание сообщения с таймаутом + Sleep.

Можно как-либо по переменным оси определить, где подвис младший процесс, или куда деваются ресурсы?

Какой процессор? Под какой компилятор? Какие имеете средства отладки?

 

Посмотреть Kernel::ReadyProcessMap - по соответствующему биту выяснить состояние процесса (готов он к выполнению или нет; если готов, но не работает, значит блокирован каким-то более приоритетным процессом, если не готов, а по логике должен бы, то смотреть место, где этот процесс переводится из ожидающих в готовые к выполнению).

 

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

Что за грабли? В чем проявляются?

[BAT 0]

про грабли - было следующие

 

в одном процессе с периодичностью 60 мс слались сообщения с данными

другой процесс ожидал этих сообщений с таймаутом 10мс

если за эти 10мс сообщение приходило, то оно обрабатывалось,

если не приходило, то просто выполнялись служебные действия

Так вот периодически сообщения просто терялись.

Увидел, что вышло обновление. Посмотрел багфикс.

 

Flag or message missed - ID: 2848274

Last Update: Settings changed ( sb-sf )

Details:

 

Flag or message missed if waiting process timeouted, but new event signaled

before timeouted process gets control.

 

Обновил. Проблема ушла.

 

По поводу текущей проблемы. Есть какие-нибудь ограничения на использования channel

в обработчике прерывания? Обработчик оформлен по всем правилам работы с осью.

 

Работаю с AT91Sam7x512 из под IAR 5.30

[dxp 34]

Обновил. Проблема ушла.

Это давнишняя вещь, просто релиз давно не выпускали. А в репозитории оно давно лежит.

 

 

По поводу текущей проблемы. Есть какие-нибудь ограничения на использования channel

в обработчике прерывания? Обработчик оформлен по всем правилам работы с осью.

Основное и главное ограничение - надо следить, чтобы не возникло ситуации, когда при записи в канал там не оказалось для этого места (или при чтении оказалось нечего читать). Если места не окажется, то канал попытается перевести процесс в ожидание, а в прерывании этого делать нельзя... Вот цитата из доки на эту тему (стр 77):

 

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

 

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

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

[BAT 0]

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

и проверка количества доступных данных перед чтением.

Канал там используется для удобства обмена.

Если других ограничений нет, то проблема не тут. Будем искать... :)