Разделение функциональности встроенной системы на задачи RTOS

Я пытаюсь понять, как проектировать задачи RTOS для выполнения функций, необходимых для встроенной системы. Какие рекомендуемые ресурсы для изучения конкретных рекомендаций по разработке задач? Ниже приведены некоторые типичные вопросы, на которые я пытаюсь ответить:

  • Должны ли задачи разрабатываться для системного модуля (флеш-память, USB, дисплей и т. д.) или для аппаратного/периферийного оборудования системы (UART, SPI, I2C и т. д.) или для комбинации того и другого? Если оба, то как решить?
  • Имеет ли смысл иметь отдельную задачу для Rx и Tx для последовательной связи? Каковы преимущества/недостатки этого?

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


c arm embedded rtos powerpc
person analogue_G    schedule 20.04.2014    source источник
comment
Возможные конструкции сильно зависят от аппаратного обеспечения. Если в вашем контроллере всего 16 КБ или ОЗУ, вы, вероятно, не можете позволить себе 12 стеков. Что у тебя есть?   -  person Martin James    schedule 20.04.2014
comment
Кроме того, нужны ли вам вложенные прерывания или вы намерены разрешить их?   -  person Martin James    schedule 20.04.2014
comment
@Martin James - в настоящее время использует ARM Cortex-M3 и M4 с 256 КБ и 512 КБ ОЗУ. Оба имеют вложенные прерывания.   -  person analogue_G    schedule 21.04.2014

Ответы (2)


arrow_upward
3
arrow_downward

Задачи могут служить двум целям:

  1. Функциональное разделение
  2. Ответ в реальном времени

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

Вторая цель специфична для RTOS и может включать единственную «функцию», как это может быть задумано в (1), которую необходимо разделить на несколько потоков, чтобы уложиться в сроки в реальном времени. Здесь проблема заключается не только в разделении на задачи, но и в распределении приоритетов потоков.

person Clifford    schedule 20.04.2014

arrow_upward
2
arrow_downward

Ну, в качестве грубого руководства, вы, вероятно, можете обойтись только одним потоком для обработки управления всеми медленными char-ориентированными периферийными устройствами, такими как UART и I2C, если вы запретите вложенные прерывания для таких периферийных устройств. Это позволяет экономить на стеках, позволяет использовать простые FIFO-сообщения от обработчиков прерываний для пакетов rx и позволяет использовать для них общий пул буферов. Поток может ожидать на семафоре буферов в потокобезопасной очереди tx и в одной общей простой очереди FIFO для буферов rx. Всякий раз, когда поток ставит в очередь буфер для tx или обработчик прерывания ставит в очередь буфер rx, он сигнализирует семафору.

person Martin James    schedule 20.04.2014