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

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

А машины состояний — я ничего против них не имею там, где они реально соответствуют контексту. Там, где задачу решает линейный код — я предпочту линейный код. У себя в проекте для SPI используется FIFO c передачей следующего байта в обработчике прерывания окончания передачи предыдущего. Проблема (по крайней мере, я вижу это как проблему) тайм-триггеред именно в том, что нельзя включить прерывание от SPI.
UFO landed and left these words here
Ну да, особенно когда они про обычные критические секции писали, что на самом деле они ненадежны, т.к. операция запрета прерываний неатомарна :) Хотя если наложить требование, чтобы все задачи выполнялась за время, меньшее одного тика, то в какой-то степени выполнение задач и декремент RunMe будет разнесен во времени с инкрементом. Но это ведь относится к класу пожеланий, а не обеспечения надежности — задаче ж ничего не мешает занять времени больше, чем планировал проектировщик.
Only those users with full accounts are able to leave comments. Log in, please.