Pull to refresh

Comments 4

UFO just landed and posted this here
«Получается, что никто не запрещает использовать прерывания для работы с периферией» — нет, слово «периодическое» в «в системе есть единственное периодическое прерывание» не означает, что разрешены другие непериодические прерывания, возможно, не совсем точно написал. Требуется, чтобы в системе вообще было единственное разрешенное прерывание — от таймера для работы шедулера. Чтобы не было непредсказуемых задержек и необходимости критических секций.

То, что по-хорошему для RunMe нужна критическая секция, авторы концепции тоже молчаливо обошли стороной.

А машины состояний — я ничего против них не имею там, где они реально соответствуют контексту. Там, где задачу решает линейный код — я предпочту линейный код. У себя в проекте для SPI используется FIFO c передачей следующего байта в обработчике прерывания окончания передачи предыдущего. Проблема (по крайней мере, я вижу это как проблему) тайм-триггеред именно в том, что нельзя включить прерывание от SPI.
UFO just landed and posted this here
Ну да, особенно когда они про обычные критические секции писали, что на самом деле они ненадежны, т.к. операция запрета прерываний неатомарна :) Хотя если наложить требование, чтобы все задачи выполнялась за время, меньшее одного тика, то в какой-то степени выполнение задач и декремент RunMe будет разнесен во времени с инкрементом. Но это ведь относится к класу пожеланий, а не обеспечения надежности — задаче ж ничего не мешает занять времени больше, чем планировал проектировщик.
Sign up to leave a comment.

Articles